We have many Filemaker databases hosted on server, but have one database that is giving us issues. On multiple occasions a staffer has entered a new file, and a few minutes later the record is gone. You know its been created because we use an automatic serial number for each file and that number is no longer there. When you perform a find, it cannot find the record for that serial number. I have already confirmed that there is not a script written for this. Has anyone else had this issue with Filemaker 13 and Filemaker 13 Server?

There are no known bugs in the platform that would cause this.  Invariably it turns out to be:

- a script deleting the record (perhaps out of context - are you doing live development on this file)

- the user deleting the record

- the record being reverted before the first commit

 

You mention the gap in the serial #: is the serial assigned on record creation or on commit?  If "on creation", change it to "on commit" if that work in your workflow and see if there still is a gap in the serials when the users next report a missing record.

Thanks for the reply Wim, we've had problems with "Ghost Records" as well. I've had it on my to-do list to fix this. I was planning on creating new records using globals and then send everything via a script when complete. We usually see this problem while using FM Go. I just changed the serial field to "on commit" so we'll see if that helps. Essentially it sounds like the same idea I was going for, except it's a thousand times easier. 

FileMaker Go can be destructive if a user gets disconnected from the server when a record is uncommitted.  FMGO will attempt to reconnect and then it has a tendency to record lock itself if it reconnects.  When this happens, FMGO will delete records.  I've seem it delete a whole found set of records.  FileMaker engineers know about this issue but they so far have not been able to resolve this issue.

The "on commit" did not work. It actually made things worse so I'm switching back to "on creation". Thanks for the response Rgordon. We've tried to help this by setting the iPods to not go to sleep, so they are always on unless you hit the power button. We've found this has helped quite a bit but there are still times when the wifi might be intermittent.

Changing to "on commit" wasn't going to solve your problem.  It was only going to fix the issue of your serial numbers incrementing when an uncommitted record doesn't get saved properly.  In fmgo you need to make sure that records get committed frequently, especially when entering data in a portal.  I use the following OnExit script trigger to minimize having an uncommitted record:

If (Get(RecordOpenState)>0

   commit record

EndIf

Thanks Rgordon. I just added that to the fields on our most problematic layout. I'll wait and see if any more blank records come up.