Board index » delphi » One user gets locked out of DB and gets Cannot locate PDOXUsr.net file

One user gets locked out of DB and gets Cannot locate PDOXUsr.net file

Has any one had the pleasure of dealing with the locking files of Pdox... I'm using Paradox version 5.0 (no patches, would like some) , BDE version 2.0...with Delphi front end... I have a user who is getting locked out of the database and is getting a "PDOXUsrs.net file not found" error message...  
The file is there on the server in a diff locale than the Tables... and all the other users are working fine..

I suspect I'm having a prob with the db as I rebuilt the table a month or so ago and found that the rebuild util. actually rebuilt the table in version 4.0 (not Version 5.0) for the table structure even though specified version 5.0 in the rebuild...

Anyways I am having to all 20 user out of the DB and then physically remove the PDOXUsrs.lck as well as the pdoxUsrs.net  file and then things seem to return okay...

Would it benefit me to use the Paradox version 7.0 DBE util? If so , where the heck can I get a copy of it ... I really need to keep the application 16 bit...

Note: Would it help to change the Strict Referential integrity Option to False in the DBE Util?

Thanks,
Marc

 

Re:One user gets locked out of DB and gets Cannot locate PDOXUsr.net file


"PDOXUsrs.net file not found" sounds like a network problem of some kind. A
corrupt table would not prevent the BDE from finding the network control
file. The table repair utility that you use must match the version of the
BDE you are using. I doubt that the problem is corruption of the lock or
.net files since it only affects one user, although it is strange that
deleting the files fixes the problem.

Once the user gets this error can other user stop and restart the
application?

--
Bill

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

Re:One user gets locked out of DB and gets Cannot locate PDOXUsr.net file


"Bill Todd \(TeamB\)" <billtodd...@nospam.qwest.net> wrote:

Quote
>"PDOXUsrs.net file not found" sounds like a network problem of some kind. A
>corrupt table would not prevent the BDE from finding the network control
>file. The table repair utility that you use must match the version of the
>BDE you are using. I doubt that the problem is corruption of the lock or
>..net files since it only affects one user, although it is strange that
>deleting the files fixes the problem.

>Once the user gets this error can other user stop and restart the
>application?

>--
>Bill

Bill,

Thanks for your help,

Once the user gets this message, everyone is locked out if they
quit their current session. So the problem , I believe, is not isolated to the user. The server connection seems normal... I can actually open the file and look at it and such... But the only way for me to clear the error is to get everyone out of the db and then delete the pdoxusrs.net file... We have been encountering file server interuptions and I suspect the problem is related to these interuptions. I went into the dbe util yesterday and reconfigured the "level" Parameter to 5 instead of. This allows the tables to be configured as version 5 when a rebuild or restructure is performed on a table. Indeed , I performed a few rebuilds last month on related tables and did not understand why the tables were being reconfigured as version 4.0. I feel like I'm just pulling straws...

Re:One user gets locked out of DB and gets Cannot locate PDOXUsr.net file


I am not sure what you mean by server interruptions but if you mean either
lost connections or server crashes then I agree that this is a likely cause
of a corrupt .NET file.

--
Bill

Other Threads