Data Loss??

[Maharg]

Hello Everyone...

My boss is convinced that we are experiencing data loss in our Point Of Sale database. Every so often we can't find a record, we have a paper copy of this record, but it is no longer in our database. The database is setup so every script that is executed in the database is logged (activity watcher) So if i create and invoice it will say in the log that I created it and the invoice #. When we look in the log for the invoice that no longer exists in our system, we can't find even the creation of the record.

We are running OS X.2.4 with FM Server 5.5v2? I think - We are also using Cron jobs to backup the files to a mounted remote volume. @ 11 oclock the filemaker database is paused through the cron job a minute later it copies and then resumes the database. Can this have anything to do with the missing records? (maybe if someone in the office is still on the record)

I don't believe that we are experiencing data loss, I think it is a user error somewhere down the line however, I am curious to know in what form does data loss occur in FM. WHole records, just, some fields, or random text??? Thanks very much....

[dkemme]

These are tough ones to track down. I have never noticed a record being lost due to creation near a back up time. I wonder if the record is being deleted somehow later on, or even used for another piece of data. Are your records assigned a serial number upon creation? If so, you could sort by that serial number and see if any are missing. Do you use an identifier after creating a record that assigns it to a particular sale that could be modified after it is printed, making it look like it disappeared? Just a few ideas...

[Ted S]

Good afternoon,

Something that I have seen happen before is that a user will completely change an existing record all the while thinking he is adding a new record. I have noticed that that if the the steps to do a query are to press a find button (to put the user into the find mode) and then press RETURN to execute the query, new users don't find this method very intuitive. They seem to find it more natural to press a FIND button after they have entered their criteria which often means that they have altered an existing record before actually going to the find mode.

This built-in query ability of FileMaker is a plus for experienced users and developers but it seems to lead to lead inexperienced users astray. I've taken to building search only layouts for databases in wide release.

Maybe this isn't your problem but personally I've seen quite a few records "disappear" in this manner.

-Ted

[Fitch]

OS 10.2.x is dangerous for FM Server. Be very cautious.

http://www.filemaker.com/ti/108428.html

However, this is probably not the issue in your case, or you would be getting "file is damaged" alerts.

[LiveOak]

IMHO FileMaker Server under OS X is a "not quite ready for prime time player". We have learned to fine tune FM Server under OS 9 to such a fine degree using RAMBunctious and Peek-a-Boo that I don't see the advantage to using OS X at this point in time. Why trust mission critical data to an application that the manufacture admits has such serious data corruption problems. Kind of like buying a car with the warning that in some cases when you slam a door that whole vehicle may go up on a ball of flame, so you should wear Nomex clothing when driving!

-bd

[Maharg]

Thanks for all your input. To answer a couple questions that arose in your replies:

The possibility of changing the record being deleted by accident is not likely in out system because once it is marked "complete" only our POS administrators can change something and even then it is limited.

The invoices are given a SN value increased by one upon creation. We have exported SN to an excel file and found that we are missing a total of 7 records.

Thanks for the warning about 10.2.x - I will look into that although the only other problem we have had is the irregular backups through the server based scripts. We solved that issues with cron jobs that seem to work fine (if they aren't causing dataloss that is)

Thanks again,

Maharg

[Garry Claridge]

Could a clash of record creation scripts be the problem!

Garry