Dbase IV: scrambldd DBFs and migration problem Novell->W2003 server

what size is your dbf? Approaching 2GB limit??

The biggest file is just 50MB or so. Most of the DBFs are around 3MB only.

Here is a program I wrote long ago to locate mad records or bad data - faq290-4606

I worked in a NetWare 5.0 environment years ago and had occasional problems with WinMe computers messing up records. My guess was that it usually happened when someone was trying to print reports and somehow WinMe or NetWare or both scrambled the file/printing handles, since we would find text being sent to the printer overwriting the table records. Yes, a huge problem. We also found that at the time that Novell did not have reliable drivers for Windows XP.

(Frankly, Microsoft did not aggressively fix compatibility issues between NetWare and XP, Novell filed at least one complaint alleging MS took a year and a half just to fix one of the networking issues they reported with MS software. Therefore, many companies switched to Windows servers to resolve the longstanding problems.)

Eventually we went to Win2000 server and that data corruption problem went away. XP is much better and more flexible than Win98 or WinMe - on a Microsoft Server, of course. Server 2003 is a solid and stable product, but of course MS is soon going to push for people to get Server 2008.

Hello,
well, we tried a win2K server already instead of the netware server.. same problem.
We also tried WinXP clients... problem even worse.
Here the problem happens when 2 or more clients are modifying the same DBF file (but different records).

I spoke of issues I had with dBase 5 for DOS. Have you tried RLOCK and UNLOCK? Do you have problems mainly when you're editing records or appending records or both?

Frankly, you need to get out of the DOS world soon. These languages are some 15 years old and more problems will likely crop up as time goes on. Even though it may cost some to have the programs rewritten, you are already paying a cost from the data corruption, delays to fix the data, etc. In the long run you need to update.

We already tried dBase V as well. Same thing.
Yes I have tried RLOCK... it is not a programming error.
Seems to be some delay with the internal record locking system of dBase.
Yes we know that we have to update and are already working on a completely new software, but it takes time.

Is there a Dbase equivalent for Foxpro function FLUSH which commits buffers to disk

Flush?
No, there is none.
Also, we already switched off all cashing in the netware clients....