Doing it through the BDE is fine, so it should just work OK if you are sure
it is how you say. Are you sure the netFileDir is the same one for all
users?
The good thing about doing it in your code, is you guarantee that for your
App at least, the network control file is guaranteed to be in the correct
place. Usually I store this location in an Ini file, or Reg entry and load
it at startup time prior to logon.
In point 2... BDE Aplications often generate temporary files - Query temps,
Cache Temp files etc. If something goes wrong then you may find these files
get dropped in what ever the default directory is at that time meaning you
can get files splattered all over the place. Set the Session.TempDir (you
check the syntax) will ensure these temp files go to one directory on each
users hard drive.
Now, you are talking Windows Terminal server - which is a beast I have
already had an ugly experiance with - I think you need to be very carefull
here that your PDoxUsers.Net file is in a real directory that all the other
user know about, and not a virtual location. I would start by checking
performance with all the non-TS users, then taking it one step at a time
from there.
-----Original Message-----
From: Mark Howard <[EMAIL PROTECTED]>
To: Multiple recipients of list database <[EMAIL PROTECTED]>
Date: Friday, 5 November 1999 1:14 PM
Subject: Re: [DUG-DB]: Application not showing table updates
Thanks for the response Tony.
I do not have any code in the app saying Session.NetFileDir := xxxxx
but
NetDir IS set through BDEAdmin and Local Share IS set to True the same way.
Is there a problem doing it this way?
Given that there may be other apps using Paradox, doesn't the setting of the
NetDir have to be application independant?
Can you please elaborate on your point 2, below?
Appreciate your help
Mark
Tony Blomfield wrote:
> It all comes down to those few settings in the BDE Config
>
> 1.
> Network Control file - there must be one and only one on the entire networ
k
> which every Pdox user has full access to, and every copy of your
application
> must use this single PDoxUsers.Net. How you do it - with a BDE Alias, or
> coded into your app, dont matter. NOTE Full access means Unrestricted read
> write access. The onsite network Nazis will try everything they can to
screw
> you around with this.
>
> Session.NetFileDir :=
>
> 2. It also pays to make it easy to clean up crap by
>
> Session.PrivDir :=
>
> 3. And set Local Share = True
>
> If you have 1 and 3 then it will work.
>
> Your comprehension of the net file dir is pretty important. Dont ever
forget
> it exists as it (or some problem with it) is often the cause of a support
> call.
>
> Hope that helps...
>
> Tony.
> -----Original Message-----
> From: Mark Howard <[EMAIL PROTECTED]>
> To: Multiple recipients of list database <[EMAIL PROTECTED]>
> Date: Friday, 5 November 1999 10:51 AM
> Subject: [DUG-DB]: Application not showing table updates
>
> This post has been copied from the main Delphi group because of no
> responses.
> Hopefully I will have more luck here. If I haven't given enough
> information, please ask.
>
> Hi
>
> This is a question that relates to a D3 / Paradox app. running on NT
> Terminal Server.
> The application opens all tables in the database as it starts and only
> closes them as it ends, unless the user specifically closes and reopens
> the database.
>
> In the code, every Post is followed by DBISaveChanges.
>
> The site is complaining that with two (or more presumably) workstations
> using the system, postings from one workstation are not appearing in
> TLists on the other workstation, even when these are specifically
> refreshed from the database.
>
> If the database on the second workstation is closed and re-opened the
> data then appears.
>
> Can someone please tell me what I have to do to ensure that these
> postings are immediately available to the second (and subsequent)
> workstations.
>
> I find it difficult to test these multiuser things as I don't have
> access to a network (let alone NT Terminal Server!)
>
> If there are some tests that I can get the site to do, to home in on the
> problem, any suggestions will be gratefully (desparately?) received.
>
> TIA
>
> Mark
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
