When It s Time to Move On: Migration Issues

A great deal of work currently being carried out in the Visual Basic world is the rewriting of applications previously written in the earlier versions of the language. This section looks at the differences between the various versions of the language and some of the date issues you can encounter. The table below summarizes of the date-handling features of the different versions of Visual Basic.

Visual Basic Version	Date Data Type?	New Functions	Date Window	Other Issues
1	No	DateValue, DateSerial, IsDate, Day, Month, Year, Weekday, Date($), Now, TimeValue, TimeSerial, Hour, Minute, Second, Time($), Timer, Format($)	1900-1999	No native date storage. Dates either stored as Strings or Doubles.
2	Variant (Type 7)	CVDate	1900-1999
3	Variant (Type 7)	DateDiff, DateAdd, DatePart	1900-1999
4 (16-bit)	Date	CDate, Weekday, and DatePart updated to include optional FirstDayOfWeek and FirstWeekOfYear argument.	Current Century
4 (32-bit)	Date	CDate, Weekday, and DatePart updated to include optional FirstDayOfWeek and FirstWeekOfYear argument.	OLEAUT32	DateSerial does not use OLEAUT32; it uses a current century window similar to 16-bit version 4.
5	Date		OLEAUT32
6	Date	FormatDateTime, MonthName, WeekdayName	OLEAUT32

The basic split is between the 16-bit and 32-bit versions of the language. If you are migrating your code from a previous 32-bit version of the language, the date logic will work unchanged. However, if you are moving from a 16-bit version, there are some differences. The most significant difference is the complete lack of a built-in Date data type in the first version.

NOTE

---

The 32-bit implementation of Visual Basic 4 has a strange anomaly. In this implementation the DateSerial function does not use the same date window as the CDate and CVDate functions, provided by OLEAUT32. DateSerial uses the same current century window as the 16-bit implementation of version 4. This is the only time in all the versions of Visual Basic that these functions might provide different results.

If you are migrating your code from Visual Basic 1 to Visual Basic 6, you will most likely have to deal with date storage based around Strings, with any manipulation logic having been hand-written. The quality of this logic will very much depend on the original author, but it should always be treated with suspicion. It is guilty until proven innocent, because this code would have been written in the late eighties and early nineties, when the world was only just starting to wake up to the Y2K problem. At the very least, the leap year logic will be suspect.

Migrating from code written in Visual Basic 2 and Visual Basic 3 will be more common than from Visual Basic 1. Here you might be lucky: when well written, code in these versions can be very compliant. The Variant data type did (and still does) store dates in the same format as the newer Date data type. These versions have the full complement of supporting conversion and manipulation functions. Unfortunately, there has been a real lack of awareness of the Variant type's existence for use with dates. Just as with code from Visual Basic 1, you might have to work with code that stores dates in Strings. I still come across very recent Visual Basic 3 code that is not in the least bit Year 2000 compliant (in some cases within compliance projects!).

If you have been lucky and the original author used the Variant data type, be aware of the original date window. These versions will always assume the 20th century for ambiguous dates. Any code that relies on this behavior will be in for a surprise when ported to the latest version.

Visual Basic 4 is easier to migrate from than the previous three versions. This one supports the Date data type, and from my experience most code will have been written using it. Here the only issue is the date window. The 16-bit implementation of this version uses a date window that assumes the current century for an ambiguous date. The 32-bit version uses the window provided by OLEAUT32, although at the time of this version's release OLEAUT32 also assumed current century.

There is no real difference between Visual Basic 5 and Visual Basic 6 in terms of date usage other than the additional functions and controls available to you in version 6.

In all cases, any code you port will be as good as the original author's. We have had the tools to store and manipulate dates since version 3; however, these tools have not always been used. Even today noncompliant applications are still being produced.

What to Look Out for When Renovating Old Code

This section lists a few of the problems that can crop up when you're updating existing code.

Sorting on dates

Sorting dates will be one of the main areas where noncompliant date formats will become readily apparent to anybody. If we take, for example, the YYMMDD alphanumeric date format, it is fairly obvious that when this format starts finding dates with the year 00 these are going to be sorted before all other years. Sorting reports or displays on dates is not an uncommon feature of computer systems. This can generally be thought of as a cosmetic problem, but it can be a very visible barometer of more serious and far less visible problems lurking beneath the surface.

Dates manipulated as strings

When reviewing code written in the earlier versions of Visual Basic, we often see date manipulations carried out on Strings. Take the following piece of code:

Dim dteMyDate    As Date Dim nYear        As Integer dteMyDate = Now nYear = Val(Right$(Format$(dteMyDate, "Long Date"), 4)) If nYear > 1999 Then     MsgBox "Welcome to the Twenty First Century!" End If 

This will work, unless of course somebody has changed the format of the Long Date in the regional settings of the Control Panel. If the original programmer was more enlightened, you might see something like this:

