How to trap "Save record" event

[WestCoaster]

Hi all,

I am wondering if someone found out a way to trap the "save record" event within an FM script.

What we are trying to do is to change values in another database system depending on whether the user chose to save modifications he made in a given record in FM.

Using that specific layout option FM lets you prompt the user if he wants to save his modifications but up to now I did not find any way to trap that event, i. e. to branch an FM script into whether "trying to leave record after modifications made" / "leaving record unmodified".

Any suggestions?

Greetings from Germany

Tom

[LaRetta]

Hi WestCoaster,

There are probably additional ways using AppleScript but I would use an event trigger plugin. There are many available. Some event-trigger plugins are free; some inexpensive and some costly. They each have their value. For instance, I use SecureFM which can trigger (using auto-enter) based upon a record's modification date/time stamps.

How you would then pick up that change in your other database would depend upon your setup but an FM script can fire based upon the record modification change which could perform an export for you. Script-step 'Omit Record' then 'Show Omitted' will give you only that record in the found set for export. If you are interested in event triggers, perform a search here ...

LaRetta

[Vaughan]

One method is to do all data entry into global fields. The data is only entered into the real record fields when a "Save" button is clicked.

[WestCoaster]

Ok, that's what we have been doing for a long time and what is a rock solid way of doing it. However the downside is that every modification you make in the solution means triple the time you'd need otherwise: The field itself, its global correspondant and another layout where the global field resides - which to make things worse usually won't look like the "original" layout.

Cheers

Thomas

[WestCoaster]

You mean a field which holds the modification time/date of a record and is updated automatically each time a record is changed and which then triggers an FM script using a plug-in? That sounds interesting but in my experience that kind of modification field doesn't get refreshed properly, i. e. you first have to enter it to refresh it especially when the table grows more and more complex.

So to make this really save you'd have to setup a comparison field 'Modification date/time old' and an additional calculation field which compares 'Modification date/time current' (the one you suggest) and '...old'. Only if these two differ then the calc field should produce a marker by which you can determine that this is a record on which a script has to be performed. Just 'omit and show' of the modified record most probably would leave the user with a selection of records which he doesn't intend to view.

Cheers

Thomas

[Dan-A]

I must be out of my league here but here goes anyway!!!

can't you just have 2 buttons in your layout??

Save, Cancel

One with a record commit and run your script from there

the other to undo changes made.

Just a thought.

Dan

[LaRetta]

Hi Thomas,

If you have a TimeStamp field established (called ModDateTime), Auto-Enter (Modification Timestamp) it will change after every modification to that specific record. You should have a Create and Modification field anyway. Then just create a new standard field (timestamp, number or text, doesn't matter). Set it up to Auto-Enter (with Do Not Replace Existing Value UNCLICKED) and enter a calculation thus (example based upon SecureFM):

ModDateTime & External ( "Menu-PerformScript"; "YourScriptName")

You do NOT have to be in either field for them to update or fire. Any change to a record and ModDateTime will change which will trigger the new field & script. You can download a SecureFM demo to see it in action. I am unfamiliar with other event trigger plugins but assume they work the same.

Exports only work upon a found set - such is life. And you are correct ... You would end up with a found set of 1 for the export and lose your existing found set. But you could include a Show All Records or even Perform Sub-script of the script which brought the User to their existing found set; and even place them back on that specific record. Again, much depends upon your current situation which you haven't explained.

Easiest way ... create another table. Join tables on UniqueSerial using =. Select 'Allow Creation of Related' in this new table. When your script fires, set the appropriate fields (in the new table) with the data you require (in your other db) from the modified record; which will automatically create the new record. Then execute your export from THAT table instead. Would look something like:

Freeze Window

Set Field [OtherTable::AnyField; CurrentTable:Anyfield ] ... etc.

GoToLayout (Other Table layout)

Show All Records

Export [ ]

Delete All Records

GoToLayout (original layout)

Using Show All Records & Delete All Records would just be a safeguard but be careful if multi-user because of possible timing problem, ie, if a User modifies a record it may be created after the export and before the delete. And you would need to move this exported data to your other DB immediately or it would be lost by the next modification export (overwriting the txt file). There are also ways of storing the exports in multiple files using Troi, etc. - again, depends upon what you're doing.

Probably better to let the modification records accumulate in this new table and execute your Export script at a later point (as a group) when you have control. You could then Find [ ] a specific group without export/deleting newly created ones rt. Or leave them there - kinda nice for an audit trail. Just flag with ExportDate and only find those not yet exported.

Your existing found set (and record location in your current table) would then be preserved and Users won't even be aware of what is happening.

LaRetta