Needs a primer for multi-user settings....

[DanBrill]

Hello all,

I've developed a good solution to be used in stand-alone settings. Now I need to make it multi-user-friendly.... I've done the obvious things like setting the files as multi-user. But what do I need to do to make it really multi-user friendly? When writing flat-file db's in Perl, I've gone to great lengths to make sure that one user wasn't using a file while another wanted access to it. What do I need to be aware of in File Maker? How do I deal with 2 users wanting to access a file at the same time? What happens when scriprs collide? Where should I go?

Thanks for any insight.

Dan

[ernst]

Hi Dan,

This is a subject that would deserve a forum by itself I think. Or at least more threads than there are now.

Basically Filemaker will not let more then one user modify a record at the same time. Several users can be viewing a certain record, but if one of the users has his cursor in a field all following users who try to click in a field will get an error message saying "This record is being modified by user X".

Unfortunately there is no way to remotely 'kick' a user out of the record, so hopefully this does not happen on a global network, with the user that's locking the record being on holiday with his computer left on...

If the database is relatively straight forward and accessed one record at a time this is the main problem that can arise. More severe problems can occur when a record is accessed via a script, for example causing an infinite loop when a script tries to access a 'busy' record, or when a group of records is changed via a script or a 'Replace' command. Ideally the developer should make built-in checks for such errors and also test, with a second machine at hand, if these errors are captured in an appropriate way.

When performing critical operations on a group of records it could be a good idea to have a separate error-logging database.

The errornumber that Filemaker generates if a record is busy is 301, so that could be used to determine these kind of errors.

One other thing that I found on this subject is that if one uses a script to loop through the related records in a portal, an error already occurs when performing the 'goto portal row' script step, even without actually entering a field from that 'busy' related record.

Hope this gives you some idea of what to expect when going multi-user.

I'm also very curious what other people have to say about this -imo very important- subject.

Best regards,

Ernst.

[DanBrill]

Thanks, Ernst. This should get me started. Fortunately this won't be used globally. The worst is that someone will have to walk across the office and give their napping co-worker a nudge. I'll have to 1) get myself a second copy of FM to test across my network, and 2, check out all of my scripts to see what happens when they run a a record that is in use.

Anyone else have insights? It seems that this would be a big topic.

Thanks again,

Dan

Dan

[Anatoli]

You can check for Status (CurrentError)

But collisions between users are not that common.

[LiveOak]

One option is to use a scripted modification of a records that: 1) copies the record contents to global fields, 2) displays the global fields on a screen for modification, 3) then attempts to write the global values back to the actual fields when the user clicks a "Submit" button. This at least gives you a single point for the script to check if a record is in use and,if it is, pop a message that modification is not possible at this time. Whether the situation occurs often enough to warrant this complexity depends upon the situation.

Similarly, you can manually mark records as "in use" and lock other users out before performing scripts that use replace statements across a bunch of records.

-bd