nYear = Val(Format$(dteMyDate, "yyyy")) 

Here the programmer is explicitly stating the format in which he or she would like the date to be used. If you are really lucky you might actually see the following code, which correctly avoids the conversion to a String altogether by employing Visual Basic's Year function:

nYear = Year(dteMyDate) 

Using Visual Basic's Find dialog box can be quite revealing here. Just searching on Long Date, Short Date, Mid, Right, Left, and Format—while somewhat indiscriminate—can be very revealing. The first example above is not uncommon.

Most of the compliance problems in Visual Basic applications can eventually lead us back to the manipulation of dates as strings. This must be treated with extreme mistrust. Your first task when renovating this code must be to replace this code based around strings with the built-in date functions operating on Date data types.

Look for dates used as magic numbers

Magic number dates are date values that are used as a system indicator. Dates such as 9/9/99, 12/31/99, or 999999 are common examples. These might be used to indicate such things as records that never expire, locked or deleted records, or records that must always be displayed at the start or end of a list. They work fine until the magic date occurs, then all sorts of strange behavior can follow. Again, by using the Find dialog box, searching for these strings can be most illuminating.

Testing

Without a doubt, the Y2K problem has highlighted the importance of testing. Even if you don't convert any code, you should, at the very least, test all your Visual Basic applications to ensure that they are Year 2000 compliant.

If you have made changes, perform regression testing wherever possible, using the original test scripts for each application. If you don't have access to the original test scripts, you should attempt to test the functionality of the entire application, regardless of whether certain functionality uses date processing. This step is necessary because various changes at any level of the application could have a domino effect (for any number of reasons) on any other application functionality. Testing only the changes is not good enough.

Ensure that all test conditions and the results from all testing are well documented. The testing tasks and issues described in the following subsections might help you formulate your testing plan.

Test the user interface and third-party controls

As I have mentioned, calendar controls are at the top of the hit list for potential Y2K horror stories. There are too many commercial calendar controls for this book to cover individually, and I wouldn't be surprised if many of the existing calendars are updated to new versions fairly soon.

So if your application uses a calendar, and even if you have a new Year 2000 compliant version of that calendar, give it a good hammering. Test all conceivable scenarios. Leave no stone unturned. When testing the user interface there are a number of key dates you should test in as many different formats as possible. The table below shows a list of dates that you should use in your testing.

Valid		Invalid	Ambiguous
Dec 31 1998	Jan 1 1999	Feb 29 1900	Jan 1 00
Feb 27 1999	Feb 28 1999	Feb 29 1999	Jan 1 99
Mar 1 1999	Sep 9 1999	Feb 30 2000	Feb 29 00
Dec 31 1999	Jan 1 2000	Feb 29 2001	Jan 1 29
Feb 28 2000	Feb 29 2000	Feb 30 2004	Jan 1 30
Mar 1 2000	Dec 31 2000
Jan 1 2001	Feb 28 2001
Mar 1 2001	Feb 28 2004
Feb 29 2004	Mar 1 2004

Test Data and Conditions

Testing for the Year 2000 problem won't be like any testing that you've done before. Here's why: in order to be 100 percent certain that your business can survive into the year 2000, you'll need to execute three completely separate system tests dealing with three sets of test data, and more than likely (depending on the size of your organization), each of these three tests will be in a different testing environment.

Regression testing of today's production environment

Having made changes to your current system, your next task is to test that all programs function as expected for the current time frame. In other words, you want to be certain that your business can continue to use its Visual Basic applications with no unexpected side effects.

In effect, this test will ensure that the systems work exactly as they did when they were originally built. This test might sound counterproductive to begin with, but it's no good announcing to the world that all your applications are Year 2000 compliant if they come crashing to their knees!

Future date testing

Having verified that your system functions correctly in the present, you'll need to create a second set of test data that will test your system's ability to cope with dates on either side of the year 2000. The particulars for this test will depend entirely on the business nature of your applications.

For example, let's suppose that your Visual Basic application maintains car insurance policies, which typically can have a life cycle of 12 months. You'll need to set your system clock to some time in 1999 and run your tests, this time looking specifically for the application's ability to process car insurance policies that will expire in the year 2000.

Your business might have a shorter future date requirement, such as a long-term car parking system that has a maximum life cycle of 6 months. In this case, you would need to ensure that the system date is set to at least August 1999 so that you can adequately test processing into the year 2000.

And the list goes on. Make sure you thoroughly understand the future date capabilities and scope of your system. Then run your system so that it is forced to process future dates that are at least in the year 2000, if not later.

Running your system in the future

The final test involves gauging the ability of your applications to function in and beyond the year 2000. Set your system date to some time beyond 2000, and run your original test scripts. Don't forget that if your system processes historical information, you should have test conditions in which you set your system clock beyond 2000, and then force your applications to look at dates before 2000.

Leap years

