From: liz@paradoxcommunity.com   
      
   User count or usage or data volume increasing could be why you're now   
   seeing more problems.  What we can't know are the details of past   
   problems which may have been caused by this.   
      
   Here's how a Paradox/BDE application is supposed to work:   
      
   1. We have a directory (or more than one, but we'll work with one) where   
   the data lives, and another directory where the .NET file lives and each   
   user has a PRIV directory.   
      
   We start with no open instances of Paradox, no lock files, no net file.   
      
   2. User number 1 fires up Paradox.  Paradox loads the BDE.  The BDE sees   
   there's no .NET file and creates* one.  The BDE then creates* .LCK files   
   in PRIV.  The user opens the application, thus opening tables in our   
   data directory and the BDE creates* .LCK files in said data directory   
   and makes an entry** indicating what locks the user has on the tables.   
   It also makes an edit** in the .NET file.   
      
   So far, we need the following rights (other than "list" and "read",   
   which are a given):   
      
   * Create - in the .NET directory, the PRIV directory and the data directory   
      
   ** Edit - in the .NET and the data directory (I think edit in PRIV goes   
   without saying)   
      
   Opening a table probably requires execute rights, not really sure.   
      
   3. Other users come.  For each user who opens Paradox and starts the   
   application, the BDE makes entries in the .NET file and in the .LCK   
   files in the data directory and creates .LCK files in PRIVs.   
      
   The above rights are still enough - we're creating and editing.   
      
   4. A user closes the app (and Paradox), but others are still using it.   
   The BDE edits the .NET and .LCK files in the data directory and deletes   
   the .LCK files and temp tables in PRIV, probably any temp files the user   
   caused to be created elsewhere too (I know of no comprehensive list of   
   directories where the BDE creates temp files; testing a year or two ago   
   showed the BDE sometimes uses the dir above the one the data is actually   
   in, so we now all recommend the data above all your Paradox dirs be   
   unused and have full rights like the Paradox dirs).   
      
   We now need to add delete rights in PRIV (possibly elsewhere, if the   
   user caused temp files to be created elsewhere).  If the LCK files in   
   PRIV don't get deleted, there's a high likelihood of "different .NET" or   
   other errors the next time the user starts the app.   
      
   5. Steps 3 & 4 repeat ad nauseum through the day.  The .LCK files in the   
   data directory grow and grow and grow and grow.  (The .NET file stays at   
   13 KB, go figure.)  This is all as it should be.   
      
   6. Finally, at the end of the day, the last user exits the application.   
     The BDE deletes their PRIV LCK and temp files, edits the .NET file and   
   *deletes* the LCK files in the data directory.   
      
   * We now need delete rights in the data directory (for sure).   
      
   Here's what happens if we don't have delete rights in the data directory:   
      
   The lock files grow and groW and grOW and gROW and GROW until they're so   
   BIG that Paradox won't work any more and your application runs slower   
   than molasses in winter and users get impatient with it, so they   
   ctrl+alt+delete it, which at first just causes index out of date errors,   
   which cause application errors where the corrupt index is used, and   
   frustration grows and users complain to each other about how stupid this   
   app is or how stupid IT are or how slow the network is and they   
   ctrl+alt+delete the app some more and cause data corruption (unless   
   you're really lucky - glory to Paradox, the BDE and NetWare), some users   
   power off their computers rather than Crtl+Alt+Deleting and pretty soon   
   you've got corruption and GPVs and GPFs and other errors all over the   
   place.  Meanwhile, you're having to take the app down in the middle of   
   the day to run table repair and management are yelling at you for lost   
   productivity...   
      
   All because:   
      
   a) the users don't have delete rights, so the LCK files never get   
   deleted when the last users leaves the app (for lunch, at the end of the   
   day, or whatever) and so they get to an unmanageable size (this is a   
   known and documented issue - lock files cannot grow infinitely - the   
   closer they get to 1MB in size, the slower the app is and the closer   
   failure comes)   
      
   and/or   
      
   b) your users are lazy and leave the app and their computers running   
   24x7 so they don't have to restart it, thus leaving locks forever and   
   interfering with your backups - not to mention losing memory to leaks   
   for days on end, leading to other problems.   
      
   This is the reality of Paradox.  Rights and configurations must be set   
   to *support* it, not to *fight* it.   
      
   There are 2 ways to help avoid users deleting tables:   
      
   1) Use some obscure drive letter for your Paradox files and don't put   
   any other files there and don't allow users to create files at the root   
   of the drive.  Have nothing but folders at the root of the drive.   
      
   2) Use UNC rather than mapped drives, so that it's harder for users to   
   find where your Paradox files live in the first place.   
      
   I suppose you could try using some other tool, run by some user with   
   delete rights, to try deleting the LCK files from the data dir every now   
   and then, but IMO, that's a bad solution.  Just give people delete rights.   
      
   Liz   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)