SSIS: Dealing With Temporary Tables in Access

When using temporary tables in SQL Server, all you have to do is prefix the table during creation with a “#” (pound sign) and SQL Server knows to delete the table after the session closes.  Example of creating a temporary table in SQL Server:

ID int IDENTITY(1,1),
firstName nvarchar(30),
lastName nvarchar(30)

Again, if you close your session in SQL Server, the above table will be dropped then and there.  This makes temporary tables in SQL Server very useful to SSIS as they clean up after themselves.

Unfortunately, there are many of us who are still having to deal with all those pesky Access 200x databases running around.  And, unfortunately, Access does not support temporary tables like SQL Server does.  When you create a table in Access, it is there to stay unless you specifically drop it by executing a DROP TABLE statement.

In SSIS, this leads to a bit of a problem.  Let’s say your package fails for whatever reason (lost connection to server, power went out, etc.) before it gets to the step where you clean up all those temporary Access tables (i.e. you have an Execute SQL step that has one or more DROP TABLE statements in it).  The next time that same package is scheduled to run it’s just going to fail again when it gets to the step where you create your temporary tables in your Access database because those tables already exist.

In order to combat this problem, and provide yourself a sanity check as I’m certain that like me you always forget to delete your temp tables while testing which means you get the “table already exists” error a lot, we can put a step in that checks for temp tables in Access and drops them.  Before the step that creates your temp tables, insert a Script Task that runs the following code:

OleDbConnection conn = null;
OleDbCommand comm = null;
public void Main()
    conn = new OleDbConnection(Dts.Connections["Connection Manager"].ConnectionString);
    comm = new OleDbCommand("", conn);

    if (checkForTable("Demographics"))
        comm.CommandText = "DROP TABLE Demograhpics";
    if (checkForTable("newBills"))
        comm.CommandText = "DROP TABLE newBills";
    if (checkForTable("newTrans"))
        comm.CommandText = "DROP TABLE newTrans";
    Dts.TaskResult = (int)ScriptResults.Success;
private bool checkForTable(string tableName)
    string[] restrictions = new string[3];
    restrictions[2] = tableName;
    DataTable dt = conn.GetSchema("Tables", restrictions);
    if (dt.Rows.Count == 0)
        return false;
        return true;

Notice that this code checks for three tables:  Demograhpics, newBills, and newTrans.  You can, of course, keep adding “if” statements to check for your temporary tables or you can pass in an object variable that you can loop through that checks for a list of tables.  This way, if your packages fails for some reason during one run, on the next run any temporary tables in Access will be dropped before the task that creates them executes.

There may be other more elegant ways to handle this problem.  If I think of any, I’ll post them.  You, of course, are welcome to mention other ways in the comments section.


R. I. P. ISA/TMG Server and SBS Server

As I’m certain many of you know, Microsoft has announced the discontinuation of Internet Security and Acceleration (ISA) Server, which was later renamed to Threat Management Gateway (TMG) Server, and Small Business Server.  You can find those announcements here and here respectively.

I must admit I’m of mixed feelings about all this.  I had a fond love of both products.  In fact, I thought Small Business Server 2003 was one of the best products MS ever made.  You had so much cool stuff in one box. 

  • Windows Server 2003
  • Exchange Server 2003
  • SQL Server 2005
  • ISA Server 2004

While that all seemed like such a great idea all those years ago, having all that stuff on one box – especially a 32-bit box – turned out to be a bad idea.  It didn’t take much to fill up those four gigs of RAM with Exchange and SQL Server assuming you used both of them significantly.  Microsoft eventually broke SBS up into two servers with SBS 2008 and SBS 2011, however.  Another issue is that, while I knew what I was doing with SBS, a lot of other “IT Pros” did not.  It wasn’t uncommon at all for me to find an SBS box that was completely hosed and barely functioning – with the client constantly wondering why things sucked so much all the time.  The biggest issue was that most IT people attempted to manually configure all the features rather than using the wizards.  Even Susan Bradley, the SBS Diva, had something to say about that after someone posted a rogue article about configuring SBS – using the completely wrong approach.