Include in all three of your system tests conditions that will force your application to process the last two days in February and the first two days in March. The year 2000 is a leap year, which means that February 29 2000 is a valid date. Don't be caught out by this one. I've seen much debate from mathematicians and rocket scientists on the correct way to calculate leap years, and I've naturally researched the subject myself thoroughly enough to conclude that 2000 is a leap year. In fact, I nearly had a fight with my neighbor the other day because he wouldn't accept that February has 29 days in the year 2000!

The point I'm trying to make here is that if superhumans and neighbors can disagree on the number of days in February 2000, so can programmers! It's possible that during the development of your Visual Basic applications, a programmer might have manually calculated (incorrectly) that the year 2000 is not a leap year, so be sure to test for it.

Recommended system dates

If you're lucky (or wise), you'll have already built automated testing procedures that don't require too much manual intervention. Otherwise, somebody is going to get very sore fingers! In a perfect world, I would suggest running your complete system test against the following system date years: 1998, 1999, 2000, 2001, 2002, 2007.

Change Your System Date

Before we get into the techniques involved in changing your system date, be warned! Some system resources and functions are date- and time-sensitive and might be switched on or off when you change the system date. Before changing your system date, make sure that you understand all of the consequences. Better still, consult an expert first.

The tests you carry out with regard to the system date serve dual purposes. Not only are you testing the ability of your applications to function correctly in the year 2000 and beyond, you are also testing how well your hardware will cope with the change. Although the hardware issue is outside the scope of this chapter, it's still an important concern, because without the hardware… say no more!

In many cases, your system date will come from one of three places: from a date value in your database, from the clock on your server, or from the clock on your PC. Retrieving the current system date from the database is a very wise move. If your Visual Basic applications do this, resetting your system date is simply a matter of changing the value in the database. That's all there is to it. But you'll still need to test the ability of your machines to function in the year 2000, and we'll look at the steps involved with that in a moment.

If your applications retrieve the system date from the PC's clock and the PC is connected to a network, chances are that your workstation retrieves its system date from the server. In this case, you should definitely consult your network administrator about changing the system date. There is one way of changing the system date without being affected by the network, and that is to disconnect the PC from the network. If you disconnect your PC, however, you will probably defeat the whole purpose of the exercise, especially with regard to testing the hardware.

If your system date is retrieved only from the PC's clock, consider the fact that on some older PCs you might not be able to set the clock beyond the year 2000. This is because the BIOS doesn't know about centuries. Whatever the case, you should run the following two tests on your PC to judge both your application's functionality and your hardware's capabilities.

System clock automatic update test

In most cases, when the clock rolls over to start the year 2000, most of us will be popping party balloons, singing, and hugging loved ones (or as Mark Mayes said in the last edition, lying at the bottom of the garden caressing an empty bottle of vodka!). I expect very few office PCs will actually be turned on over the New Year's holiday (although it has been suggested that companies should leave them on just in case), and even fewer Visual Basic applications will be running. In the spirit of completeness, however, you should test to find out whether your PC's clock will actually roll over. To do so, follow these steps:

1. Using the DOS DATE function, set the PC's date to 12/31/1999.

2. Using the DOS TIME function, set the PC's clock to 11:58:00.00.

3. Keep the power on.

4. Wait until the clock passes midnight.

5. Check the date to ensure that it is 01/01/2000.

6. Test your Visual Basic application (if appropriate).

7. Turn off the power.

8. Wait for a while.

9. Turn on the power.

10. Check the date to ensure that it is still 01/01/2000.

11. Just for good measure, test your Visual Basic application again (if appropriate).

System clock automatic update test after a power down

The more likely scenario is that all office workers will go home on the evening of Friday, December 31, 1999, having switched off their machines, and will return on Tuesday, January 4, 2000. To ensure that the PC's clock will have successfully moved on to the correct date while the power was down, perform the following test:

1. Using the DOS DATE function, set the PC's date to 12/31/1999.

2. Using the DOS TIME function, set the PC's clock to 11:58:00.00.

3. Turn off the power.

4. Wait at least three minutes.

5. Turn on the power.

6. Check the date to ensure that it is January 1 2000.

7. Test your Visual Basic application (if appropriate).

There are countless more tasks and issues concerned with testing for Year 2000 compliance. I hope the issues I've raised will set you on your path toward creating the perfect test plan. The important thing is to be sensible about testing. Consider all possible scenarios, and don't cut corners.

Consider Third-Party Tools

With the deadline now looming dangerously close, companies are finding themselves working with very tight project deadlines in their migration and renovation projects. Time spent reviewing some of the available third-party tools can pay real dividends. While none of them should be considered a one stop "silver bullet," they can seriously affect your productivity. Tools such as Visual DateScope 2000 from Class Solutions Ltd. (see Appendix D for a full description) can provide you with just the edge you need when it comes to meeting that deadline.