It remains completely possible to move data from some of the oldest legacy Books and Advanced Accounting versions to the latest release. But there are challenges. And in this case, even though the software had not been customized (one of the reasons why sometimes users don't move forward into new versions and which can pose an additional considerable challenge), more obstacles than might have been expected were encountered.
Challenges and obstacles:
Just to move a Books 2.04 system forward is a somewhat tricky task even when everything works exactly the way it should. And in this case, it initially did not.
Program age and limited feature set: Books 2.04 (Copyright 1988 Business Tools Inc.) was based on the TAS Professional 3.0 application development system (Copyright 1986-1988 Business Tools Inc.). It had a reduced feature set compared to Advanced Accounting 3.0 which was also based on TAS 3.0. The latest tas.exe executable file in the 3.0 series was dated October 30, 1991 and this was the executable in place on this Books 2.04 end user system.
Books 2.04 was the next upgrade in the evolutionary line after the prior TAS-Books system developed using TAS-Plus 2.0 (both Copyright 1986 Business Tools, Inc.), and it was still using Btrieve 4.11b (Copyright 1982, 1988 Novell) dated February 29, 1988, which loaded as a TSR usually in a batch file prior to calling the tas.exe executable. Orders in fact had been entered and processed earlier in this month.
 |
| Books 2.04 |
Dictionary files were unexpectedly corrupt: In moving a legacy system forward, a Books 2.04 or Advanced Accounting 3.0 system must first be converted (in terms of its data; the program themselves are not converted but rather updated and replaced via software upgrade installations) to Advanced Accounting 5.1 (versions 4.0 and 5.0 can be skipped in terms of data conversion). An even older system such as TAS-Books 1.02 would have to first be converted to a TAS 3.0 based system. With over 20 years of use, some data files might be expected to become corrupt. None however appeared to be in this case. In running the standard conversion process to Advanced Accounting 5.1 after making the necessary preparations, we ran into an unusual problem: the conversion process was clearly going through each file and converting each record, yet every single record saved into the 5.1 version was blank. Yet there were no error messages encountered during the conversion process. This is not behavior that we had previously experienced.
After a lot of troubleshooting and trial and error, we finally realized that the TASDICT.M file (version 3.0 based systems have *.M* data files; later versions starting with version 4.0 have *.B* file extensions) was corrupt after trying to reindex it in several different ways including using the Pervasive rebuild utility: This was true of both dictionary files required in this version to support the two different sets of company data that were converted, and even though the last date stamp of these files was January 30, 1998. The dictionary (and location) files do not change on a regular basis and there was no reason to expect that they were corrupt. And in fact, it is rare for dictionary files to ever become corrupt in any version.
Yet the results of a Pervasive rebuild indicated that both the dictionary files (one for each company) in fact were bad.
The rebuild operation start time is 05/20/17 12:22:58.
rbldcli -c -sK -pP -f6 C:\books\tasdict.m
REBUILD-20: The utility is processing C:\books\tasdict.m.
REBUILD-68: Status code 2 was returned while copying records from the following file:
C:\books\tasdict.m.
REBUILD rejected a total of 645 records.
REBUILD copied a total of 90 records.
REBUILD rebuilt a total of 0 indexes.
The rebuild operation end time is 05/20/17 12:22:58.
Another symptom of corruption was the fact that the "maintain database" program could not find its matching field records when attempting to use it for any desired file. The dictionary files that define fields and tables otherwise remain static and aren't even opened and used in any way by older versions including through version 5.1 other than the location file. So the problem of the corrupt dictionary files wouldn't have caused any end user problems unless the user needed to use the maintain database option (which apparently they did not) or in the conversion process that was now desired.
Since the dictionary files could not be repaired or at least not easily, we then had to hunt for a replacement. We no longer have an installation package that we could find for a standard Books 2.04 system. We would not expect the user to have a backup from before 1998 of the afflicted file. But, we found one in connection with an old project. And we determined that with the replaced file, the conversion did work; except, the TASDICT.M replacement file had layouts that had been customized which created problems until some of those changed layouts were changed back to match the standard Books 2.04 system being converted.
Post 5.1 conversion problems: Because of limitations of Books 2.04, a special utility that we completed in May of 1999 (named BKBK20) has to be run to move posted sales order invoices out of the pending file into historical files, among other things. That program has to be run in each converted company. That worked as expected.
However, a serious year 2000 (Y2K ) issue remained, and one that was anticipated. Books 2.0 and Advanced Accounting 3.0 were not Y2K compliant because of the century problem engendered by the use of short dates, i.e. a system using short dates in the MM/DD/YY or other similar short year format has to make an assumption as to what the current sliding century is based on. And legacy development systems such as TAS 3.0, simply used a 1900 to 1999 century period meaning that a date entered as 01/01/00 would be interpreted as a 1900 date. This though was not a problem of the Btrieve record manager engine (which has always saved dates as long dates, never as short dates and this is still true with the more modern Pervasive systems) but in interpretation of a short date century by the implementing software (in this case, tas.exe). While attempts were made by Business Tools to effect Y2K changes in later versions, only version 5.1 became the first Y2K compliant version in terms of fully and correctly interpreting dates entered in the 21st century (well, for at least the first 20 years of the new centruy; the sliding century for versions newer than 5.1 is much greater).
Users of versions prior to 5.1 who did not upgrade their software by January 1, 2000 typically were customized users who in anticipation of a Y2K problem had TAS 3.0 developers change every "short date" to a "long date" in their system. This is not the approach taken to solve the issue in the newer Advanced Accounting series that continues to use short dates for date entry (which saves users entry item and leads to fewer entry errors) but it was the solution of choice in customized TAS 3.0 systems (it was not however the only choice, but typically the only option that was commonly implemented). And there are many dates that had to be changed including changing all of the internal temporary date fields and all of the screens with dates on them had to be addressed including sometimes placing that date in a slightly different position to accommodate the extra two digits. Lots of tedious work was involved. So it was not a trivial undertaking also because every single program using a short date would then also have to be recompiled along with changes every single screen or report "mounted" by that program, and lookup lists also requiring realignment for the extra two digits and so forth, and then tested.
This Books 2.04 user had decided to roll the dice and live with whatever consequences came their way in terms of the Y2K issue. This did not mean that their system stopped functioning as of January 1, 2000, a system that they continued to then use for an additional 16+ years past that data. But it did mean that the system did not "understand" that a "99" date and prior was older than a "00" date which would have led to problems in posting things into a prior year, customer aging lists, all reports that included any prior year dates in a date range, etc. In the year 2000 itself, there would be been lots of problems. As time went on though and years passed, the fact that the system was not Y2K compliant meant very little and the software would have had all of the appearance of working exactly as it did prior to the turn of the century.
But given all of the data that was dated on/after January 1, 2000 intending to be in a new century and not the old one, and given that this information was now going to be contained in a system that was Y2K compliant, the date problem had to be fixed. Using in part a utility we had written to address this issue, the century problem in the underlying short date data was fixed so that dates would sort and behave as expected.
There were also some GL and other technical setup issues that had to be resolved. And finally, we had a Books 2.04 system converted to Adv 5.1
 |
| Advanced Accounting 5.1 |
Final phase to Adv 7i: From here, standard tools we developed going back to 2004 and enhanced since then were used to move the 5.1 converted data for two companies to the latest version. This involves a series of steps, but all went very quickly and very smoothly.
And so finally the system was ready for use, containing all of the customer, inventory and sales history data from the Books 2.04 system.
 |
| Advanced Accounting 7i |
No comments:
Post a Comment