Comments on: Importing Records to a Backup – Brute Force

By: Dominique

Dominique — Fri, 25 Apr 2008 06:45:25 +0000

Hello,
Thanks for this interesting article.
I was not able to find the “more surgical technique” on this blog.
Is it somewhere else or not out yet ?

Thanks anyway for all these usefull and practical blog entries…

Dominique

By: David Head

David Head — Thu, 27 Sep 2007 05:59:08 +0000

Quite true Jesse. I was not aware that the behaviour had changed so long ago!

I found another interesting thing:

Perform a find in a table
Close the file
Open the file
Same found set

Then:
Omit a couple of records
Close the file
Open the file
Old found set (ignores omits)

Then:
Show All Records
Close the file
Open the file
Old found set

But then sometimes it is inconsistent in this behaviour. I would be interested to know the basis of all this.

By: Jesse Antunes

Jesse Antunes — Tue, 18 Sep 2007 00:09:19 +0000

@David – Could you clarify your comment a little bit for me. I would like to add a note to the post about it but I’m unclear on what specifically you are referring to.

When a file is closed, it will import all the records in the table in versions 7+ despite there being a found set. I don’t believe that it is specific to 9.

I am definitely going to add the not that when a file is closed all records are imported from a table just as a point of interest anyway though.

Thanks again for the comments. We appreciate all the input.

By: David Head

David Head — Sun, 16 Sep 2007 03:08:54 +0000

Hi Jesse
You note that “we are using the Show All Records command in the damaged file before importing is because FileMaker only imports records that are in the current found set of the file which is being imported (if it is open)”.

You correctly note “if it is open” but I think it is important to note explicitly a (welcome) change of behaviour in FileMaker Pro 9 to which you may be alluding.

If you import from a table in a closed file, even if there is a found set, it will import the total records. Nice!

Conversely, if you DO want to import a limited set of records, you must have the file open to establish the found set.

Cheers, David
uLearnIT

By: Jesse Antunes

Jesse Antunes — Sat, 15 Sep 2007 09:38:21 +0000

@Bob – Wow, That’s a lot to digest. I think basically what you are trying to say is automate the whole thing. I think in an ideal world you are 100% correct so I whole heartedly agree with your idea. I think in practice it is much more likely that no one would maintain such a system because on site personal tend to be….. errr…. let’s say lax in their development practices. If you are the sole developer on the solution, you definitely have yourself a golden hammer if you commit yourself to maintain a backup process like this.

I really like the idea!

Thanks for the input Bob

By: Bob Stuart

Bob Stuart — Sat, 15 Sep 2007 08:00:18 +0000

It’s probably useful to think of three kinds of situations:

1 In a Separation Model where Minor Upgrades might only involve changes to the Interface file which can be simply swapped out for the new one.

2 Data and Interface Recovery after a severe crash

3 Separation Model or not, Major Upgrades in which aspects of calcs and field definitions have been changed in the new Data file(s). Despite your best intentions, this WILL happen.

In the case of 2 & 3, writing a monster Import script for all your tables may be tedious but it’s also the key to creating a completely automated ‘Update’ routine. This makes it really easy for clients to upgrade to your sparkling new Major Upgrade of your solution, OR recover from a severe crash.

My solution files have an ‘Upgrade/Recover’ button. Eventually, I’ll probably make it inoperative when the file in which it’s used is NOT a Clone. Detecting any data in the tables will ‘grey it out’ because using it when data exists will duplicate some or all records.

Upgrade/Recover runs a script containing the following steps.

Open (hidden) a selected backup file and store it’s filepath in a global
Run a script called ‘Prepare For Export’ IN THAT FILE
‘Prepare For Export’ goes to each layout that represents a TO and performs a Show All Records step

When that subscript finishes, the Upgrade/Recover script in the NEW file performs the individual table data imports and is followed by a step that resets serial numbers for each table using “Max ( foreign_auto_num_field ) + 1″. That’s assuming you DO have auto serial number fields to identify records in each table.

After the last subscript performs its Import, the backup file (it’s filepath is stored in a global, remember) is closed and a “Congratulations” dialog appears if no errors were detected.

Close File [ filepath ]
Go to Layout [ original layout ]
Refresh Window
If [ Get ( LastError ) > 0 ]
Show Custom Dialog [ Title: "Errors Occurred"; Message: "Some errors occurred during the Upgrade process. Please check the
Import log."; Buttons: â€œOKâ€ ]
Else
Show Custom Dialog [ Title: "Success"; Message: "Congratulations! The Upgrade process was completed successfully."; Buttons:
â€œOKâ€ ]
End If

Hope I haven’t forgotten anything. Let me know.

Bob Stuart
Think Data Pty Ltd
Noosa
Queensland
Australia

By: Jesse Antunes

Jesse Antunes — Fri, 14 Sep 2007 15:32:12 +0000

@jules – Thanks for the comment. You might be right. I prefer changing it manually. if you have multiple tables that you need to update serial numbers, or multiple serial numbers within a table it seems just as difficult to write the script. Now if you are planning ahead and want to write the script Before any crashes…. I’m sold. That’s a great way to do it.

By: jules

jules — Fri, 14 Sep 2007 06:15:56 +0000

nice description of an onerous task.

though i don’t like manually changing serial numbers. i think it’d be easier to write a short script using “Set Next Serial Value”