This brings me to ISA/TMG.  Again, a great product.  The biggest problem with ISA/TMG was expense.  Today you can get Juniper’s SRX100 fully loaded for less than $1000 with great performance for the majority of small businesses.  The cheapest ISA/TMG computer I ever saw was just over $3000.  No one is going to pay that for a firewall.  Not to mention the fact that I don’t think as many people plugged into ISA/TMG via addon’s as MS had hoped. 

Lastly, of course, as to why these products are going the way of the dinosaur, is The Cloud.  Everyone who knows me knows that I am NOT a big fan of the cloud.  To me its just another round of outsourcing.  Another round of CEO’s and CIO’s stupidly expecting top notch Cadillac quality performance and service out of some people who do not work for them.  We tried it in the 90’s when we fired our IT staff and asked another company to send in theirs to run the show and we tried it again in 2003 when we sent everything to outsource companies in India.  Neither case has worked thus far – at least not to expectation.

Of course, the only thing we know for certain is that the only constant is change.  It’s time to grab some new skills and move forward.  The glory days of having 2 – 3 dozen or so small business clients using SBS 2003 and making a decent living off of them by providing customized service at a great price are long over.  Today we have the “one size fits all” Cloud.  Today, we move our stuff to big servers hosted by faceless people that have no idea who we are or what we need.  Today, we move back to the mainframe. 

Welcome to the future.


Exploring the Juniper SRX Default Configuration

In Part III of our quick start series, we went through the Juniper set up screens to set some initial configuration settings for our new device.  Today, we are going to use the CLI to explorer the default configuration given to us by those initial configurations.

To access the SRX CLI, you need Telnet.  Please note that on Windows 7 and Windows Server 2008 R2 the Telnet client is not installed by default.  You may follow these instructions to install Telnet.

Once you have Telnet installed, if you needed to install it, open a command prompt and type TELNET 


Once you hit enter, you will be presented with a username prompt.  Use the Administrator account that we created in Part III of the Quick Start series to log in.  Note that both user names and passwords are CASE SENSITIVE.  Once logged in, you’ll see a prompt like this.


At the command prompt, type the word configure and press Enter to enter configuration mode.  There are two modes to the SRX, we will investigate them both in future posts.  Suffice to say the mode you enter into when first logging on is Operation Mode used for monitoring and the like.  Configuration Mode is where you configure the device.  Your prompt should now look like this.


Notice that the prompt changed from using a “>” symbol to using a “#” symbol.  The “#” symbol means you are in configuration mode.  The “>” means Operational Mode. 

In Configuration Mode, there are certain commands you use to navigate the configuration tree.  The following shows most, but not all, of the configuration tree:


We will be investigating many of the parts of the configuration tree in future posts.  To navigate the tree, we do have certain commands to use.

show – shows the configuration of the part of the tree you are at.  If you are at the configuration root, the show command will show you the entire tree which can take a long time if there are lots of things configured.  If, however, you have navigated to, say, System | Name-server then the show command will show you only what is in that section.  If there is more information to show than what your window will allow, the show command will fill the window and stop until you press the spacebar for the next page.  The percentage you have seen thus far is shown at the bottom.


edit – use this command to tell the CLI what part of the tree you wish to edit.  For example, if you type edit system then you will enter the system stanza of the tree.  Do notice that the prompt tells you were you are.


up – use this command to navigate up levels of the tree.  edit brings you down to levels you specify, up brings you up the next level above where you are.


top – if you want to go straight up to the configuration root, use top.

Now that we know how to move around a bit, let’s take a look at certain parts of the tree, called Stanzas.  First, type the word top to make sure you are at the top of the configuration root in case you have been playing around.  Next, type the following:

edit system name-server

This will place you in the System part of the tree in the name-server stanza.  Now type show.


You should see the IP addresses of the name servers you typed in while following along in Part III of the quick intro.  Type top to go back to the top of the configuration tree (refer to the diagram above when needed).

Now type the following commands:

edit interfaces fe-0/0/0

