FileMaker migrates very easily from single user to multi-user just by hosting it on the server. Record locking becomes an issue, but FM warns you when that is happening and pauses until it is rectified and identifies who is locking a record, etc. You need to plan more about using global fields that are session dependent, etc., for certain things where you don't want users to see the same piece of information, but still want to use the same field (e.g., input to a prompt, etc.).
Multiple people can use the same script at the same time. They cannot Edit a script at the same time, but as many people as you want can run the same script at the same time.
Scripting for multiple users includes planning on what to do with record locking or other things where something fails. In fact, all good scripts have to plan for error capturing and what to do when an error occurs, even if is as simple as doing a find and not finding anything.
PS: FileMaker's Error Capture codes can be returned to a variable by using Get ( LastError ) and the error codes can be decoded at: FileMaker Pro Error Code Reference Guide | FileMaker
set error capture (on)
Commit Record (dialog off)
set variable $Error = Get ( LastError )
set error capture on
If ( $Error )
Show Custom Dialog Box ( Error, changes could not be made because the record was locked)
otherwise.... continue on script....
PPPS: Don't be terrified. Most of what you have will still work. You just need to do some minor modification to make it multi-user friendly.
Do you have backups? Check there first
No problems if two users are clicking on the script. Each FileMaker Pro handles each request to FileMaker Server itself.
By the way, if you're feeling overwhelmed, there are a lot of FileMaker Consultants out there that are available to hire to help you out. FileMaker calls them "Partners". But you can find a list of them at FileMaker Consultants, Data Consultants, Database Consultants There also are FileMaker Trainers and of course quite a number of online video training. But for your specific database, it is hard to best getting a consultant to assist you directly.
I will continue to plug away asking questions. I keep reading about "User Tables" were creating a record that holds the user's AccountName and to set a script when the file is open. I'm a bit confused. I don't know if I should create 1 record for UserID and AccountName setting the AccountName to a calculation field using Get (AccountName) and set that to global storage. Or, shall I create a record for each individual user to have their own UserID.
Once I do get this answer either by trial and error or someone gives me the answer I don't fully understand how Filemaker will use this information any differently that if I where to set certain fields in a table to auto-enter the AccountName. This auto enter seems to already capture what this User-Table is being created for. Please help me understand.
"user tables" are only needed in specific circumstances. Don't go there unless you find that you have record locking issues that are best solved by that approach. If your users aren't editing portal records from the context of the same parent record, you probably do not need them.
Thanks Phil. Yes, there are no portals in which a user can edit. As the clouds are clearing on my original post I'm starting to feel a little better. I will add the error capturing on in my scripts.
1 of 1 people found this helpful
I will add the error capturing on in my scripts.
Remember that when you set "set error capture [on]", it is then up to you to trap for errors at crucial script steps and then handle that error (decide what to do).
So every time you create a new record or you change data on a record, use Get(lastError) and decide what to do.
Also be aware that as you develop on a live file you will generate 'schema locks' that can block users momentarily from creating new records. So once you have other users actively working in the system, be very careful with the live development unless you feel comfortable that you are trapping and handle all possible error scenarios.