We cannot explain why a group of tables ended up completely empty yesterday.
Some of the tables had thousands of records, and they all have the same
modified date/time of 4pm. Most still show varying sizes up to around 2MB,
but they are all empty. This software is used daily, and has been for years.
Does anyone know what may have emptied a handful of tables, yet left others
alone in the same directory?

The company using the software is very large, and has many users tied into
the database via a mapped drive. At this point, we are clueless, but we need
to give some sort of explanation as to what happened. They are rectifying
the situation themselves, using what they can from daily backups that they
make, but from what they say, it is still quite a task.

They are running PdoxRT V10 (Winxp) - It is virtually impossible to find out
what/who happened due to the amount of users touching the database daily.
There is a total of 121 files in that directory, and 42 were emptied
somehow.

TIA
Shawn

Shawn,

Here's an example of what could have happened.

Referential integrity code is set up so that if you delete a parent
record, child records are deleted first, then the parent is allowed to
be deleted. Auto-append is enabled on the form showing the parent
record. The user moves past the last record of the parent table, but
doesn't type anything, thus, a real record isn't inserted and the parent
record doesn't get a key. The user sees the blank row and decides to
delete it. Code doesn't check whether the key is blank, it just assigns
the key to a variable, then uses tcursors to setRange on the detail
tables and deletes "related" child records. Since this would result in
setRange including all the records in the table, all the records would
be deleted.

There may be other reasons - malicious, accidental, bad code or some
other unknown. It's pretty hard to guess when you don't have details.

FWIW, I have not heard of Paradox tables spontaneously emptying themselves.

Are you sure they aren't just corrupt?

Liz


Shawn wrote:

Shawn wrote:

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

Shawn,

I recently had a client with a similar (though not exact) problem. A shared
drive was allocated on a computer exposed to the internet (with IIS on it).
The shared drive's security allowed 'Everyone' full control. Someone from
China hacked in, copied all of their data, and deleted their files, all while
the client was watching a popup window saying 'Deleting files...'. Not a
fun day for them.

The lesson learned was to never let 'Everyone' have access, only 'Authenticated
Users'.

In your case, though, since all the timestamps are the same, I'd bet someone
mistakenly installed a 'demo' or iniital version of the software over the
top of your live production data. As soon as they realized what they were
doing, they killed it.

Any Opal table empty's would take more than a second for 42 tables, I would
think.

HTH,
Jim Moseley

FWIW.. I tend to disagree with all the previous theories, but mine is just a
theory, too.. if all of those tables have the same date/time stamp, I'd lean
towards hardware/power failure, not malice.. anything done by hand, or by
any deliberate purpose, would have different stamps.. seconds and/or minutes
apart.. failure could result in all being the same..

a real "paradox empty" command would result in 2k table sizes, not big table
sizes..

--

Steven Green - Myrtle Beach, South Carolina USA

http://www.OasisTradingPost.com

Oasis Trading Post
- Collectibles and Memorabilia
- Vintage and Custom Lego Creations

Diamond Software Group
- Paradox Sales and Support

Diamond Sports Gems
- Sports Memorabilia and Trading Cards

"Jim Moseley" <jmose (AT) mapson (DOT) triptracker.com> wrote

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" <nospam@nospam> wrote

Thanks to everyone for the quick responses..... Our problem is still
unexplained, but Steve's explanation makes the most sense at this point -
considering how our app is configured and written.

-Shawn


"Steven Green" <greens (AT) diamondsg (DOT) com> wrote