dBase IV + Win2KPro - file sharing Problem

[Guest_imported]

My Client is currently introducing New computers (Win 2000 Pro) to their dBase IV Payroll system. The problem occurs when several users try to append records to the same database at the same time. The user with the Win2K pro computer will wipe out all of the updates made by the Win98 user. Two Win2K Pro users will selectively wipe out each others work. The Win 2K Pro computer ignors all record locks and other user updates. It almost appears like WIN 2K Pro makes a copy of the datafile when opened, then writes the file back when it is closed. The Clipper DBCOMMIT() command solves this problem (In Clipper). The AutoSave setting in dBase has no effect. This problem only seems to occur when appending records, editing existing records does not seem to be affected. I have discovered an inelegant solution: Close the datafile before and after appending a record. It seems to me there should be a way to change WIN2KPro so that it handles dBase files like WIN98, otherwise I have a huge coding job ahead.

 

[Guest_imported]

I seem to have the same problem did you find a better solution.

Thanks

 

[Guest_imported]

In the Fall I thought I had the problem solved when I heard about a solution on a different BB. They believed that using two protocols at once, screwed up the record locking of Win2000Pro. In our case we were using IPX (novell) and IP (internet). I was easily able to duplicate the problem in my office when using the two protocols. When I removed IPX, the problem disappeared (In my Office). So we moved several Districts to a WIN 2000 Server (IP only) and let them loose. Although much improved, this spring I have been getting reports of the same old problem happening during times of heavy data entry. (3-4 users appending records to the same data file). It has been very frustrating with the lack of info and interest in this problem. (one response in 10 months). A lot of my reports are already programmed in clipper so I guess that I will have to recode (in Clipper) the problem areas of my dBase program.

My original solution dating back to last summer was to open and close files before and after appending data. (flush buffers). This worked great at first, but after a few months I noticed that the targeted data files were becoming corrupted very frequently (Missing EOF marker). I restored the original code and the ongoing corruption ended.

 

[dbMark]

Okay, here's a second belated answer. We had similar problems, and data issues more than just missing EOF() markers in the DBFs, with our Novell 5 system using IPX. As it got busier it got worse. And when a computer messed up, would always do it again on all subsequent retries after the table was fixed. Only a reboot would return the workstation back to normal. Some stations were more prone to act up than others, but no rhyme or reason why. Finally we switched to Win2000 server and the problem went away. I still wonder if MS makes their OS just finicky enough with the IPX system just so users go to their servers in frustration.

In a prior assignment back in the late 90s I was supporting a system where the programmers had finally decided to quit APPENDing during the busy day. At night they would append lots of records and delete them. Then they had special code (instead of APPENDing) which simply RECALLed a deleted record and used it. Rarely, 2 computers claimed the same record, but that was much less common than the original problem. Finally went to SQL server for the back end...

When is a LOCK not a LOCK? When it doesn't LOCK!