Issues with older VB 6 apps

How old is your LIMS Software?

Do you know what programming language your LIMS was written in? If it was a homegrown LIMS app? Is your LIMS an affordable LIMS software package from a professional LIMS vendor? Is it "old", like turn of the century? Is it specifically a LIMS for a small lab situation?

If your answers to any of these questions is "yes", chances are it is either a VB 6 app or an MS Access app.

If either of this possibilities are true in your case, you may be sleeping on a currently inactive volcano.

Why is that?

Because when a LIMS is being built it is usually tested with some data, but not necessarily thousands of records.  This is simply reality. Ask any software developer (after a few drinks).  Note: Almost all software developers drink...

Because of the reality of not developing a system with thousands of records, there are two things that will inevitably not be checked:

• Performance
• Overflow Errors

The first one, performance, is obvious, things run aster with only 500 records, than they will with 500,000 records.

The next issue though, "Overflow Errors" is a programming term. It has to do with programming "data types". Back in the old days, when a hard drive was a microscopic 64K, and RAM was extremely limited, you had to be careful how you used programming variables. The trick was to use the tightest or smallest data type for each specific variable, so as not to chew up RAM.

Note: Nowadays, this is really a non-issue. We have more RAN and disk space then even Gene Roddenberry or George Lucas could have imagined.

An example of this data type situation are two choices for storing whole number values. One is referred to as an "integer" and the other data type is called a "long". An integer variable can hold 16 bits of data, or 2^16. Since half of the values are negative, the positive range is really 2^15, or 32,768. A long is 2^32 (or 2^31 for positive numbers) and can go up to 2,147,483,648. It is twice as big to the computer, but in reality the long data type has a limit that is sixty five thousand times larger than an integer datatype.

So what does this mean?

If you are using a numeric data type in either VB 6 or MS Access (VBA) to hold a numeric value, then you have to give some thought as to which datatype you will use. If you are just assigning a number to items in a short list, like the fifty states, an integer data type will be fine. However if you are assigning a number that is equal to the amount of people that live in Virginia, then an integer will run out of space, since it can only go up to 32,768. If you try to set an integer variable to a number greater than 32,768, then BAM! you get an overflow error.

Why would anyone use an integer datatype then? It's habit. Kids in college were taught to use integer datatypes all the time in VB 6 classes. All the books used them too.  

It usually takes a seasoned LIMS software developer to realize that there will always be portions of code that can get by with an integer, most of the time, until you have that one special custoemr (lab) that does things a little differently. A table that usually has a few hundred records now has over forty thousand records. When they go to do anything in the system where an integer datatype is set to a value of 40,000 or so, it blows up.

Newer developers never consider this, due to lack of experience. Also, they are testing with databases that are nearly empty.  You really have to assume that any whole number based variable will surpass (or could surpass) 32,768. It actually takes less time to declare a variable as a "long" than an "integer" because there are less key strokes.

if you have an older VB 6 app or an older MS Access app, then I GUARANTEE you, it will eventually blow up, because of the integer / long scenario.

I just ran into this with a lab in Utah, and had to due a major work around for them since the program they have is compiled and they are not able to get a newer compiled version. Ouch.

They had a table that grew by a few hundred records a month. It took several years, but finally, this table grew beyond 32,768 records and then different things in the app started to break.

What can you do?

Upgrade your LIMS now to a nice juicy .NET app or even a web app. Be proactive. Don't sit back and wait for your ancient app to break, because break it will.

Make sure you know what is is you are looking for in your next LIMS.

You want your coffers to overflow, not you LIMS software application!