 |
|
| Computers Forum Index » Computer - Databases - Paradox » Records go poof!... |
|
Page 1 of 1 |
|
| Author |
Message |
| Shawn... |
Posted: Fri Jul 17, 2009 12:31 am |
|
|
|
Guest
|
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 |
|
|
| Back to top |
|
|
|
| Liz McGuire... |
Posted: Fri Jul 17, 2009 1:28 am |
|
|
|
Guest
|
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:
Quote: 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
|
|
|
| Back to top |
|
|
|
| Jim Moseley... |
Posted: Fri Jul 17, 2009 2:50 am |
|
|
|
Guest
|
Shawn,
Quote: The company using the software is very large, and has many users tied into
the database via a mapped drive.
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 |
|
|
| Back to top |
|
|
|
| Steven Green... |
Posted: Fri Jul 17, 2009 3:56 am |
|
|
|
Guest
|
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 (no spam) mapson.triptracker.com> wrote in message
news:4a5faebb$1 at (no spam) pnews.thedbcommunity.com...
Quote:
Shawn,
The company using the software is very large, and has many users tied into
the database via a mapped drive.
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
|
|
|
| Back to top |
|
|
|
| Shawn... |
Posted: Thu Jul 23, 2009 8:10 pm |
|
|
|
Guest
|
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 (no spam) diamondsg.com> wrote in message
news:4a5fbe44$1 at (no spam) pnews.thedbcommunity.com...
Quote: 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 (no spam) mapson.triptracker.com> wrote in message
news:4a5faebb$1 at (no spam) pnews.thedbcommunity.com...
Shawn,
The company using the software is very large, and has many users tied
into
the database via a mapped drive.
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
|
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Thu Dec 10, 2009 12:47 pm
|
|