Re:One user gets locked out of DB and gets Cannot locate PDOXUsr.net file
Marc,
1) the locking problem
The approach you've used to fix things is the same as I've been using since
PDXW V1.0 and it seems to be only reliable way even although it is pretty
ghastly. As to the problem itself, I wonder that there is some network
disturbance that leaves some unresloved connection to a table (is a detached
process possible?) even if not to the pdoxusers.net itself. When I've dealt
with this problem recently it always seems that somehow logged-out users
seem still to be connected.
2) table "version" problem.
I've found that the 16-bit paradox utilities tend to ignore the "version"
you try to nominate but that it doesn't matter. The utilities tend to
revert to the oldest version possible that supports the data types in the
table - if your application uses no fields with "newer" datatypes then the
engine seems to consider no merit in using a "newer" table version tag and
just seems to do what it likes. I've found, though, that the 32-bit engines
works more predictably. Paradox 5 itself seems not to mind though so I just
ignore it.
2) Most of my 16-bit Paradox apps are in V7 and 1 & 2 above still happen the
same so if this is the only reason you want to upgrade from V5 then it
probably wouldn't help. The real issue here is the version of the database
engine underpinning Paradox and the only bde-specific parts in the latest
16-bit version (bde 252 I think) related to support of new datatypes but you
basically wouldn't be using them in Paradox 7 unless you reworked the
application quite a bit (and I suspect that you don't want to do that with
Paradox 9, which is only 32-bit, available). I don't think V7 (16-bit) would
be available anywhere now as the 16-bit architecture seems to have been
totally abandoned when Paradox was sold to Corel some time ago. V7 32-bit
might be around if you can get hold of a copy of Corel Office Professional
V7 as it came bundled with Paradox 7 32 bit. Even then you would have to
recompile your application to run it and still might not fix the problems yo
u're finding anyway.
3) "Strict Referential integrity"
Basically I've always stayed away from this totally within Paradox
applications as it has burnt me several times (great way to lose bulk date);
I prefer to handle it myself within the application. Ditto for "lookups"
although this is mainly because I want to use more intelligent and
"prettier" lookup screens. I wouldn't think changing this setting would have
any affect on the "pdoxusrs" problem at all as it relates more to rows in
the tables than to way the engine interacts with the environment.
hope this helps,
Ian Borland
i...@compsci.com.au
