1 approach you might like to try would be to push all the fields that need this into another table. This way the user will be accessing a record in one table, but another user will be accessing a different table, hence not locking the parent record.
Yes, I think that will be the solution but I am going to wait a little while and see if there any other options.
That was my original apporoah to this solution but allowed myself to be pushed into the current situation because of a need for a rabid solution.
One other thoughtthat just struck me…
You could allow users to enter the data into globals, then save that data into the appropriate record. You'd probably need to have a table to hold the globals but should be able to make it work.
Possibly having a save script that checks to see if the record is open and if so loop until it isn't (assuming this si the only place people enter data).
Thanks for a very interesting idea worthy of futher study. It is certainly out of my currrent comfort zone but one I may use to move to a new level in FileMaker programing.
Give me a shout if you need a hand.
Caveat: Be careful with global fields when using IWP. You will still need a separate record for each IWP user, even if using global fields.
FMP users enjoy what can be perceived as field locking when using global fields, while IWP locks the entire record.
Understood, I was wondering about that.
U quasi answered urself correctly in ur hunch that a no was coming.
Just to confirm, there is no way to turn off the behavior of record locking.
If a field has been entered on a record, that record is off limits to other users
Depending on how u have ur solution wired up, it can lock out any number of parent records as well.
Ur on the track with the ideas in the thread.
Basically , u want to abstract away from making direct edits to the data.
Instead , u want to create a "form layer" where edits can be made by individual users and pressing commit is the only window when u r actually touching (and thus locking up) the record.
U can do this any number of ways. The two that I tend to use are a) each users has a session table which includes a set of universal form fields. Any time they are looking at data and make a move to edit that data and /or create new, they are pushed to these form fields (whether they know it or not).
When they commit, the data is pushed into the real data table and their form is cleared out.
There are a lot of Bells and whistles but that is the gist. The other approach is to use a webviewer and display a cool form made with html / CSS / js. This requires capturing the inner HTML of the form - a process easily handled with a plug in and not so easily handled without.
One caveat to watch for - the good side of record locking. When u shut down filemakers ability to make sure that data integrity remains solid during modifications, u need to assume the role.
What happens when a person goes to make an edit on data and while they are making a change, another person jumps in a changes the data they thought they were changing? This is followed by unsync'd commits from different users and when the smoke clears, a frankenrecord emerges with data from various users unwittingly merged into a record. U will want to get hip to get(recordmodificationcount) so u can compare the number when user starts their edit in the abstracted form and when that data is pushed to commit. if the number isnt the same, the data has been modified since user went to edit it. also, forge a law to build to as far as how commits work in ur system.
Thanks for your reply and it cotains very good information to be aware of.
I think this idwhat I am going to try and do.
Currently when a user sellects a section to enter data [results] they are directed to the appropriate layout and taken to the last record. If the user see last week datal they create a new record and then enter their respective data. If they see the properr date and no data they then enter their data. But this is where Record Locking can occur if someone else is entering data on any of the other section of the same form.
As a result I am considering the following:
The user selects his section to go to and then creates a new record even if he sees the proper date on the blank layout he is taken to. and enters his data.
At the end of the day there will be 7 new records with same date and the approprite information entered in each [Finance, Marketing. Operations. etc.]
The task then will be to Merge the information into one Record and that record will be the source for all Reports.
Question Can anyone share anything about merging records into one record. Perhaps an On Exit Layout ScriptTriger tha will fire out another script.
Ant ideas will be very welcome.
1 of 1 people found this helpful
I suggest you split each section into its own table. There are a couple of reasons that might influents your decision.
1. When FMP downloads a record it sends all fields for that record. This means even though the user is only looking at one section the entire record, all sections, is downloaded to his computer. If this solution is going to be used over the WAN the latency could cause performance issues.
2. You don't get record locking if only one person is editing the section.
And one bad reason:
Doing Finds from the main table using one of the section table fields will use unstored (slow) related record searching.
Mitigation, script finds to be performed in the original data tables and use a looping script in the main table to find the ID's of the found records. GTRR for the found set will work for a single related find but not for finds bridging two or more related tables. Combining the two methods would probably yield better results.
1 of 1 people found this helpful
It might be beneficial to back up from workflow considerations and think about data modeling first. What does each one of these records represent in the real world? Go back to relational database fundamentals: Each record represents a "thing" of some sort, unique in its own right.
Naturally, you can break normalization rules if workflow considerations demand it, but you may find out that a properly normalized database will eliminate some of these "different departments with different inputs" issues.