2 of 2 people found this helpful
Is the script trapping for an error after Commit Records? It sounds like it's not.
Try turning off error capture and running it from filemaker pro, see what happens that prevents it from continuing. It sounds like some validation rule you've setup has prevented the script from continuing, even though you think it has been committed successfully.
Please share your script as well so we might assist with identifying any logical errors.
Thank you for your suggestions.
I've looked carefully for any field validation rules, but there don't seem to be any.
I turned off the error capture as you suggested and saw that no records were found, as expected.
The script fails when I create a new record following a test to see if there are any existing records that qualify. No records are found, so the new record is created. All seems fine until I activate the next script.
I don't know how to copy the script into this message so that you can check the logic.
You can use the picture tool in the tool bar of your reply box to add a picture. That can be a screen shot of your scripts workspace. You can also print a script to a PDF and copy/paste the script as text into a reply. You can also, if you have FileMaker Advanced, copy/paste a script from a Database Design Report to this forum. And there are plug ins that make copy/pasting scripts as text possible.
Speaking of Advanced, if you have that, you might run your script with the script debugger enabled to watch what happens. You might have a completely different script, say performed by a script trigger tripped by your first script, that is opening a record for editing and thus creating the error message that you report.
I'm attempting to find records that qualify based on an account number, then constrain that set to find only those where a particular field is blank.
I haven't been able to achieve this with the Find Record script step because Omit = "" doesn't seem to work. So I've used:
Enter Find Mode
Set Field ; Account Number
Set Field ; ""
This leads to the problem.
1 of 1 people found this helpful
Given the complexity of this script, you really, really need advanced. The debugger and data viewer alone can save you HOURS of frustration trying to puzzle issues like this out.
What you can do with your current setup is to temporarily add some show custom dialog steps into the script at different points and pay attention to which ones appear before you get this error. That may help you narrow down when such it is happening and that may be enough to figure this out.
PS, to omit records where a field is empty, specify the * find operator in the field. This can be done with "*" as the calculated result of a set field step. To find records where a local field is empty, use "=". Tof find records where a related record's field is empty or there is no related record, use "*" in an omit request. And Omit Record while in find mode, changes the current request into an omit request just as though you clicked the omit button in a manual find.
Thank you for your very helpful comments which clarify some things that I didn't know - especially how Omit Record behaves in Find Mode; the Help documentation doesn't seem to be helpful on that point.. I'll work through your suggestions and get back. I'll also think about Advanced for my context.
1 of 1 people found this helpful
Here's a link on scripted finds that may be helpful:
The discussion got hijacked recently by a member needing help with a particular find script, but the first part of the discussion lists a number of script examples for how you might script a find.
Thank you for getting me over the line when there was no obvious connection (to me) between the symptom (being forced to revert records) and the disease (not using: Omit Record, and Set Field ; "", correctly in my find request. I've laboured for hours in the wrong ballpark, so thanks for identifying the real problem.
[If I may go off topic for a moment, and I may open a fresh discussion on this, can you provide any links that might help me to avoid problems when this app I'm working on goes up (hopefully on FMCloud) in a multi-user environment. This is my first experience in attempting this, and I've already realised that public records can't be modified to suit the needs of each user the way they can in a single user environment.]
and I've already realized that public records can't be modified to suit the needs of each user the way they can in a single user environment.
I'm sure there's a reason, but it's not obvious from that sentence. Not sure what "public" might mean in terms of your solution.
Global fields are something to research. They don't work the same in a hosted solution. That's generally a good thing as it makes them very useful, but it catches a number of new users by surprise. If a client changes the value to a global field, that change is only visible to the client that made the change. When the client closes the file, the value of the global field reverts to the value it had when the file was uploaded to the server.
You need to read up on record locks that occur when one user starts editing a record and another user then attempts to edit the same record or runs a script that tries to do so.
Manage Security becomes an important topic as you frequently need to grant different access options to different groups of users.
By 'public' I was trying to distinguish between records only accessible by the Account Name and records available to all users of the file, i.e. the public. My usual practice for a single user file would be allow the record to be classified by the user into categories of A, B, or C, so that the record could be found later based on Category. However, this won't work in a multiuser situation. There are undoubtedly may other precautions that multi-user files have to take into account. I thought that there may be a link that summarises these in the helpful way that the 'Scripted Find Examples' did. I'm not sure of the terminology to use to find the link I'm looking for. Thanks again for your help.
If the records already have access controlled via Manage | Security so that only records with the current user's account name may be viewed, then you need do nothing to your system of classifying records into categories.
A find for records of category "A" will automatically omit any records that Manage | Security is set up to keep them from viewing.
There's a find tool you can use to research the forum via keywords such as Record Level Access Control or Record Lock to find useful info. There's also a knowledge base where you can search out technical info: Click "Return to FileMaker.com" at the top of this screen, then select the option for the knowledge base from the support drop down.
This is getting interesting. Rather than leave your response buried under the wrong discussion heading I've opened a new discussion, "A Cautious Leap from Single to Multi-user Apps", so that other members can more easily find your answers. I hope that's OK.
Makes perfect sense.