Once again your intrepid consultant was called to an AREV/32 conversion of a system running a small business for decades on an AREV system. The majority of the actual work was performed by Martyn back at the office as he wished to
He succeeded on both points but at the same time underlined why a little consultancy help can occasionally come in handy.
In preparation for this I burned all of the files I was going to need onto DVD using what Microsoft refer to as "Live File System". (Incidentally does anyone else get annoyed by Microsoft's habit of inventing their own acronyms for things? The world and his wife refers to "Live File System" as "Universal Disk Format" or UDF. Even windows.microsoft.com says "Learn about the Live File System (UDF) and Mastered disc formats"). My Windows 7 software ASSURED me that this would be readable on any machine from XP on.
Being a trusting individual I also took my laptop and a 64GB USB stick to the site.
So to the designated XP workstation to copy the UD47 files to the server. The DVD is inserted and up pops a dialog suggesting that we format the CD so that it is useable. Pop out the DVD and check the front of the player - yup CD/DVD - it just doesn't want to play.
Back to the laptop and copy the files on to the USB stick and insert and.... nothing. It seems that beyond a certain size XP sees a USB Stick as a Drive not a storage device and won't play without special drivers.
The client springs to the rescue and provides a branded USB stick. Which isn't big enough.
Fortunately the client then remembers their second generation USB sticks which ARE big enough. With that sorted UD47 is soon installed on the server and the converted AREV32 app is up and running.
Except it isn't. It all works fine until lookups are performed on an XREF field. On the AREV system using a specific keyword returns hundreds of matches. On the AREV32 system using the same keyword only one. The indexes are rebuilt and - the same. So into the system monitor and "LIST 20 TABLENAME COLUMN_XREF". What comes out is NOT what we're expecting to see at all. It's a series of word fragments bearing no relation to the words in the primary column. It's a wonder we're finding anything!
So I did what any self respecting consultant would do and checked the XREF formula where I was surprised to find a delimiter string of
\537061632C2D2E\
rather than the
\202C2D2E\
I was expecting.
Referring back to the original AREV system it became apparent that the original developer had declared the delimiters as "Space,-. " not "SPACE,-." and AREV32 was not as forgiving when converting over and had treated the S p a c and e as delimiters to parse the XREF on.
Deleting the index and readding rectified the issue BUT the issue was present in every XREF index on the system. So a quick scan of SYSCOLUMNS identified all the likely culprits and some time was spent tracking down, removing and rebuilding every XREF index on the system.
Then it was time to sign off on reports. By now time was beginning to run out so things had to be done quickly. And of course when time is limited, life likes to throw curve balls. "Well this set of reports need to come out on this printer as it uses this special stationery and this set need to come out on this printer as it uses this other special stationery". OK let's just check the Windows printer definitions. Oh it's not actually in the Devices panel as they're attached to the parallel port and the reports are hard coded for the escape sequences required for that printer.
DirectPrint looked like a likely option BUT there were so many reports to convert that time would run out. Thanking TPTB that I started way back when DOS was at version 1.0 I recalled that as far at the system is concerned the printer on the parallel port is just a file, "LPT1".
So a quick global replace of the "PRINT" in statements such as this
PRINT Var1 "L#10" : " " : Oconv( var2, "D2/E") "R#8" etc
with "printVariable := CRLF$ :" like this
printVariable := CRLF$ : Var1 "L#10" : " " : Oconv( var2, "D2/E") "R#8" etc
a trim of the leading CRLF$, a tidy up and an OSWRITE printVariable on "LPT1" and all worked as before.
All that was left to do was to copy just the data from the old system, decommission it and go live with the new system. That at least went without incident!
-
a) hone his AREV/32 skills and
b) show how straightforward the majority of conversions are.
He succeeded on both points but at the same time underlined why a little consultancy help can occasionally come in handy.
In preparation for this I burned all of the files I was going to need onto DVD using what Microsoft refer to as "Live File System". (Incidentally does anyone else get annoyed by Microsoft's habit of inventing their own acronyms for things? The world and his wife refers to "Live File System" as "Universal Disk Format" or UDF. Even windows.microsoft.com says "Learn about the Live File System (UDF) and Mastered disc formats"). My Windows 7 software ASSURED me that this would be readable on any machine from XP on.
Being a trusting individual I also took my laptop and a 64GB USB stick to the site.
So to the designated XP workstation to copy the UD47 files to the server. The DVD is inserted and up pops a dialog suggesting that we format the CD so that it is useable. Pop out the DVD and check the front of the player - yup CD/DVD - it just doesn't want to play.
Back to the laptop and copy the files on to the USB stick and insert and.... nothing. It seems that beyond a certain size XP sees a USB Stick as a Drive not a storage device and won't play without special drivers.
The client springs to the rescue and provides a branded USB stick. Which isn't big enough.
Fortunately the client then remembers their second generation USB sticks which ARE big enough. With that sorted UD47 is soon installed on the server and the converted AREV32 app is up and running.
Except it isn't. It all works fine until lookups are performed on an XREF field. On the AREV system using a specific keyword returns hundreds of matches. On the AREV32 system using the same keyword only one. The indexes are rebuilt and - the same. So into the system monitor and "LIST 20 TABLENAME COLUMN_XREF". What comes out is NOT what we're expecting to see at all. It's a series of word fragments bearing no relation to the words in the primary column. It's a wonder we're finding anything!
So I did what any self respecting consultant would do and checked the XREF formula where I was surprised to find a delimiter string of
\537061632C2D2E\
rather than the
\202C2D2E\
I was expecting.
Referring back to the original AREV system it became apparent that the original developer had declared the delimiters as "Space,-. " not "SPACE,-." and AREV32 was not as forgiving when converting over and had treated the S p a c and e as delimiters to parse the XREF on.
Deleting the index and readding rectified the issue BUT the issue was present in every XREF index on the system. So a quick scan of SYSCOLUMNS identified all the likely culprits and some time was spent tracking down, removing and rebuilding every XREF index on the system.
Then it was time to sign off on reports. By now time was beginning to run out so things had to be done quickly. And of course when time is limited, life likes to throw curve balls. "Well this set of reports need to come out on this printer as it uses this special stationery and this set need to come out on this printer as it uses this other special stationery". OK let's just check the Windows printer definitions. Oh it's not actually in the Devices panel as they're attached to the parallel port and the reports are hard coded for the escape sequences required for that printer.
DirectPrint looked like a likely option BUT there were so many reports to convert that time would run out. Thanking TPTB that I started way back when DOS was at version 1.0 I recalled that as far at the system is concerned the printer on the parallel port is just a file, "LPT1".
So a quick global replace of the "PRINT" in statements such as this
PRINT Var1 "L#10" : " " : Oconv( var2, "D2/E") "R#8" etc
with "printVariable := CRLF$ :" like this
printVariable := CRLF$ : Var1 "L#10" : " " : Oconv( var2, "D2/E") "R#8" etc
a trim of the leading CRLF$, a tidy up and an OSWRITE printVariable on "LPT1" and all worked as before.
All that was left to do was to copy just the data from the old system, decommission it and go live with the new system. That at least went without incident!
| Making Databases Happen |
USA +1 267 238 3814
|