MIssing Records

[reichwaldl14]

Fairly new to Filemaker and the forums here, so please cut me some slack if this question is in the wrong spot or shows how new I am to Filemaker. Any help is appreciated.

We run Filemaker Server 11 and, often, when we run into a situation where one user is trying to access a record that is locked because another user is modifying it. After this instance, many times the record that was locked goes missing (deleted? launched into outer space? I don't know where it goes, but it ain't in our DB anymore).

Any reason why this happens? Do I have something set up wrong? Is there a way to prevent this?

[Vaughan]

The record should not go missing.

How complex is the database? If there are scripts that edit records then they should explicitly trap for the the possibility that the record is locked and take the necessary evasive action. IT my be possible that a script is not handling the record lock gracefully and doing something unexpected to it.

[reichwaldl14]

Thanks for the reply, Vaughan.

It often happens when administrators are making slight changes to the database (editing a field definition), never during scripts. As the admin implements the changes, Filemaker informs the admin that the process cannot be until the users finish with the records. If the admin waits, all records that were being worked on disappear. This has happened regularly from our migration from Filemaker on a single computer shared over the netwrok to Filemaker Server.

In an ideal world, we wouldn't be making changes to the database while records were being modified, but this isn't possible. Our database, while robust, is still getting new additions by the day, both in new records and database modifications. To answer your complexity questions would be difficult for me. I am new to database development and to me, it is extremely complex. It contains 45,000 (on its way to 100,000, if our owner gets his way) records that catalog our inventory. Additionally, we use the database to manage the inventory across multiple sales channels. The last element of the database is the storage and reporting of all inventory purchases and sales data.

As stated previously, all help is appreciated. But I am increasingly resigned to believe that this issue will persist and our database development will need to occur in short bursts of database downtime.

[IdealData]

If you edit field definitions on a live system then FMS will "freeze" the database whilst you make the changes - as you say scripts are not affected. I know, because I also work on a live system.

Consider making the changes in a master development file (off line), test them and then IMPORT the data from the server and re-load the new file to the server.

[reichwaldl14]

If you edit field definitions on a live system then FMS will "freeze" the database whilst you make the changes - as you say scripts are not affected. I know, because I also work on a live system.

Consider making the changes in a master development file (off line), test them and then IMPORT the data from the server and re-load the new file to the server.

Thank you, I will make sure to use this procedure. Just wanted to ensure that this was the issue, and not something else.

[Wim Decorte]

It often happens when administrators are making slight changes to the database (editing a field definition), never during scripts.

Not sure what you mean by "never during scripts"

Just know that making schema changes in a live system will produce some results that you probably don't expect. A "go to layout" for instance that happens when a layout change is committed will make FM go to the very first layout in layout order and will end up in a TO context that you did not anticipate. What IdealData said earlier in this thread: NEVER make changes to a live system. Do it in an offline copy and then do a proper version release by importing data from the live system when nobody is in the system.

[Steven H. Blackwell]

If you edit field definitions on a live system then FMS will "freeze" the database whilst you make the changes - as you say scripts are not affected. I know, because I also work on a live system.

Consider making the changes in a master development file (off line), test them and then IMPORT the data from the server and re-load the new file to the server.

Excellent advice as Wim noted. You could also use The Separation Model™ and avoid the import headaches.

Steven

[bcooney]

In a perfect world, one never develops on a live system, but we do--all the time. You must script robustly. You need to error trap any script step that can fail. For example, if a developer is modifying the Clients table, that table may be "locked" from edit to all users. That means, a New Record in Clients will fail. This isn't something you'd think of when you think of "record lock." Think "table lock!"

Investigate Todd Geist's Transactional scripting. Put If Get (LastError)=0 after Go To Related steps and New Record, etc.

[Steven H. Blackwell]

In a perfect world, one never develops on a live system, but we do--all the time.

This is courting disaster and inviting irreversible damage to the file, especially if this is done while users are connected. I strongly recommend avoiding this.

Steven

[bcooney]

I know you do, Steven.