LinkExchange Network
You are here: HOME > TRENCHES INDEX > CYBERDATE 08.23.1997
Site Map

Log Index
Previous Log Entry
Next Log Entry
Christophers Napkin Sketch by Al Gleichman

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 08.23.1997 (When we last left our hero, HAL..)

    Situation Report
    Take Charge And Move Out
    United States of America
    Mission Report
Previous HAL Articles:

Cyberdate 06.14.1997 When it rains, it pours

Cyberdate 05.17.1997 HAL's softwarez feeding frenzy continues

Cyberdate 05.10.1997 HAL gets more software

Cyberdate 05.03.1997 Feeding Softwarez to HAL 9000

Cyberdate 04.19.1997 Moving the HAL 9000

Later HAL Articles:

Cyberdate 09.06.1997 Kurrent Konundrums Debut

Cyberdate 10.04.1997 Putting out brushfires

Cyberdate 10.11.1997 P2's transformation slips into high gear

Cyberdate 10.25.1997 More fun with P2, HAL and 4-Bits


Allaire Corp. HomeSite v2.5 HTML editor

America OnLine Online Service

CyberMedia First Aid 97

Inprise Corporation (formerly Borland Corporation) dBASE 5 for DOS

Microsoft Corporation Microsoft Visual FoxPro, Microsoft Internet Explorer, MSN

Mijenix Corporation PowerDesk Utilities 2.0

Quarterdeck Corporation CleanSweep v3.0, Procomm Plus.

Surplus Direct Direct Channel computer products.


SITREP: Back in May I ran into a wall while transferring database applications from my old workstation, "P2", to "HAL", my current computer (see In the trenches Cyberdate 05.17.1997 "HAL's softwarez feeding frenzy continues"). Many of my dBase IV routines had failed when running on the faster HAL. Since then, I've gotten the database applications working on HAL with some modifications. A few more software applications other than database programs were also installed since we last left HAL in May.

TACAMO: I continued to install software on HAL while pondering the solutions to my database conundrums.

InterActual World's Greatest Monuments v1.31 is a multimedia encyclopedia of the world's most famous man-made structures, statues, and landmarks. This is a CD-ROM application that shipped with HAL, so I Installed monuments with the Aptiva Installer, a utility that IBM provided for installing the software packages they bundle with their PCs. The installation only took a few minutes and completed without a hitch.

Borland dBASE v5.0 for DOS: 2:07 PM 5/19/97 Borland's dBase 5 arrived from Surplus Direct. It included four 3-1/2" diskettes and 5 manuals. It installed quickly and efficiently on Hal. I made a shortcut on the desktop. dBase 5 runs fine in a DOS Window under Windows 95 whereas dbase IV would not (Windows 95 always had to shutdown to run dbase IV and startup again afterwards to run reliably on P2). So far, so good. Copies of the company's dBase IV subdirectories and files were placed under the new dBase 5 directory and the games began. The "main" dBase IV program module ran with difficulty. I kept getting a "WRONG LANGUAGE" error dialog when the module tried to open database table files, I was also receiving indexing error messages.

My transaction updating and reporting module would choke on this "WRONG LANGUAGE" error and exit. Unfortunately, this module had been half hand-coded by myself and half generated by dBase IV's application-writing "wizard". After reviewing my code, which I had the good sense to document so many years ago, I discovered, much to my dismay, a coding syntax error in the indexing subroutines. A short history is in order here:

Previous to the introduction of dBase IV, index files could contain one index per file. These index files were distinguished by the ".NDX" extension. dBase IV introduced "multiple" index files with the ".MDX" extension while maintaining backward compatibility with the old single index file format.

If you call for an index file without specifying it's extension, dBase will default to searching for a ".NDX" index file. This was my coding mistake. dBase was not finding any multiple index files because it was looking for single index files of the same name. Once I added the ".MDX" extension to my code, the program worked without indexing errors.

The confusing thing about this problem was that it only happened randomly when the application resided on P2, and not at all on it's predecessor, "Merlin", a CompuADD 386/20MHz PC. That's why I haven't hunted it down and fixed it until now. It wasn't a "deal stopper" until running in dBase 5 on HAL.

I didn't understand the wizard-generated code that dBase IV had produced for the transaction module, so I my best short-term option (band-aid) would be to eliminate the "WRONG LANGUAGE" error that was stopping the program. The easy way to accomplish this task, without programming is to make dBase 5 tables and indexes to the same specifications as the original dBase IV tables and import the existing data records into the new tables. This is a "no-brainer", but tedious, and was to lead to new problems later on but, for now, it was the obvious solution. At any rate, this is what I did. After importing the records from the old dbase IV tables, the transaction subroutine was run. This time, it completed normally.

At this juncture, the major dbase IV applications seemed to be working in dBase 5 on HAL. I still had to test other modules of the system that were not used often, such as certain dBase reports, and the first time I ran a module that had not been run under dBase 5, there were usually unexpected "burps" or system errors. These were generally easy to fix in a half hour or less, but fearful of a big blowup which would not be resolved easily, I kept entering data in the original database on P2 and then importing new records into the database on HAL every day. This was more work, but good insurance should the new database modules on HAL not work for some Kritical application I had not tested yet. I could go back to the database on P2 in an emergency, "a bread crumb trail" to get me out of the woods.

