Paradox, PDOXUSRS.NET file on network

Just Comment :

I Have the same problem using paradox table on the network ;(

Adeng.

hi people,

have you controlled each bde configuration?

if there overall the same netfiledir (called NET DIR in the BDE Administrator by
configuration|driver|native|Paradox) entry?

if no then edit it to the same entry, to a shared network drive
if the shared networkdrive not available a .NET-File will created on the first HD-Root directory.

If you will set the netfiledir at runtime, then must all DataawareControlls pointed to
to the TDatabaseComponent(DatabaseName = Name of TDatabaseComponent)

You cannot run two Applications on a workstation that will use different .NET-Files

meikl

Hi Meikl

Thanks for your comment regarding the BDE configuration on each machine. Is there a way to do this at runtime? If so how? I'd like to make the program as easy and user-friendly as possible to aliviate the need for users to sit and configure the BDE manually on each machine using my application.

All my table-components have their session property set to the session component who's netfiledir property I set at run time to be the same directory as the one containing all the shared DB files.

So I think all that is needed now is code to configure the BDE at runtime on any machine that runs my application.

Your comments?

Thanks in advance

Hi Cybersoft,

first, Sorry, instead TDatabase i meant TSession

If you will set the netfiledir at runtime, then must all DataawareControlls pointed
to the TSessionComponent(SessionName = SessionName of TSessionComponent)

The Tsession should first set to active then the activate other dataawarecontrols or set tsession active in designmode.

A general change of the default entry of NET DIR in the BDE is not recommended

Should work, if all have read, write, access and deleterights on the shared netfiledirectory.

If you will run multiple instances of your App on one workstation the privatedir entry of each instance should be different.

Hope, this helps

meikl

Hi Meikl

I've tried changing the BDE on both machines and it seems that
both can still edit the same record at the same time - IE not locking the table when one user puts it into edit mode.

I found this in the Delphi help file regarding the TSession component and the NetFileDir property:

"Delphi derives an initial value for NetFileDir from the BDE configuration file for the Paradox driver. Any value assigned       to NetFileDir at design time or runtime overrides the BDE configuration setting."

Although this is not true - because I write the value of the NetFileDir property to a text file during run-time and it is the value of that the BDE has been set to - not what my application set it to!

And according to an article in the inprise.com developer support
forum and techincal information database they state that the drive letters need not be the same on all the machines as long as they all inevitably point to the same directory containing the PDOXURS.NET file.

Just to let you know - all the Table components have their Session property set to the value of the Session's SessionName property. The Session's Active property is set to true at run-time and the value of the NetFileDir property is changed at run-time. (well so I thought)

At first I thought it may be a peer-to-peer network on 95 problem - but I've tested it here at work on two NT workstations on the network and the same occurs.

Both machines can edit the same record in a table being edited. BUT, the one difference I've noticed is that on my machine, on which I've developed the application, it actually does use the NetFileDir created at run time - although the other machines use the entry that was set using BDEAdmin.

Why does it use the NetDirFile setting I assign it at runtime on my machine and not on the other machines.

Another thing I noticed is that irrespective of what the NetFileDir setting is (and where it has been set) there is ALWAYS a PDOXUSRS.NET file created on the machine's C: drive in the root.

When I checked the contents of the PDOXUSRS.NET file (when the NetFileDir was forcibly set with BDEAdmin) I noticed that both machine's usernames were in there but it didn't lock the table's record being edited by one user.

I'm at wit's end here trying to figure this out.

Your comments?

Thanks in advance.

I've just done some more debugging and it appears that no matter WHAT I set my Session's NetFileDir to - it gets overwritten each time. I've tried doing it with the Session Active and with the Session InActive. Both give the same results!

HELP! PLEASE!

I've managed to get it to set the NetFileDir property now correctly on both machines - but I can still edit the same record from two machines - it's still NOT locking the record in that table.

I'm in your hands now....

Hi CyberSoft,

please wait, i am just under pressure at the moment, it should go
please tell me the default entry  of NET DIR in the BDE-Configuration.
i will back in One/Two Hours

meikl

Hi Meikl

Sorry - I did not mean to make it sound as if I'm relying on you completely - it was more generally speaking :-)

The default entry on all the machine's I've tested is: C:\ (which is the default when you install BDE for the first time).

What puzzles me is:
1) the fact that another local PDOXUSRS.NET file is being created on every machine running my application
2) that even though the PDOXUSRS.NET file residing in the shared location where the main tables are has both username's in it - but still doesn't lock the record.

Patiently awaiting your response (and anyone else that may be able to shed some light on this).

Again, thanks in advance for time and effort.

Hi Cybersoft,

Lock:
are you sure that both workstations working on the same table in the same directory?
Check the Alias Entry PATH in the BDE-Configuration on Both Workstations.
File:
Maybe the .Net-File on the local machine is generated during BDE initialzation before overriding with the TSession-Component.

meikl

Hi all

Just a thought - what is the value of Local Share in the BDE on each PC?  It's on the Configuration tab under System|Init.

Dave

