dBase 5 DOS + Win 2000 / XP + SCAN = "Flaky!"

[dbMark]

Yet again I've encountered weird behavior with dBase 5 for DOS in the Windows 2000 and XP environment and so here's my documentation of this issue. Two different programmers have stumbled across this issue a total of 3 times this year.

Each program is a little different but here is the overall environment: dBase 5.0 for DOS, the program files and the data files are all running on a Windows 2000 Server. There are no problems seen with older Windows 98/Me workstations. But if you use the SCAN loop from a Windows 2000 or XP workstation sometimes you're exited (dropped, bumped, ejected, blown out, etc.) from the loop prematurely long before reaching the actual end of the records.

Here are a couple simplified examples.

In the following example, the scanned table is opened NOUPDATE but I think it becomes unstable anyway apparently after hitting 2 or 3 records locked by others and the scan exits prematurely.

USE myTable NOUPDATE
SCAN
xFile = mytable->otherTable
USE (xFile) ORDER myOrder IN SELECT() NOUPDATE
SELECT (xFile)
IF SEEK(my_data,xFile)
? "Record found"
ENDIF
USE
SELECT myTable
ENDSCAN
USE IN myTable

In the following example, after hitting 2 or 3 records locked by others, the scan exits prematurely. Adding UNLOCK alone does not resolve the flaky abort, but adding the RLOCK() test does work.

SET EXCLUSIVE OFF
USE myTable
SCAN
REPLACE myField WITH myData
ENDSCAN
USE IN myTable

This happens whether or not we place a filter on the table or use the SCAN FOR or not. Something is causing the SCAN to get out of synch somewhow. Perhaps the answer is to always test first with RLOCK() in a multi-user environment but I wouldn't have thought it of any consequence with a table opened NOUPDATE.

If a program command is unreliable in a somewhat unpredictable pattern, I get worried.

Replacing the SCAN/ENDSCAN loop with DO WHILE/SKIP/ENDDO avoids this issue but it is an unfortunate workaround since SCAN was meant to be the best way to automatically go through a table record by record.

Legacy software - beware!

dbMark

 

[dbMark]

I'm surprised that no one has commented on this issue. I am continuing to find more of my programs that are failing - without any system warning - to successfully complete SCAN/ENDSCAN loops if they're run on 2000/XP systems.

As mentioned above, I am replacing them with DO WHILE/SKIP/ENDDO loops. I hate the workaround, but what else can I do until I am able to convert to a newer database programming language?

Environment:
- Server: Windows 2000 Server SP4 acting as a DNS, DHCP and file server for Windows versions 98se/Me/NT/2000/XP
- Workstations: Windows 2000 or XP (NT family)
- Database version: dBase 5.0 for DOS released 1994 (using either DBO or EXE)
- Critical failure: If an attempt to open a table fails because it is in use by another user, then the SCAN/ENDSCAN loop it is currently in can terminate at a future point before it has reached the end of the table. (The same complaint applies when attempting to edit individual records that are locked in a shared file and RLOCK()/UNLOCK were not used. But this is not so bad because we do have a way to determine beforehand if a record is locked. Such is not the case with the USE command, sad to say.)

Aside from this critical problem, I am amazed how well we've managed to keep things going for 10 years! Some peripheral standalone programs have already been converted to Visual FoxPro, but there's a long way to go...

dbMark

 

[dbMark]

Another inconsistency has been discovered with dBase 5 for DOS. A developer here found a case where field replacements failed to complete in a table that had just created a standalone index (.NDX) rather than a tag in a master index. The fields being replaced were not in the index expression, so it was not a case of the record pointer jumping around. It failed on his XP, so he tried it on another's WinMe, thinking it was another XP issue, but WinMe failed too!

* sample code to illustrate problem
USE myTable
* write separate index since table not opened exclusive
INDEX ON myDate+myPartNo TO tempNdx
REPLACE myCost with myItems*myUnitCost FOR myDate=DATE()-1
BROWSE  && see that only first record was replaced!

In addition many years ago we stopped using SEEK and FOUND() command combinations since FOUND() sometimes failed. Here's what we did.

* abandoned method
SEEK mySeekVal
IF FOUND()  &&  might fail unpredictably
   * code
ENDIF

* current method
IF SEEK(mySeekVal)  && works fine
   * code
ENDIF

I'm documenting this in case someone else has problems.