Jump to content

MIssing Records


This topic is 4334 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 4334 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.