Newbies tom duckers Posted August 18, 2008 Newbies Posted August 18, 2008 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 ]
Quartekoen Posted August 18, 2008 Posted August 18, 2008 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.
Søren Dyhr Posted August 18, 2008 Posted August 18, 2008 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
Vaughan Posted August 18, 2008 Posted August 18, 2008 "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.
Newbies tom duckers Posted August 19, 2008 Author Newbies Posted August 19, 2008 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).
Recommended Posts
This topic is 5941 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now