August 18, 200817 yr Newbies Hi, In a 'price file comparison' solution I have a script which deletes an individual price file and its parent supplier record. Script is as below, triggered by a button on the parent record. My problem is that sometimes there is a delay before the custom dialog is displayed. In this time filemaker is performing a find. The delay seems to be proportional to the size of the price file in question and for long files the 'finding' box is displayed briefly. If you wait for the find to complete, decline to delete the file then run the script again it goes straight to the dialog. This isn't a killer problem but I'd rather cut the delay out of the process, has anyone got any ideas why it happens? Regards Tom The script: Set Error Capture [ On ] Show Custom Dialog [ Title: "Are you sure"; Message: "This will DELETE the current list for this supplier: proceed?"; Buttons: “OK”, “Cancel” ] If [ Get (LastMessageChoice) = 2 ] Exit Script [ ] Else End If Set Variable [ $pk_sup; Value:Suppliers::pk_Sup ] Go to Layout [ “pricelist for delete test” (Pricelist 5) ] Show All Records Enter Find Mode [ ] Set Field [ Pricelist 5::fk_sup; $pk_sup ] Perform Find [ ] Delete All Records [ No dialog ] Go to Layout [ “SuppliersInfoForSupplierManagement” (Suppliers) ] Enter Find Mode [ ] Set Field [ Suppliers::pk_Sup; $pk_sup ] Perform Find [ ] Delete Record/Request [ No dialog ] Perform Script [ “VieworEditSuppliers” ] Exit Script [ ] Set Error Capture [ Off ]
August 18, 200817 yr The fact that the first find takes a while, and the second is pretty much instant implies that during the find, Filemaker is creating on-the-fly indexes for your fields. Once it finds the record, it knows the index, and thus jumps right to it next time. You should probably be able to remove that delay by editing the storage options for the field you're searching through. Try setting the indexing to All, but remember that this will make your files larger, and may slow it down in the beginning while it creates the initial indexes.
August 18, 200817 yr Couldn't you exploit cascaded deletes here? Set Variable [ $zap; Value:Main::parentID ] Duplicate Record/Request Enter Find Mode [ ] Set Field [ Main::parentID; $zap ] Perform Find [ ] Delete Record/Request --sd
August 18, 200817 yr "The fact that the first find takes a while, and the second is pretty much instant implies that during the find, Filemaker is creating on-the-fly indexes for your fields." Not necessarily: even if the field is indexed, FMP has to pull down the index data from the server to the client. With large files this could take a while. Once it's done the data is CACHED until the index changes.
August 19, 200817 yr Author Newbies Thanks Soren, I should have thought of that, it cleans the script up nicely. And on the original issue (which I didn't explain very well), the apparent delay on the execution of the first script step was nothing to do with the script and everything to do with an unnecessary field on the layout (that was being refreshed when the record was selected).
Create an account or sign in to comment