If you are using the SRX210, replace the fe with ge.  Otherwise, you should see this:


Notice where the arrow is pointing.  If in the initial configuration screen you unchecked the DHCP box and entered a static IP, that IP is here.  Otherwise, you’ll see DHCP.  This interface is the one that should be plugged in to your ISP.  In my case, it is plugged into my Linksys router which allows my other computers to get on the Internet as well.  Later on, we are going to make some configuration changes to make the SRX my router for my network and we will remove the cheap Linksys.  Type up to go up one level and then type show:


Notice that we are now looking at all the interfaces.  The show command as I mentioned earlier shows you everything in the current position of the tree, including sub-branches of that position.  Since we are at the interface level, it is showing us all the interfaces along with their configurations.  Notice you have the —(more)— at the bottom for scrolling.  Use the space bar to scroll on down.

Notice also that while fe-0/0/0 is assigned a static IP address, or DHCP depending on your choice in the initial configuration screen, the other interfaces are all assigned to a VLAN.  You also have interface lo0 which is, of course, the loopback adapter.  At the bottom, you should see the interface for the VLAN and the IP address it is assigned which is the IP address range of your internal network with the SRX.


Let’s take a look a the VLAN itself.  Type top to get to the configuration root.  Then type:

edit vlans

Notice we have a Virtual LAN called “vlan-trust” defined and that the interface we saw above is assigned to it.  Also, notice the shorthand for which unit to refer to.  Instead of typing the name of the VLAN then the name of the unit, we just do vlan.0 where the zero is the unit.  If you have more units, such as 10, 11, and 12, you could do vlan.10, vlan.11, vlan.12, etc. 


So what we have is an logical interface that defines the IP address range of the VLAN, which is assigned to the VLAN itself, which is in turn assigned to the other interfaces (except fe-0/0/0).  This allows us a great deal of flexibility.  Think about.  You could literally have each port on the front of the SRX assigned to a completely independent VLAN.  Let us continue.  Type top to get to the configuration root again.  Now type the following:

edit security zones

We are now looking at the default zones created by the SRX.  One is called trust and the other is called untrust.  Typically, trust is your internal LAN and untrust is the Internet.  Notice what we are doing:

  • For inbound traffic to the trust zone, we are pretty much allowing everything to go to the SRX.  All protocols.  And we assigned our VLAN, vlan.0, to this zone.
  • For the untrust zone, we assigned fe-0/0/0 and notice that we allow only dhcp and tftp.  Normally I remove these.  Do keep in mind that if you remove DHCP and you chose DHCP as the way for fe-0/0/0 to get IP address from the ISP, you will no longer be able to get on the Internet should your ISP change IP addresses on you (assuming you don’t have a static address).

This all should make sense.  fe-0/0/0 is plugged into our Internet connection and our vlan.0 is our internal network as we examined earlier.  Although, in a true production environment we may place more limitations than this even on the Internal network instead of just allowing everything.


At the CLI prompt, type up to go up one level the type edit policies then type show.

We are now looking at our one and only default security policy.  Should be pretty straight forward.  We have one policy called “trust-to-untrust” that pretty much allows anything from the internal network to go out to the Internet.  Since there is no policy allowing traffic from the Internet to the internal LAN, that means anything from the Internet is blocked.


Type up one more time then type edit nat then type show.  We are now looking at our Network Address Configuration.  We have one rule translating addresses for traffic that goes out regardless of IP address.  We do not translate any traffic coming to us since, thanks to our policy, we have no traffic coming in.


So what we have is this:


This is straight from the book I recommend on my Books I’m Reading page for learning the Juniper SRX Security Services Gateway.  This diagram gives a decent idea of how traffic is processed by the SRX. 

And this is the default configuration you are given after completing the initial setup wizard. 

To exit the CLI of the Juniper SRX, type the exit command until your telnet session is closed.

Next up, we are going to add some VLANs and assign other ports to them.  In my home network, I have my wife’s computer which will go on one VLAN, my computer which will go on another, and a Dell PowerEdge T310 server running several virtual machines that will all be on yet another VLAN.

