Avoiding Record Locks
For many FileMaker systems, the number of concurrent logged in users, especially those who will hit issues with record locks, is often very low. Typically, these types of systems are used within the local area network and you just ask the offending user to unlock the record. However, with the number of remote users logging into a system through the WAN, a variety of things have had to change. The way you architect a database system can't necessarily take the same approach as was done before.
As a FileMaker developer, you should now consider the remote user and plan your system accordingly. Fortunately, this approach can be taken at any point in the life cycle of a FileMaker system. You can retrofit or plan from the outset to use a very creative way of avoiding record locks. Quite simply, you provide each user with their own personal file.
If you're familiar with using External Data Sources within FileMaker, then this may be common ground for you. If not, then you'll find a ton of useful information within this video. If your users are accessing a system from across the globe, then using the know-how here will help alleviate a lot of connection stress and struggles because it's a method of data collection and transfer which directly emulates what users do when they interact with a standard web based application. Need the benefits of speed and performance? Look no further than Avoiding Record Locks.
Comments
Security
Thank you for showing this technique. I have a quick question; how do you setup security in the small UI file?
It depends
Security in the UI file can be set to allow any user to interact with the data (an argument can be made to support this, since the UI file doesn't actually store anything for longer than it takes to send the data to the host) or it can be set up with different user accounts. If I was going to implement the latter, it would have to be with externally-authenticated accounts (Active Directory, Open Directory, or one of the new oAuth options) - there is no way to effectively manage the security for individual accounts stored within the FileMaker file across multiple users with this technique. The only process I can think of is to let the user change their account password in their own copy of the UI file, and then upload that file back to the host, and store an individual copy for each user, and hope that they specified exactly the same credentials in each file... way too messy and error-prone.
--
Daniel Farnan
Ignorance is curable, not preventable