Corruption in imported script?

[tv_kid]

I'm rebuilding a corrupt database. I've checked all the layouts on the corrupted files and they all appear fine, so have copied and pasted into a new file. I've rebuilt the tables from scratch. All was going well until I imported the scripts from the previous file. When working through them to check they were functioning correctly, I came across one that contained a GTRR script step. The layout it points to does not exist in this new file. Bringing up the dialogue box for this step allows me to select the layout I want it to go to, but when I hit ok it appears in the script as this 'phantom' layout.

I'm very concerned that I have brought over corruption into this 'clean' version. Has anyone else experienced this issue? I had assumed scripts would be free of corruption. Is the only answer to print out the scripts and manually recreate them?

---

I've now realised, through further browsing of this forum, that I was experiencing the GTRR bug of showing a layout from an external file. I removed the layout in the external file and the script line reverted to: layout "unknown". This has been well documented on this forum.

Apologies! But I would still be interested to know if scripts can contain corruption, as I'm a bit paranoid about the rebuilding process!

Thanks

Edited March 6, 2006 by Guest

[gdurniak]

see my post here:

http://masdevelopment.com:3455/1/57?view=print

[tv_kid]

Thanks for the link. I've looked at this site before and found it helpful. However, I'm intrigued by:

"Avoid importing scripts, or copying layout objects. They may be corrupt. There is no documentation to say if this will propagate corruption."

Is there any way to check for certain if scripts and layouts are corrupt?

[LaRetta]

Is there any way to check for certain if scripts and layouts are corrupt?

No. Corruption and I have a long history (and close personal relationship). I have copied one graphic from a trashed file and caused a new clean clone to crash (in testing this very issue). I also brought script in once ... again simply to test it. And it crashed my new file. These were controlled tests because I wanted to convice myself to NEVER RISK IT. It worked because I've seen it in action and I satisfied my morbid curiosity. I will NEVER use a file once it has crashed and I will never use ANY PART of a file once it has trashed. When you view the script, it looks normal. When you view the graphic, it looks normal. Corruption doesn't always show and it is never worth the risk!!!

LaRetta

[tv_kid]

Oh *%$@! Do you mean I have to rebuild all the layouts from scratch, and redo all of the scripts too?

I guess I just need to bite the bullet, but that wasn't the answer I was hoping for!

Thanks for the help.

Matt

[LaRetta]

Oh Matt, I've been given the same news. It will never feel good, I know. That's why when a file even burps, I trash it. Because if I don't and I later find out it was corrupted, I've wasted hours and hours worth of work because I'll eventually need to trash it anyway. The GOOD news is that you're trashing it now instead of waiting until you've put in another 20 or more hours ...

Update: And I've become a compulsive back-upper.

L

[gdurniak]

Matt,

please note that under time constraints, I have "cheated", and used "suspect" practices

it's your choice, but at least now an informed choice

greg

[aldipalo]

Can you build a closing script that automatically backs up your files? How would you go about doing that?

You have just made me paranoid as well.

Al

[gdurniak]

a closing script backup is possible, but possibly clumsy

just quit filemaker, and copy your working folder, preferably to another hard drive. The new OS X "Automator" might help here

if you have the luxury of working from FM server, you can setup a timed backup schedule

Also, be sure to move up to FM8v2. There are less bugs. FM7 had definite corruption problems.

[aldipalo]

Thanks. I tried the close script routine. See attached.

However, when I checked the files they were all the same. I have a few external databases connected to my main DB so I need to copy all of them in order to make a complete backup. Can you tell me what's wrong with my script?

I figured I should open each DB, show all records, save the file to my server (FM is on my computer), close the file and on to the next one. I must be missing something because when I looked at the files on my server, they were all correctly named but, they were all the same size as my contacts file and they had the contacts data not the company or jobs or calls data. :)?

I have tried several times to import the external files into my main database, but, have not been able to do it. Can anyone tell me how to accomplish this? I would think it would make everything a lot simpler.

I would also assume that I should only do the backup from the "Admin" account otherwise everytime someone closes their program they'll be backing up the file. Is this a correct assumption?

Thanks for your help.

Al

Close_Script.pdf

[LaRetta]

Check out Wim's website ConnectingData in downloads called "Backups, more backups!!"

It's been a godsend...

[T-Square]

FYI: You are getting the same file saved over and over because your script is operating within the context of the current file. In other words, you open the CompanyDB, but then your script comes back to the script file to continue the script, and then saves the current (script) file as CompanyDB.

To back up multiple files, you need a Backup script in each separate file that issues the Save As command. Then, your core script calls each file-specific Backup routine to make the backup.

You do not need to Show All records if you're using the Save As command, since you're saving the file, not the recordset. If you use the Export command, you do need the Show all; otherwise FM exports the current found set.

Since this started with a question of corruption, I'll note that both saving as and exporting may not remove corruption, and the only way I've heard to eliminate hidden corruption is to export your data as a text file (comma-delimited), and rebuild your data structures and scripts by hand. Maybe that's changed in 8?

It would be great if there were an SQL export option...

David

[aldipalo]

Hi T-Square:

Thanks for the reply. So, if I understand this correctly I set up a "BackUp File" script in each DB? I then call each "BackUP File" script from my "Close" script?

Perform Script [backUp Company]

Perform Script [backUp Contacts]

Perform Script [blah, blah]

And this will back up all my db's individually?

Should the last backUp be from the main DB, in this case "Contacts?"

Al

[T-Square]

That's right. I don't know about whether the order matters.

[aldipalo]

I finally got around to putting all the back up scripts together and the close script. The order is important. The LAST file to be copied should be the current file. Otherwise, the script closes before going to the external databases.

By setting a couple of globals "BackUpDate" and "BackUpTime" I was able to have the script set the date and time of the last backup. Now, whenever the user closes the file it lets them know when the last backup date and time was. If they do not elect to back up and it has been more than 7 days since the last backup it warns the user and gives them a chance to reconsider. This way the user is constantly reminded to back up their files.

Everything is working like a charm. Thanks for all your great suggestions.

Al