VFP With XP/98

Discussion:

VFP With XP/98

(too old to reply)

Brian Copeland

2004-09-07 15:50:33 UTC

What we see happening is that when the Visual Foxpro data resides on a
Windows '98 computer (we are using free tables, not a .DBC, if that
matters), there is an issue when accessing the data using more than
other Windows XP workstation. When one workstation appends a record
into the database, it seems that the header reflects the new record
count, but the new record itself doesn't exist. As a result, an
attempt to open the same database on another XP workstation will come
up with an error 2091 -- corrupted database due to header/data
mismatch. The problems persists until the database is closed. It isn't
a problem when only one XP machine has the table open... only when
another tries to open (shared) the same table.

Setting TableValidate to 0 "fixes" the problem, however, then the
second workstation runs the risk of inserting data into a table for
which the actual number of records is inconsistent with the record
count. The table isn't really corrupted, it just "appears" that way to
Visual Foxpro. This only seems to happen if the data is on a Windows
'98 computer being accessed by two or more Windows XP workstations,
using computer name or a drive letter.

How safe or unsafe is it to set TableValidate to 0 in this situation?
Wouldn't this run the risk of "lost" records due to update conflicts?
Is there a known work-around to this? We have tried setting
caching/write properties on the folder on the Windows '98 machine
where the data resides, with no luck. We found this after seeing a
pattern in customer calls, where a database would appear corrupted
only if another workstation was logged in. When we set it up to test
here, sure enough, it happened right off. Is this a known issue with
Visual Foxpro, or is the problem in the connection between Windows '98
and Windows XP?... and if so, which one is at at fault, the '98
sharing its files, or the XP accessing it?

Anders Altberg

2004-09-07 17:28:16 UTC

Permalink

I winder if this could be related to a known probelm in Windows 2000 -
system write caching. The system decides when to actually perform the write
and it can take its own sweet time about it. FLUSH will only shove data into
this buffer. You can turn this feature this off in W2K but it seems to
restore itself. There is an API for it FlushFileBuffers or something like
that. In VFP9 it will be handled with an extra paramter in the FLUSH command
FLUSH FORCE.
-Anders

Post by Brian Copeland
What we see happening is that when the Visual Foxpro data resides on a
Windows '98 computer (we are using free tables, not a .DBC, if that
matters), there is an issue when accessing the data using more than
other Windows XP workstation. When one workstation appends a record
into the database, it seems that the header reflects the new record
count, but the new record itself doesn't exist. As a result, an
attempt to open the same database on another XP workstation will come
up with an error 2091 -- corrupted database due to header/data
mismatch. The problems persists until the database is closed. It isn't
a problem when only one XP machine has the table open... only when
another tries to open (shared) the same table.
Setting TableValidate to 0 "fixes" the problem, however, then the
second workstation runs the risk of inserting data into a table for
which the actual number of records is inconsistent with the record
count. The table isn't really corrupted, it just "appears" that way to
Visual Foxpro. This only seems to happen if the data is on a Windows
'98 computer being accessed by two or more Windows XP workstations,
using computer name or a drive letter.
How safe or unsafe is it to set TableValidate to 0 in this situation?
Wouldn't this run the risk of "lost" records due to update conflicts?
Is there a known work-around to this? We have tried setting
caching/write properties on the folder on the Windows '98 machine
where the data resides, with no luck. We found this after seeing a
pattern in customer calls, where a database would appear corrupted
only if another workstation was logged in. When we set it up to test
here, sure enough, it happened right off. Is this a known issue with
Visual Foxpro, or is the problem in the connection between Windows '98
and Windows XP?... and if so, which one is at at fault, the '98
sharing its files, or the XP accessing it?

Dan Freeman

2004-09-07 21:59:14 UTC

Permalink

First thing I'd do is get a real file server. <s> Neither Win98 nor WinXP
are file server operating systems.

Dan

Post by Brian Copeland
What we see happening is that when the Visual Foxpro data resides on a
Windows '98 computer

Cindy Winegarden

2004-09-07 22:00:39 UTC

Permalink

Hi Brian,

I'm not sure if it's related but people have reported problems when using a
peer-to-peer network with a Win98 machine as the "server" and WinXP machines
as the clients.
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP

Brian Copeland

2004-09-08 03:07:35 UTC

Permalink

Cindy,

That's exactly how this is set up. We've recommended that the client
upgrade the Win98 machine to XP. We've been a little gun-shy of the
TABLEVALIDATE approach because of the potential to overwrite an
un-flushed record.

Any other ideas or suggestions?

Thanks to all.

Post by Cindy Winegarden
Hi Brian,
I'm not sure if it's related but people have reported problems when using a
peer-to-peer network with a Win98 machine as the "server" and WinXP machines
as the clients.
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP

NikV

2004-10-11 15:21:07 UTC

Permalink

Had similar problems getting data actually written to the disk, Flush,
sys(1124) (I think) did not work, then Cy W suggested Rlock() /unlock which
forced the data to be written!

Nik V

Post by Brian Copeland
Cindy,
That's exactly how this is set up. We've recommended that the client
upgrade the Win98 machine to XP. We've been a little gun-shy of the
TABLEVALIDATE approach because of the potential to overwrite an
un-flushed record.
Any other ideas or suggestions?
Thanks to all.