Another bug in dBase 5 for DOS

[dbMark]

Yet again I've encountered weird behavior with dBase 5 for DOS in the Windows environment and so here's my documentation of this issue. Previously I reported SCAN/ENDSCAN issues, SEEK/FOUND() issues and failed field replaces in newly indexed tables as described in thread290-882126.

Each issue 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 or 2003 Server.

This new problem is that I get the error "Variable not found" under the following circumstances:

myArray[myFldNum]="fails"
myArray[AliasName->myFldNum]="succeeds"

myArray[VAL(myFldChar)]="fails"
myArray[VAL(AliasName->myFldChar)]="fails"

The workaround is to save the desired field value to a memory variable then do the array field replacement using that variable:

myTempVar = VAL(AliasName->myFldChar)
myArray[myTempVar]="succeeds"

Another bug I've known for years is that ID() returns the logged in user name in a NetWare network but with a Windows Server network it returns the computer name. In both cases the program adds a 1, 2, etc. to the returned name for each session/window running on the computer. With Win98/98se/Me you're up a creek trying to figure out who's logged in for security verification. With Win2000/XP you can get the user name with GETENV("USERNAME").

dbMark

 

[dbMark]

More testing tonight revealed this quirk:

myArray[VAL(myFldChar)] = 1 && fails
myArray[VAL(AliasName->myFldChar)] = 1 && fails

myArray[VAL(myFldChar)] = myArray[VAL(myFldChar)] + 1 && succeeds
myArray[VAL(AliasName->myFldChar)] = myArray[VAL(AliasName->myFldChar)] + 1 && succeeds

For some reason, when the value of the array is being incremented or stored back to itself, it does not error. Repeating the above lines in any order did not produce any different results.

Even more perplexing was I tried the first post's code in one session and it worked. Then I exited dBase and reentered and it didn't work! I compared the DISPLAY STATUS system variable settings and they were identical. So I'm not sure what I had done in the prior session to avoid the error.

 

[dbMark]

Mystery solved! Well, not solved, but I found out how to avoid the error. The table had been opened NOUPDATE. Apparently this affected the array & field logic in some unanticipated way. So the solution is that the field's table must be opened either in shared or exclusive mode, but not noupdate!