From: numberjack@wi.rr.com.nospam4me   
      
   Some ideas.   
      
   I would have copied (using explorer) the entire folder somewhere, to check   
   out later.   
   If the files are not 2k... somethin is amiss, the datestamp EXACTLY the same   
   is a clue.   
      
   something to look for...   
   or (this has happened to me), if the files are 2k, did someone maybe copy   
   "empty shell" tables over them all at once?   
   are all the suspect tables in alphabetical order?   
   What is the modified AND created date?   
   Index files? they can also be a clue.   
   Are they opening the tables in Paradox or the app to see that they are   
   empty?   
      
   How do you know that the 42 are emptied? What was the sign?   
      
   Does the app happen to have all 42 table open at once when looking at a   
   master record or something, then user had a power failure or crash?   
      
   Did you try to rebuild the tables?   
      
   "Larry DiGiovanni"  wrote in message   
   news:4a5fa014$1@pnews.thedbcommunity.com...   
   > 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)