shared dB / limit layout to one user at a time

[innodes]

I have a shared dB that has a few input layouts that need to be limited to one user at a time. Is there a script that will check the server and if that page is in use by another user, will block entry?

thanks

[Fitch]

FileMaker will only allow one user at a time to modify a record. Is that what you're asking?

[innodes]

We have developed a method that will check the current sku number and increase it by one. This sounds like the built in serial number function, but is not. The serial number function starts and continues as used. If a user deletes a file or two during its use, there are missing numbers (skips or blanks). So a script was developed that will check the table against itself and count the highest existing number. It then adds one. Then if a number is used and deleted, the script always recounts, eliminating blanks(thanks JMO!).

The problem we just found is that until all of the record is completed and "entered", that number and record is just sitting open. The sku number identified as "next in line" has not been saved yet. If another user gets on to create a new sku while the first user is still in process, the script grabs the same "next" number. Walla, duplicate sku numbers. This is not a good thing.

So I was hoping there was a way to limit the use of this particular layout (not the whole file) only to be used by one person at a time.

thanks for any help,

[Fitch]

I assume that you're using a script to navigate the user to the entry layout. What if you included a step that makes a new record in a "temp" SKU table. When the next user goes to create an entry, it can search the temp table and if it finds a match, it can prevent the second user from proceeding. Once the entry is completed, the temp record is deleted.

You could also reverse that idea, so when you complete a record it creates the "next" SKU in a temp table. When a new entry is made, it grabs that number and deletes the record. When the second user tries to create a new entry, it checks to see if the temp table is empty, and if so, stops you.

Another option might be to commit the new entry on creation, rather than upon "completion." Or are you using global fields for entry?

Another option is to use a single-record table for entry. Only one user at a time can edit a record. Oops, I already said that.

Another option might be to use custom privileges with a calculation. Your script could put the current user's ID into a field, and then clear the field when completing the entry. Field (not layout) access could be controlled with a calculation based on the field value. You'd have to carefully test this.

[innodes]

I'll give it a try and let you know.

thanks,

[innodes]

Got it, thanks. I took a variation on your "commit on creation" idea. Since this is a totally manual "scripted" number creation, there was not an option to select that feature. However, by inserting the Commit Records/Requests into the script just after the number is created, it does what you suggested and what we needed!

thanks again for the thoughts. have a great week.

[innodes]

We have been running this for a while, and thought it was fixed. We just caught a duplicated number. In deeper testing, I am finding that the "commit record" in the script is not committing until all fields are complete (a requirement). Is there anyway to force a commit, so the record is saved, temporarily overriding the field fill requirements (invisible to the user), but then bring the user back to the fields that require input?

Here is how I have it today:

New Record/Request

Set Field [blaa, blaa, blaa + 1]

Allow User Abort [Off]

Set Error Capture [On]

Commit Records/Requests [No dialog]

Set Error Capture [Off]