Do keep in mind that my quick overviews and instructions on how to perform certain tasks are meant to show you how I’m using the SRX.  If you really wish to learn the device properly, I recommend the book Junos Security found here at for paper back or you can go Kindle edition.


WSUS Connection Error

If you get a screen on your WSUS server that looks like this:


Or when trying to connect you get this error:


The problem is most likely with your WsusPool in IIS 7.x.  Open the IIS 7 Manager and go to Application Pools.  Then double-click the WsusPool.  The .Net framework version should be set to v2.0.50727 (mine was set to unmanaged).  Make certain all settings, including .Net Framework version, are set to what you see here:


Click OK then restart IIS 7.  Your WSUS console should connect now.  I have seen this problem come up after fresh installs.  Apparently the installer does not set this setting correctly sometimes.


One Group of Users, Two Terminal Servers, and Two GPO’s in one Group Policy Container

Imagine you have the following situation:  You have a group of users who need to access two different terminal servers.  If both machines required the same settings, that would be a no-brainer, but this isn’t the case.  One terminal server requires a certain set of Group Policy Settings and the other terminal server requires different settings (in my case, the settings in question were the start-up application).  And both servers are members of the same GPO.  How do we handle this situation?

Although there are probably a few solutions to this problem, the one I used was implementing a WMI – Windows Management Instrumentation – filter. 

Open the Group Policy Management Console and go to Forest | Domains | Domain Name | WMI Filters and create a new filter.


The two filters I created are called WMI Legacy Terminal Server and WMI New Terminal Server.  Edit the WMI filter you just made and enter the following WMI Query statement:

SELECT * FROM Win32_ComputerSystem WHERE Name = “servername” and Name <> “servername”

Your screen should show something like this (don’t forget to replace “servername” with the names of your servers):


The statement should give away what we are doing.  We are going to apply a filter to each of the two GPO’s so it will process only for a computer matching the name of the server we want.  Therefore, for one Group Policy Container, we are going to have two terminal servers and two GPO’s that are all members of that one container but only a certain GPO will execute for a certain terminal server.  After you have made your two filters, click on the Group Policy Objects in question and apply the correct filter.  Your screen should look something like this:


So when User A logs on to the Legacy Terminal Server, one GPO will be applied (in my case start up application X), but when logging into the New Terminal Server, another GPO will be applied (in my case starting up application Y). 

One significant drawback to this approach is that each GPO can have only one filter.  Make certain this isn’t of significance to you before using this approach.


Quick Intro to the Juniper SRX Series Security Services Gateway Part V

This will be the last part of our Quick Intro series.  Further posts on the Juniper SRX will be more about doing actual configurations.  Be sure to read up on Part I, Part II, Part III, and Part IV.

In this part, we will discuss a feature of the Juniper SRX that seems to be unique amongst security devices made by its worthy competitors such as Cisco.  This feature is the concept of the Zone.

According to the documentation, “a zone is a logical construct that is applied to an interface as is used as a building block for security policies. . .”  In most devices, security policies allow traffic to go from point A to point B, such as from the local area network to the Internet. or vice versa.  Adding a Zone creates a new dimension in that it simplifies management.  You can have multiple logical interfaces that require similar security grouped into one Zone.

Zones are where you see default names like “Trust,” “Untrust,” and “DMZ” scattered throughout the Juniper documentation.  In earlier products, those were the default zones.  Starting with the SRX, you can rename your zones to what you want and have as many zones as you want.

As we mentioned earlier, logical interfaces are added to a zone.  We also know that each physical interface can have many logical interfaces, called Units.  So with this much granularity, one physical interface can handle traffic, at the same time, for a wide variety of purposes.  You can have physical interface fe-0/0/3 handle traffic for 5 different VLANs, each VLAN belonging to a different zone.  Just remember that a logical interface can be a member of only one zone.

The following is an example of the default zones that come with the SRX once you do the initial configuration:

