Table values mysteriously changed in 2 columns only

[Kyle Keller]

I created a database which my company has used for over 2 years at now
over 30 locations. Just today, one of the locations called and was
having problems with their program. The database is A97 runtime with
split front/back ends. They sent me their back end file, and 2 of the
columns in their Events table, all were somehow changed. One of the
values changed all changed to 0's, and the other all changed to 1's.
There are about 4000 records, and they're all changed.

The users can re-enter the values for the current data to get back on
their feet, and everything seems to work fine once the data has been
re-entered.

I don't have any update queries or anything in the program that would
go through all the records and check or change or update any of the
values automatically.

There are 4 front end users on a LAN with the back end at that
location.

Any idea what may have caused this sort of thing?

[Tom van Stiphout]

On 27 Jan 2004 17:29:38 -0800, ky***@jsav.com (Kyle Keller) wrote:

It taught them the value of making backups. Did you have them sweat a
bit to drive home that point?
Corruption happens, but this seems too particular to be contributable
to random corruption.
Perhaps it's a disgruntled employee? Don't laugh - I've worked with a
client that had this happen, and we used security monitoring
(available on NTFS) to catch the criminal.
Don't count out your app too quickly, although I have to say that
after 60 locationyears of operation most of the bugs are probably
ironed out already.

Interesting problem. Let us know what you find out.

-Tom.

I created a database which my company has used for over 2 years at now
over 30 locations. Just today, one of the locations called and was
having problems with their program. The database is A97 runtime with
split front/back ends. They sent me their back end file, and 2 of the
columns in their Events table, all were somehow changed. One of the
values changed all changed to 0's, and the other all changed to 1's.
There are about 4000 records, and they're all changed.

The users can re-enter the values for the current data to get back on
their feet, and everything seems to work fine once the data has been
re-entered.

I don't have any update queries or anything in the program that would
go through all the records and check or change or update any of the
values automatically.

There are 4 front end users on a LAN with the back end at that
location.

Any idea what may have caused this sort of thing?

[Bas Cost Budde]

Tom van Stiphout wrote:

On 27 Jan 2004 17:29:38 -0800, ky***@jsav.com (Kyle Keller) wrote:

It taught them the value of making backups. Did you have them sweat a
bit to drive home that point?
Corruption happens, but this seems too particular to be contributable
to random corruption.
Perhaps it's a disgruntled employee? Don't laugh - I've worked with a
client that had this happen, and we used security monitoring
(available on NTFS) to catch the criminal.
Don't count out your app too quickly, although I have to say that
after 60 locationyears of operation most of the bugs are probably
ironed out already.

Interesting problem. Let us know what you find out.

-Tom.

I created a database which my company has used for over 2 years at now
over 30 locations. Just today, one of the locations called and was
having problems with their program. The database is A97 runtime with
split front/back ends. They sent me their back end file, and 2 of the
columns in their Events table, all were somehow changed. One of the
values changed all changed to 0's, and the other all changed to 1's.
There are about 4000 records, and they're all changed.

The users can re-enter the values for the current data to get back on
their feet, and everything seems to work fine once the data has been
re-entered.

I don't have any update queries or anything in the program that would
go through all the records and check or change or update any of the
values automatically.

There are 4 front end users on a LAN with the back end at that
location.

Any idea what may have caused this sort of thing?

It reminds me of the UPDATE without WHERE statement error every
developer is required to make at least once, to get a feel for timing ;-)

Maybe there is such a statement somewhere? Or a WHERE clause that can
evaluate to True under certain conditions? Or just someone trying to
build a query for themselves, only to discover on test run "is it that
quick? Let's try it on the other column as well -- er wait, did it say
4000 records updated?"

--
Bas Cost Budde

[Kyle Keller]

Thanks for the replies, I have a little more information today...

Apparently a user was copying the entire program folder to his thumb drive,
and 'bringing it home' to work on. Then copying everything back the next
day. He would tell the rest of the staff not to make any changes, because
they would be overwritten the next day.

I can see him copying the files back to the server computer, while another
user is firing up his application... and I'm not a network expert, but
that's just asking for something to go awry. Its amazing what users will
come up with.

I found a .bat file in the google archives by Don Leverton/Trevor Best that
I'm playing with to automatically back up the back end file every day. It
looks like it will only work with single computer setups or on the network
computer where the back end file is located. Any other suggestions for
automatic backups?

Kyle

Bas Cost Budde <ba*@heuveltop.org> wrote in message news:<bv**********@news2.solcon.nl>...

Tom van Stiphout wrote:

On 27 Jan 2004 17:29:38 -0800, ky***@jsav.com (Kyle Keller) wrote:

It taught them the value of making backups. Did you have them sweat a
bit to drive home that point?
Corruption happens, but this seems too particular to be contributable
to random corruption.
Perhaps it's a disgruntled employee? Don't laugh - I've worked with a
client that had this happen, and we used security monitoring
(available on NTFS) to catch the criminal.
Don't count out your app too quickly, although I have to say that
after 60 locationyears of operation most of the bugs are probably
ironed out already.

Interesting problem. Let us know what you find out.

-Tom.

Maybe there is such a statement somewhere? Or a WHERE clause that can
evaluate to True under certain conditions? Or just someone trying to
build a query for themselves, only to discover on test run "is it that
quick? Let's try it on the other column as well -- er wait, did it say
4000 records updated?"