This can be done but i advise caution.
You could script a process using Install On Timer and GoToOjbect with no name to run every XXX seconds that would release record lock but as soon as a user is entering data when that timer fires youll have a whole other class of complaints to address.
I would investigate a scripted data entry process when a user enters data into globals and clicks a save button when done so that the records are only locked during the time it takes to commit the records.
Google FileMaker Transactions
1 of 1 people found this helpful
Don't modify the client's record when they scan in. Log the scan by creating a new record in a related table linked to their client record.
1 of 1 people found this helpful
I would too see - and store - all this as new "events" linked to the client, asphilmodjunk 's post implies.
The data would feed portals on the client's screen (maybe timestamp ordered desc) and would eventually have to be post-processed.
There may not need to be any "post processing" to do. Using a related table to list each time a service is provided should work pretty well for managing the process and for generating reports on who received what service on a given date.
If the front door registers the event of me coming in it should post process it by fetching my reservation and bringing up the table number I was assigned to, that's what I meant with post processing.
That makes sense. I was picturing somehow updating the Client record at a later point in time and that probably would not be needed.
Note that you can scan the data into a global field where a record creates a new record using the scanned ID to either link to the client record or to look up a Client record ID to use to link the record. Then other fields can be filled in as needed to log the type of service provided for that "event"--and that can include looking up a table reservation if they have such. (I'm picturing a homeless shelter or group home so maybe not....)
We are in fact a homeless shelter. Services we document include entry into our shelter, meals, extensive personal info re each client, case management services, food bags, bus passes, and clothing.
I think what you are suggesting is that for all the scanners, we set up the scan script in the related file as opposed to the master file. (Currently, we use portals in the master file to do all the data entry).
Thanks for all the suggestions, I'll give it a try!
From this additional info it seems to me that the scanning in is basically your means of accessing various services, and that each access is an event in itself. For that reason Phil's initial suggestion would seem to be the way to go. The card scan should give you the ID of the cardholder, and you can link the event table to the cardholder record via that. This would be far better than trying to update the cardholder record directly every time a service is accessed.
I don't quite understand your response so I'll provide more information about how it is currently set up.
We create for each client a barcoded, picture ID. Upon entering our center, each client scans his ID. Each client also scans each time he gets a meal. The Scripts for these events record the date, time, and whether the person entered or got a meal, and which meal it is, based on the time of day. This data appears in a portal in the master database called "Clients". Of course, it is stored in a related file called "EntryMeals."
For the other services we provide, such as Food Bags, and New Socks, similar data is scanned in each time they get that service, appears in portals in the master database, and is stored in related files named, "Food Bags", and "New Socks."
When we provide case management services, our staff enters the data into the master database, though some of this data is stored in a related file.
Each client might get five or more services per day. It can happen that we are unable to enter data about a client because the client record is up at another work station somewhere in the building. So the staff member has to go looking for which of 15 computers might have the client's record up on its screen.
As things are quite chaotic here all of the time as it is, I'm just trying to figure out how to prevent this from happening.
For more information about us, here's our website: www.seniorsupportservices.org
Thanks for your help!
If the data being entered for a client at the time that their ID is scanned is being entered into data put into portals linked to the client record, you can redesign the process to put the data into the same record without locking the parent record. When you start with a layout based on the client and manually enter data into a portal record, you lock both parent and portal record and it's the lock on your parent record causing the problem.
But if you pull up a layout based on the portal's record and use the scanned ID to link it to the correct client record, you can display (but not edit) the client data on this layout and enter in the needed data in the related record. This does not require adding a separate file, just changing the layout context to avoid the use of a portal on a Client based layout.
Thanks for the extra info Leon. That's pretty much the way I imagined things needed to be set up: Clients in one table; Services in a second table; Accessing of services by individual clients in a join table. So the answer probably lies in the interface, as described in Phil's latest post most eloquently. If your interface is based on the join table, then any workstation will only be creating a new join record, linked to both a client and a service, but not locking either.
Interesting website, by the way.
Thanks for all your suggestions folks!
I will give "join tables" the old college try.
I've looked into Join Tables and before I attempt to make these changes, I'm hoping you can provide a bit of guidance.
The parent file is named Clients, and one of the related files is named Meals.
You are saying, I think, that I should create a Join Table to act as a go-between between these two files.
Clients to Join Table to Meals. This will serve to prevent records in either file from locking up when in use.
The only way to connect the files is via the Client ID#. So, I should create a Join Table with one field in it, "Client ID#", and then connect both Clients and Meals via the Join Table containing the single field, Client ID#.
I probably need to eliminate the direct connection from the Client file to the Meals file. (?)
Is this essentially correct?
Thanks for any input,
You may not need to add another table.
Set up a layout based on Meals. WHen you want to log a client's receipt of a meal, Create a new record on this layout and enter the needed client ID to link it to the appropriate Client record. Swiping the ID card can enter the ID into a global field that either is used to look up the Client ID or actually stores the ID (Depends one what data is received off the ID card) to use in creating the new record and linking it to the correct client.
Where, as a more extensive fix it might be useful is if you had a join table where each record represents one instance of service received by a client with an ID that identifies the type of service and another ID identifies the client. That may make for better reporting and management of your system, but isn't needed to solve the original problem mentioned in this discussion--locking each other out because a client record is open for editing on more than one computer at the same time.