Hello. I have a problem I hope someone can enlighten me about. I am
developing a website which gets data (read only) from a FoxPro for DOS
app which is in constant day-to-day operation. It works fine on my
FoxPro for DOS PC at home, and I hope it will also work on my client's
FoxPro for DOS system, although there are differences between them,
e.g., his is multiuser across a network, while mine is local to my
PC.
But I'm worried, since my web app does not work if it tries to get
FoxPro data from either of my two VFP PCs (old versions - VFP6). If I
run a SELECT (from ColdFusion, though I suspect that does not matter)
on a DBF which is already open in Visual FoxPro, I receive a message
like 'cannot open file c:\acrc\joblog.dbf)'. And vice versa: if I
first bring back data using a SELECT statement in ColdFusion from a
Visual FoxPro table not yet opened, then try to open it in Visual
FoxPro, I get the message from Visual FoxPro that 'File access is
denied'. Obviously whichever application gets to the file first seizes
control of it.
I am going to FoxPro through ODBC, and I have the specs of the
connection configured in the ColdFusion adminstrator as 'SELECT
only' (ruling out all INSERTs, UPDATESs, etc). Moreover, the problem
occurs whether or not I ask ColdFusion to put a 'readonly' lock on
the DBF. (It can do that on other remote database systems... but are
they all client/server systems instead of file-sharing?) I should
point out that the tables in question here are not opened in Visual
FoxPro with exclusive access. None of them belong to a DBC (obviously
not in the DOS case, but also not in the VFP case).
The specs of my ODBC connections are identical on my FoxPro for DOS
and Visual FoxPro PCs, though the drivers are no doubt different. My
two VFP PCs have the VFP OBDC driver versions 6.0.8167 and 6.1.8629.1.
I don't know what filename to look for to find my FoxPro for DOS ODBC
driver.
Is this just a 'hole' in FoxPro for DOS that the VFP drivers 'fix'?
After all, if a file is being updated, a SELECT could supposedly
return inconsistent data, though in this case the likelihood of that
is exceedingly slim). Should I simply be grateful that my client's
FoxPro 2.5 system has this hole? In any case I would like to
understand what is going on.
|
