FM needs some time to index

[Ugo DI LUCA]

Hi all,

Not sure what words could be appropriate. Here is the case.

I have a script that generates in a loop from 20,000 to 30,000 records. When the loop is over, FM needs obviously some time to index all what has been entered through the loop, which somehow "locks" the user that had been driven to another file.

I'd like to make them wait in another layout with a "please wait" message, but how can I control how long they should stay there. Pausing the script won't solve the problem I think (Am I wrong ?).

The script ends with SetField(g_time, Status(CurrentTime)). I currently set the time gap to 1 minute, so that if they try to exit (from a button on layout), the script checks the elpase time from the g_end ...but 1 minute is what I guessed. Hmm...

There must be another way to do it.

Also, but this is less problematical, while creating all this script in a test file, I noticed that triggering a delete all records when there are currently 20,000 records in that file, leads to an awfully long "Search for unused blocks" (not sure of the translation). Is it always the case ? I'm not that familiar with delete steps. I'm that kind of guy that keeps everything since I was 15

Thanks as usual for any comments.

[-Queue-]

When you delete a large number of records and then close a file, it does the 'search for unused blocks', I assume, to recover the space left over from the deletion. Spatial recovery of 20,000 records can definitely take some time, depending on how much data each record contained.

I haven't, however, dealt with creating that many records at once. I wouldn't have a clue how to approach your situation. Sorry, my friend.

[stanley]

Ugo:

This sounds too simple to be right, but...

Can't you send them to a layout which has your message "please wait... processing" or whatever, freeze the screen, and let the process run itself out? You could even estimate the time of completion (based on number of records & tests, etc.) and put that on the screen as well. In a sense, part of this is training the user to be patient, like the first time the user encounters the "coffee cup" when the server is backing up, etc.

And yes, anytime you delete records you go through the "Searching for Unused Blocks," although I believe FM only does that when you close the file, rather than at the time of deletion. Oops, Queue already said that. The thing is, I think that FileMaker doesn't really delete a record while running - just marks the memory space (on disk) as trash - then the actual deletion takes place when the file is closed.

-Stanley

[Ugo DI LUCA]

Thanks guys,

Well yes it happens on the closure, but as I said, I quite never scratched more than 200 records at a time, and I can't remeber it had been so long. I just wanted to check there were no corruption.

About the "refresh" now.

I have a script that will run once for creation of records, then a daily update which will set an indexed multikey involving a loop script. Both scripts, when run are already set to be used with a Layout showing a progress Bar.

When the script reaches the end, they are driven to a "Completed" Layout, and then driven back to another file.

But while they would think they could do any job on this file, they would need to wait a few minutes before FM ends indexing (no message, just the "processor" noise).

The script isn't running so far, so I'm just making assumptions, from what I can see and do while developing it on my IMac running OS8.6 with FM5.5.

I can enter a few words, but then FM stall for another few seconds. Then 2 other words and stall again. It takes at least 3 minutes before a "normal" behaviour comes back.

I'm worried someone would try to launch a script from threre while FM was currently working "in the background"

One thing I must say. I never tried with 30,000 records. It might be the max number. With 2,000 records, this file (with no graphics and very little fields) already reached 22 Mo. But refresh happens either when creating or when re-building the Multikey.

So the big deal is. Is it possible to estimate the time needed before normal behaviour comes back ?

If not, if I pause them in the "Completed" Layout that has nothing in it, won't the "Pause" also stops FM's from completing the "indexation" ?