In most of the dBase modules the drive and pathnames were "hard coded", not a good practice, but expedient. Now, since the dBase programs resided on drive E: of HAL instead of drive C: of P2, most of the modules would break when they couldn't find files they were looking for on drive C:. These "breaks" were easy to fix by opening the modules' source code files in a text editor and performing a simple search and replace procedure, substituting "E:\" for "C:\" throughout the file and recompiling the module.

FoxPro Windows 3.x v2.6: In the last session with HAL we installed QuarterDeck CleanSweep v3.0 and used it's "Transport" feature to move the FoxPro DOS v1.01 DBMS applications from P2 to HAL. That worked fairly well, so I was ready to try it with the FoxPro for Windows 3.x v2.6 applications still running on P2. This turned out to be an easier transport than FoxPro DOS had been since the main FoxPro v2.6 program modules reside on the server "Old Blue", and only the local configuration files had to be transported from P2 to HAL. Most of the FoxPro v2.6 program subroutines work with the same dBase IV (now dBase 5) files as the old dBase modules do, so the same type of drive "E:" for drive "C:" substitutions had to be made for the FoxPro subroutines that were made for the dBase modules. Preliminary experiments with the FoxPro manipulations of the new dBase 5 file structures were promising (at least, no errors were reported).

America OnLine Upgrades: 2:27 P.M. 6/6/97 AOL has been trying to download and install automatic MSIE 3.02 updates to HAL. Since I already have MSIE 3.02, and don't know what additional mischief the AOL Auto Install program might cause, I have been avoiding this by cutting the TCP/IP connection rather than quitting AOL the normal way and suffering the download. Today, I decided to let AOL have it's way (after turning on the CleanSweep SmartSweep Agent). The "patch file" download took about 20 minutes, the AOL install program started (but did not activate SmartSweep), and after a few seconds, displayed a message telling me what I already knew: I did not need the upgrade!

It was a bright, sunny, Friday in June. Although usually immune, days like this sometimes put me in a mood of restless adventure (read reckless). In the past, I would sometimes bolt from work and hit the bars along south Florida's waterways to broil under the influence of Rum runners or Corona beer and a steel band. The last time I indulged in this pastime was over five years ago, and it put me in the hoosegow overnight. I gave up alcohol on the spot. The "nectar of the gods and bane of mortals" is now off-limits to me until I get too old to drive, and I retire to the lower keys to live in a refrigerator crate next to a convenience store. That's the dream anyway. On this day I found another way to vent my restlessness. I installed Microsoft Internet Explorer 4.0 Platform Preview Edition on HAL. This is an early, not-long-out-of-alfa, raw beta that is not yet stable enough to be reliable in any way (as opposed to the late, "version 1.0", shrink-wrapped betas the public receives). Using it on my everyday workstation was indeed reckless. It was sent to me by Microsoft on CD-ROM because I belong to their developer program, and have already marked myself as a lab rat. The CD has been sitting on my desk for over a month. Today I crossed the Rubicon with it.

I scanned the Warning readme text for known bugs and other problems and took the plunge. All programs were shutdown except the CleanSweep SmartSweep Agent. The MSIE 4.0 setup program ran without incident. After the system rebooted to complete the setup, the new browser-enhanced interface displayed. Pretty neat!

Mijenix Corporation PowerDesk Utilities 2.0 would cause the First Aid 97 Guardian to stop it from performing an "illegal" action every time I tried to activate it's Windows Explorer Plus file manager utility. I uninstalled the Powerdesk Utilities. Homesite, which uses MSIE seems to work OK (except for exiting the program in "browser mode" which sometimes produces memory allocation errors). AOL 3.0 for Windows 95 and ProComm Plus FTP module also seem to work without conflict. MSN sound no longer seems to be working.

MISREP: All things considered, I haven't been punished yet by the software gods for my sloppy database programming or my brashness in installing the "bleeding-edge" MSIE 4.0 PP1 software. I will eventually have to reprogram the database using Visual FoxPro and Visual FoxExpress, but I've managed to postpone judgement day a bit longer. I feel like Mickey Mouse in Fantasia: I've got the brooms marching with the waterbuckets, but I don't know the spell I need to stop them before I drown! As for MSIE, it causes HAL to blowup on a regular basis, and I reboot him hourly just for general principles, but considering how unstable the program is at this stage I'm getting off lightly. Even Microsoft recommends that it be installed on a test machine and not your "daily driver", and I've read some true horror stories in the newsgroups devoted to MSIE 4.0 at the Microsoft Website. I feel truly fortunate. That's it for this week. It's time for a ~!@#$% non-alcoholic beer.


Site Map

Log Index
Previous Log Entry
Next Log Entry

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Saturday August 23, 1997

Updated Friday July 3, 1998

copyright © 1996-1998 LAROKE Microcomputer Consultants all rights reserved

HotBot Search for