security-zone trust {
     host-inbound-traffic {
     protocols {
     interfaces {

Notice that we have created a security zone called “trust”.  For inbound traffic, we are allowing everything as the keyword “all” indicates to pass to the SRX.  We are also allowing all protocols.  And we are binding this policy to the vlan.0 interface.  Note that physical interface fe-0/0/1 through fe-0/0/7 was assigned to the VLAN as switching interfaces.  What this means is that ports 1 – 7 on the front of the device are all going to behave like a regular network switch and all all traffic to pass through them as long as that traffic is on the same VLAN.  Of course, this begs the question:  What about Internet traffic?

security-zone untrust {
     interfaces {
          fe-0/0/0 {
               host-inbound-traffic {
                    system-services {

Notice that we have another zone called “untrust.”  Appropriate name given that we are allowing Internet traffic.  Notice that, in contrast to the “trust” zone we are not allowing anywhere near as much latitude.  We allow only dhcp and tftp to pass through this zone straight to the physical interface fe-0/0/0.  So, yes, we can bind a physical interface to a zone, not just a logical one.  And we can severely restrict traffic.  DHCP is allow, of course, in the event that we do not have a static IP address from our ISP.  I’m not sure why the default configuration allows tftp.  I typically remove that.  Do keep in mind that the host-inbound traffic part of a zone is the traffic that goes to the SRX itself, not what is passed from one host to the next.  Security Policies are used to govern traffic from one host to the next.  We’ll talk about those later.

In wrapping this up, we can have a physical interface bound directly to a zone or to any number of logical interfaces that can then be bound to zones.  Zones then have Security Policies.  Obviously, we would bind interfaces, physical or logical, that have like security requirements to one particular zone.  Take a few moments to think about this arrangement and I do believe we can see how we can handle traffic in a very large number of ways.  Also, do keep in mind that all of this ability is even on the low end SRX100 which is a only a few hundred bucks.  You do not have to purchase a $5000 device to obtain what we have talked about thus far.

There is much more to discuss regarding zones, but this is only a quick intro.  As time moves on and I begin configuring the device, more we be explained in higher detail.


Exchange System Manager: The Token Supplied to the Function is not Valid 80090308

I received this error on a SBS 2003 box that I’m going to be migrating from later this year when trying to view public folders from the Exchange System Manager.  Like many others, I tried the usual solutions found here, but in the end this blog post is what worked for me:

While I post that link as a credit to the original author from whence this solution came, I also notice the link is to a blog that is now defunct as the last post was over 5 years ago.  Therefore, I’ll also post the complete steps here just in case that blog disappears or something.

Warning:  We will be using ADSI Edit to directly edit Active Directory.  If you are uncomfortable using this tool, please contact a support professional.  Misuse of ADSI Edit can render your entire Active Directory unusable causing you to have to invoke disaster recovery procedures.

Notice:  These steps are to resolve the error in question on Exchange 2003 running on Windows Server 2003. 

Step 1.  If you haven’t already done so, you’ll need to install the Support tools for Windows Server 2003.  The tool you’ll need is ADSI Edit.  For more information on ADSI Edit, including how to install it, please visit this link

Step 2.  After following the steps in the link in step 1 to get ADSI Edit up and going, navigate to the following location in ADSI Edit:

Configuration >


          Microsoft Exchange>

               Domain Name>

                    Administrative Groups>

                         First Administrative Group>


                                   Server Name>





Right click on Exadmin and choose properties.  Your screen should look something like this (I blotted out the client’s server name hence the red mark):


If the property for msExchSecureBindings is 443, double click on the setting and remove it.  You want the msExchSecureBindings setting to be <Not Set> as my screenshot shows.  Once you make the change, OK out and close ADSI Edit.

Step 3.  Restart the Exchange System Attendant and then restart the IIS Admin Service.

Once all the services are restarted, you should be able to administer public folders from the Exchange System Manager again.

If you still have some Exchange 2003 boxen running around, like I’m sure many of you do, you may wish to add this to your list of fixes.


Quick Intro to the Juniper SRX Series Security Services Gateway Part IV

In Part III of our Quick Intro Series (don’t forget Part I and Part II), we discussed getting the SRX up quickly as a basic router.  We did, unfortunately, skip over some pretty important details along the way such as interfaces and things like that.  In this fourth part of our series, we’ll look at some of the other details of the SRX Series Gateway and introduce some additional terms one must know.

One of the things I mentioned in Part III when setting up the SRX for first use was the setting for fe-0/0/0.  Well, what is fe-0/0/0?  Let’s take a look at the ports on front of the machine:

The first ethernet-looking slot you see is the console slot that you can use a console cable to connect with and communicate with the device using Hyper Terminal.  The actual ethernet slots are the ones out to the right of the console slot and they are labeled 00 – 07.  For the Juniper SRX, the slots – interfaces as they will be called from now on – are represented by a naming scheme that describes them in detail.  The following breaks it down:

fe-0/0/0 – media type

fe-0/0/0 – Flexible PIC concentrator number

fe-0/0/0 – Physical Interface Card number

fe-0/0/0 – Port number

Obviously, for a device as small as the SRX100, we will never have to worry about the Flexible PIC number or the Physical Interface Card number ever getting above zero.  On the larger datacenter devices which may have rows and rows of interfaces, I’m pretty sure things get interesting real fast.  Let’s take a quick look at media types – the prefix of the interface name:

fe – Fast Ethernet 10/100

ge – Gigabit Ethernet 10/100/1000

xe – 10 Gigabit Ethernet

tl – T1

The media type tells what kind of interface it is.  The SRX100 is fe only which means all interfaces are 10/100 only.  The SRX210 has two Gigabit Ethernet interfaces (ge) and the rest are Ethernet (fe).  Obviously, you’ll need to go to the higher end models to get the higher end Interfaces.  I’ll not be covering all that here since my concentration is mostly going to be on the SRX100 and SRX210 for the branch office (I do not work at a large school/corporation etc. that will utilize one of the bigger models – that and I could only afford an SRX100 for my house.  Smile)

Each physical interface can have many logical interfaces applied to it.  A Logical Interface is an entity with a protocol or suite of protocols, and perhaps a network address, assigned to it.  The Logical Interface is known as a Unit.  A Unit contains protocol definition and each physical interface can have up to 16,000 Units applied to it.  Each Unit has a Family.  A Family is a protocol configuration (Family of protocols).  Here are some examples of Families:

inet – IPv4 network

inet6 – IPv6 network

ethernet-switching – switching protocol if you want this physical interface to just be used in a switch

PPPoE – Protocol used by DSL providers

Here are some examples of Logical Interface configurations:

  • First Physical Interface set with a static IP address
fe-0/0/0 {
           unit 0 {
                 family inet {

This would be a typical configuration used to set this Interface up to work with a static IP address assigned by your ISP.

fe-0/0/2 {
           unit 0 {
                 family ethernet-switching {
                           members vlan-trust;

In this example, we have set another interface up as a switching port on a Virtual LAN called “trust”.  You will see the words “trust” and “untrust” used quite a bit in the SRX documentation.  While you may name a VLAN or security zone anything you wish, “trust” and “untrust” are typically used to represent your local area network and Internet connection, respectively.

We now know that each port, or slot, on the front of the SRX is called an Interface.  We now also know that we can assign Logical Interfaces to Physical Interfaces.  Logical Interfaces include protocol families such as IP settings for different media or to merely have the port act as a switch.  For example, you could assign the necessary protocols, such as a static IP or DHCP if you don’t have a static IP, to your fe-0/0/0 for connection to your ISP and then have fe-0/0/1 – fe-0/0/7 set up as switching ports so you can plug your computers into those interfaces.  Below is how this typical configuration would look in the command line interface of the SRX:


Notice that, in the above example, fe-0/0/1 – fe0/0/7 are all members of a vlan called trust.  You could assign each interface to a different vlan (trust1, trust2, trust3, etc.) with DHCP as a service for each one thereby placing every device connected to those interfaces on its own subnet.  Believe me, the fun don’t stop there!  I’ll have examples in future posts.

In our next blog post, we will cover the concept of Zones in the SRX which will end our Quick Intro series to the Juniper SRX.  Further blog posts will cover more in-depth topics.


Windows Server 2012 Hyper-V Host Memory Sizing

My good friend, Aidan Finn, has a post on his blog about Host Memory Sizing for Windows Server 2012 Hyper-V.  In his post, he makes this statement:

Microsoft says that the Management OS should have at least 512 MB. That’s being a bit ambitious; I go with 2 GB when I size.

I’m afraid I’m going to have to disagree.  As I posted earlier, I recommend FOUR GB of RAM for the host at an absolute minimum.  My reasoning is very simple:  While I know we all go out of our way to make certain the host is only running Hyper-V, that isn’t always true.  We do sometimes have other things we must do.  And we all know how Windows loves RAM.  Maybe an update is RAM hungry whilst being installed.  Maybe you have automated scripts that run.  Something.  Anything.  Doesn’t matter.  The point is that the last thing we want is the host running low on juice.  And, RAM is cheap so there are no excuses. 

That being said, do let me be clear that my disagreeing with Aidan is not something I do lightly.  Aidan is a great guy, a good friend, and a renowned expert in virtualization.  He is also a published author with two books here and here at  Please feel free to follow everything else he does without question and without hesitation.


Visual Basic 6.0: The COBOL of Our Time

I remember back in the 90’s when those in the technology industry were decrying COBOL and how much of our infrastructure ran on that aging platform.  This, of course, was exacerbated by the Y2K bug as the rollover to the year 2000 really put a face on just how old COBOL really was/is (2000 put that face on many other things as well).

Enter Visual Basic 6.0 – also known as VB6.  VB6 was released by Microsoft in 1998 as part of Visual Studio 6.0.  VB6 had several shortcomings.  Among them:

  • Not a fully featured object-oriented programming language.  VB6 did not fully implement inheritance, for example.
  • Not a stable programming environment.  VB6 would sometimes crash costing the programmer hours of work if it was not already saved.
  • VB6 allowed many dangerous programming habits.  For example, the way it treated NULLS and its implicit type casting.

Despite all these failings, VB6 was used by tens of thousands of programmers for projects ranging from small calculator programs to software that, even today, runs major businesses – including banking.  Because of its simplicity and the way it hid so many of the more difficult aspects of programming, VB6 allowed people who never would have given programming a second thought the chance to create major software.  In VB6, you were never expected to handle pointers, do recursion, or do your own garbage collection.  VB6 hid all those things from you.  With such ease-of-use that allowed even mediocre programmers to develop complex programs with user friendly graphical user interfaces, it is no wonder that there are probably millions of lines of code written in VB6 running today.  It was cheap and easy to get otherwise hard stuff done. 

But, like all other things in the computer world, life moves on – very quickly.  VB6 was replaced by Visual Basic .Net in 2002.  Today, Visual Basic 2012 is about to be released in a couple more months.  Looking at Visual Basic 6.0 side-by-side with Visual Basic .Net is like looking at night and day.  Visual Basic .Net is a fully object oriented programming language with all the modern bells and whistles that come with that title.  Indeed, VB .Net is right on par with other languages such as C++, Java, and C#.

However, what about all those programs written in VB6?  Many of them – too many – are still here.  Major corporations such as Corning, Guildford Mills, General Motors, etc. still have entire sections of infrastructure based on VB6.  Those sections of infrastructure have been in use for years and years.  It’s very difficult to incur expense in the form of not only new programming talent, but also in the form of downtime to replace these sections of infrastructure that have been running for years and years.  Not only that, but in many cases the original programmers aren’t around anymore.  They’ve either quit, retired, or gotten laid off and refused to come back when the company realized the mistake of letting them go.  So now we have entire sections of infrastructure to maintain, and try to replace, yet those with the experience on how it all runs are no where to be found. 

The same thing happened with COBOL.  And, yes, COBOL is still in use today.  VB6 is truly the COBOL of our time because it was good at what it did.  It allowed people, even those that weren’t good programmers, to come up with simple solutions to hard problems without breaking the piggy bank.  Something tells me that in the year 2020, VB6 will still be here.