From: nospam@nospam   
      
   Shawn wrote:   
      
   > We cannot explain why a group of tables ended up completely empty   
   > yesterday.   
      
   I don't know your app, but from what information you've provided, this   
   almost has to be either malicious or, at best, the result of foolhardy   
   exploration/experimentation.  I'm going to assume you've verified that these   
   tables are, in fact, actually empty.   
      
   You can wind up with an empty table during a botched restructure, and index   
   damage can result in an apparently empty table, but 42 tables at once?  It's   
   hard to fathom how some glitch could be solely to blame.   
      
   Someone else please chime in if you thhink I am off base here, but, absent   
   evidence to the contrary - your customer needs to first and foremost regard   
   this as a security incident and behave accordingly.  Look to the network OS   
   file access audit logs, if in place.  If not in place, put them in place.   
   If they have not implemented a guaranteed cold backup policy on this data,   
   they need to at once.   
      
   Without cold backups, recovery is difficult, because recovered tables may   
   individually represent different states of the database if anything was   
   updated between the start and end of the backup.  Hence the above   
   requirement.  For that same reason, they really need to consider recovering   
   *all* tables from backups, not just the ones which were emptied.   
      
   The file sizes reflect the unreclaimed space since the rows were deleted.   
   The space will be reclaimed slowly as new records are added, or the file   
   sizes will shrink down after the tables are restructured.   
      
   These are the three biggest technical weaknesses of Paradox.  Of all   
   file-shared databases, really.  No explicit operational auditing, no   
   built-in support for read-consistent backups, and (IMHO, worst of all)   
   direct end user access to the database files.   
      
   What to tell your customer?  Aside from the likelihood they've got a   
   (potentially ongoing) security issue, they need to consider an audit of file   
   access permissions to ensure that access is restricted to legitimate users   
   only.   
      
   A workaround that solves a good deal of the security issues would be to   
   employ a Terminal Services or similar arrangement, with local profiles on   
   the servers restricted to only running your runtime app and nothing else -   
   no CMD, Explorer, etc.   
      
   --   
   Larry DiGiovanni   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)