Hi JimBob

They both say - FALSE - should this be true? According to the BDE Help file :

"(It is not necessary to set LOCAL SHARE to TRUE if you do not need to have both applications open at the same time.) Default: FALSE"



And the app is running on two separate machines.

Meikl

I'm not using BDE Aliases at all. And yes both machines are using the SAME database on the same shared directory.

Hi Cybersoft,

and its right that both machines can edit the same record at one time? Really mysterious, because, has one machine set the table in dsEdit Mode (i.e. with table1.edit)the second cannot do this and becomes normally an exception (like record locked by user xy), the second can only read the record, until the first machine has posted it.

And if you use no alias-Entry, then you have entered a Path in each DataAware-Control or use a TDatabase-Componet?

There is no lock until one station edits a record!!

meikl

Hi Meikl

Indeed that is why I am so completely confused about this whole situation. I've tried running the app twice on my local machine at work (NT) - and it raises the exception that the record is locked by another user (giving the local machine's logged in user name). But as soon as you attempt the same test on a network with two computers - both can edit the same record at the same time.

What bothers me is that even though the NetFileDir is being set correctly on both machines - and to the same shared directory (which DOES have full read/write rights) - it seems to ALSO create a local PDOXUSRS.NET file on each machine.

I'm still baffled as to how it doesn't raise the "locked record" exception because if you look at the record contents of the shared PDOXUSRS.NET file it does in fact show both usernames of both machines using that table.

I can, if needed, send you a copy of my app so that you can test it out yourself - if you could - I'd greatly appreciate it.

Thanks again
Demitri

Hi CyberSoft,

i've tried out with a sample app, but i can't reproduce this phenomenon, so that it will be a good idea to send me a copy of your app and a little table or table-structure, i will evaluate it on the company-network, where i work  tomorrow (Monday).

Send it to

kretzschmar@techsupport.de

meikl

Hi Cybersoft

Regarding the Local Share variable - I remember having some trouble like you have a few months ago.  I can't remember exactly what we did to solve the problem, but I remember that one of the things was setting Local Share = True.

JB

Hi Meikl

Thanks - I've sent you a copy of the application to test and see if you can reproduce the same errors.

Mail me if there are any problems.

Thanks in advance

Hi Jimbob

I tried setting the LocalShare setting to TRUE on both machines and got very weird results. The one application locked the tables in a way that the application running on the other machine could not view the other database files at all. So that definitely didn't help.

Thanks though.

The UpdateRecordTypes property of the TTable component would be usefull if that property could set a flag on the actual table itself so that it is read by other apps trying to modify the same table.

But unfortunately this property is only for hiding certain records from another control within the same application.

Going to look at Inprise.com if they can't shed some light as well on this matter.

Okay Cybersoft...

A couple things to remember

1)Try to have the Pdoxusrs.net file mapped to a common drive that all the users can see, using the same drive letter.  Very important in peer to peer networks...
i.e. S:\pdoxnet\

2)Create a separate directory for the DataFiles using rule one.
i.e. S:\PdoxData\

3)If your executable is on the network place it in it's own directory
i.e. S:\MyProgram\

4)Configure the BDE through the BDE administrator...I think your headaches will go away...Lots of programs require some tinkering by users...Look at hooking up to the internet...you have to set your tcp/ip...you get the picture...

5)If you see more than one Pdoxusrs.lck, paradox.lck and pdoxusrs.net file...something is wrong...*.lck files should only be in directories with data files...*.net file should only be where specified in the bde aministrator...

Hope this helps...


Rick

P.S. Also read deploy.txt found in your \borland\delphi #\deploy.txt

Hi Rickpet

Halelulja! Finally the one small minor (but very important detail) that has been missing since the beginning.

Thanks for your comment - it really helped. The only point that is required from your comments is point number one - specifically that the drive LETTER and directory names as the shared directory for the PDOXUSRS.NET file MUST be the same on both directories.

All that I did was map a directory on the machine with the main database files to the same directory and drive letter on the remote machine and voila! It locks the records.

It seems that the directory in which the Main database files lie is written to the PDOXUSRS.NET file. Now when the other application (on the "server") tries to access the PDOXUSRS.NET file to lock records it sees a different NET directory name as is used by the application and then creates it's own PDOXUSRS.NET file and allows a locked record to be edited.

There is no change required to the BDE configuration. All one has to specify before using your tables are the following fields:

NetDir : Same drive letter - shared (read/write/create/delete)
PrivateDir : Different directory for each application
SessionName : Eeach DB component must use the same SessionName

To ensure proper working I've set the NetDir value to the shared directory containing the main DB files.

I hope this helps other people as well who may come accross the same problem in the future.

Rickpet please post your comment again as the answer so that I can grade you and give you the points.

Thanks again to everyone
Demitri

I must just mention something (which I'm sure has been done many times before) that the Experts-Exchange is probably THE best resource on the internet for programming and other computer related questions. Besides the web site being setup so brilliantly there's a great group of helpful and friendly people here. Glad to be a part of it all.

All the best and happy programming! :-)