Just picking your brains....

[Matt Klein]

Hi all -

I just want to pick your brains to see if anyone has any suggestions that I haven't thought of for a problem I am having in FileMaker Pro 6.

I have a script that loops through a found set of records. For each record in the loop, I loop through a portal whose relationship is a simple ID to ID and set a field in the record to itself and the contents of a field in the current portal row. After looping through the portal I then print the a page that has the local field that contains the field data from the records in the portal.

My client has been reporting that, the first time they run the script, the latest records from the portal do not show up in the field that was populated with the portal records. These missing records are usually within 2 weeks old.

I have not seen the problem myself, because subsequent runnings of the script produce the proper contents.

It's almost as if the records aren't showing in the portal until the script runs through once.

Again, the main problem I am having debugging this problem is that I can't reproduce it.

Any thoughts?

[John Mark Osborne]

My guess is record locking. If someone else is modifying those records, a script won't be able to write to them. If you have Set Error Capture turned on, you won't see the error message. The reason you can't reproduce it is because you are likely testing it in a single-user scenario.

In FileMaker 6, you only have to have your cursor blinking in a field for the record to be locked. In FileMaker 7 and later, you actually need to modify the record for it to become locked.

Your solution is to make sure you have full control of the records in the portal before you run the looping script. The problem is, it's not easy to determine if all the records in the portal are available especially since once you determine they are available, someone could click into them before you run the script.

Therefore, I don't run looping or Replace Field Contents scripts in a multi-user scenario unless there is nobody else on the solution. There's almost always another approach. Tell us why you need to run a looping script that modifies records and maybe we can help devise a workaround to avoid record locking.

[Matt Klein]

Thanks John Mark for your response.

I suspected record locking myself though this happens on most if not all of the records in the found set.

I added steps to check each record as I get to it to see if it's locked by a user and if it is I just skip over it.

Here's what I'm trying to accomplish and feel free to offer alternative methods:

I have a patient file where for any one patient there will only be one record. For each record in the patient file there may be any number of records in a case file. I use an internal ID number to relate the case records to the patient record.

When a case is transcribed up to a certain point, the users print a worksheet that includes the current transcription as well as information for each of the patient's previous cases.

To present this information from previous cases, I go to the related patient record in the patient file and loop through related case records in a portal setting a single field in the patient record to the contents of a field from each of the portal rows.

I suppose this could be done from the case file with a selfjoin(ID_Patient to ID_Patient) with the same method(looping through portal rows), but I doubt the result would be any different.

Another thought using the self-join relationship in the cases file that I thought about implementing was to Go to the related records based on the self-join relationship and loop through the records setting a global field as I loop through the records. It would work just fine if the users were printing one worksheet at at time, but this method ruins the original found set so becomes unuseful. Unfortunately, this app is not in FileMaker Pro 8 otherwise I could use mulitple windows.

[bdonelson]

Another thought, are you working with the data as your customers?

It is possible that your customer has a recently added record that does not match the same criteria as the set you are currently working with.

Bill