corrupted scripts?!?

Mods, Tips, Tricks, and Support for Zulu
Posts: 49
Joined: Fri Feb 27, 2009 2:49 pm
PostPosted: Thu Sep 02, 2010 6:57 am
John,

Ok looks like the scripts I copied in have been corrupted somehow. They are now empty. If I attempt to copy the steps into the empty script from the sample file I get "The script cannot be found or has been deleted." If I attempt to delete the script, I get the same error. All four scripts are like this.

Nothing happened with my filemaker server and the file has not crashed or lost connection during the integration process.

Thing is I can neither delete or fix the scripts. I am betting they can't be renamed.

Darren
Posts: 49
Joined: Fri Feb 27, 2009 2:49 pm
PostPosted: Thu Sep 02, 2010 7:04 am
looks to me like that these scripts are not called by the plugin by hard-coded name. Is this correct? I have re-copied them and fixed the button for the publish script.

darren
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Thu Sep 02, 2010 8:22 am
Glad to hear it Darren. Fixing the publishing button is great. The other scripts are called by name so don't rename them.
John Sindelar
SeedCode
Posts: 49
Joined: Fri Feb 27, 2009 2:49 pm
PostPosted: Thu Sep 02, 2010 9:09 am
so if the scripts are called by name from the zulu, and I can't delete them, or otherwise fix them cuz of the error/corruption issue, how do I fix this?

Sound like I need to revert to a backup? I beginning to thing this was not an issue with zulu, but a random corruption that effected those scripts.

d
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Thu Sep 02, 2010 9:16 am
I'd revert to a backup if your can. I hear about this occasionally when folks import scripts into a hosted file. I think copy and pasting the scripts is safer, FWIW.
John Sindelar
SeedCode
PostPosted: Thu Sep 02, 2010 5:07 pm
I had the same problem today. Going back to a backup would be very very problematic.
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Thu Sep 02, 2010 5:27 pm
I'm very sorry to hear that. We begin our documentation by suggestion you make a backup, but I understand the impulse to skip over that. Believe me.

Developing on live files does have some risks and I think we should have been insistent that folks take the files down from the server before importing scripts.

At this point you can take the file down and save a compacted copy: see if that lets you delete the scripts. If not, recovering the file will let you delete them, but I wouldn't put a recovered file back in production: hence the backup.
John Sindelar
SeedCode
Posts: 13
Joined: Mon Sep 27, 2010 4:29 pm
PostPosted: Mon Sep 27, 2010 5:01 pm
Although I have not been able to duplicate this error intentionally, I've also had this occur on one test db. (In an effort to duplicate, I've trying the import again to-local and to-server with all the primary steps I previously used, without encountering a failure again yet.)

On FM11A, I imported multiple scripts in one step from local file to server hosted file (into a pre-created scripts folder.) I then setup integration and found I needed to adjust due to multiple-machine usage. While in the "Publish Calendar" script I accidentally double-clicked on the comment instead of the setVariable. It immediately wiped the script clean and entered into this state where I couldn't edit, rename, or delete the script.

After this, I could still entere the Zulu_PostEdit and Zulu_PreDelete scripts. I went into Zulu_PostEdit, double clicked a long comment, and the situation repeated, but this time the PostEdit error propagated to the PreDelete without any action on my part.

Although I can just re-do this, since this was testing, it was a pretty notable failure. If I had to guess, the issue may lie within the importing in some way. I have not yet dissected the damaged file to determine if there's a recovery method, I will do so later.
Stephen Hill
zo.com
IEC, inc.
Posts: 13
Joined: Mon Sep 27, 2010 4:29 pm
PostPosted: Tue Sep 28, 2010 2:59 pm
Recovery attempts:
  • They could be moved into a scripts folder, but still not removed. (I neglected to test removing the *folder* after migrating the scripts however.)
  • Save a copy / compressed copy / clone produced no change, the scripts were still listed but 'missing' with all of the inability to remove or edit them.
  • Consistency check reported no issues.
  • Recovery with just the structure selected reported no errors, no changes, but resulted in a file without the damaged scripts. (the log listing just plain did not show the scripts.) Running recovery with more options had the same results.


I'm using FMPA 11.0v2
It still seems as though the filemaker import of the scripts themselves somehow did not finish 'settling' the new script entries somehow. My presumption is that my attempts to open large comments may not even be the related issue, but regardless of what script item I opened it may have 'lost' the scripts.

I don't put this here for seedcode to respond to, but if anyone else looks to this forum, stay aware of possible script importing issues on the filemaker side.
Stephen Hill
zo.com
IEC, inc.
Posts: 13
Joined: Mon Sep 27, 2010 4:29 pm
PostPosted: Wed Sep 29, 2010 10:45 pm
Followup --
I did another test with a test solution with copy/pasted scripts
* Copied the publish script (local file), pasted it into the solution (remote file), one script only
* Copied all three of the other scripts (local file), pasted them into the solution (remote file), three scripts simultaneously

I did script edit tests, they were fine, viewable, editable.
I proceeded to setup a calendar layout, published, tested ical access with success, created a new record from the client (iPad calendar.)
Went back in to experiment with the validate, postedit, predelete scripts -- they were corrupted. The Publish calendar script, however, was fine (in my previous import-all, the publish calendar script went bad as well.)

I have not run through this with enough specific testing to determine the exact sequence that results in failure, but I winder if the act of corruption is somehow tied into the actually calling of the scripts (although still likely related to the creation of the scripts.) Under my first result-in-corruption test, I was simultaneously looking at the scripts and having a client attempt to access the calendar.

I'm sorry I don't have anything more definitive yet, I haven't really put the time in to try a series of reproduction attempts, been working more to try to get a working example to market to clients, rather than a corrupted example, hehe. This failure was reproduced with a continuous check on the state of the scripts every minute or two during testing. It did not occur while setting up or before publishing, and did not appear to occur until actually prompting zulu to access files. The access & create occurred between two script checks, one a-ok, the second with the corruptions.
Stephen Hill
zo.com
IEC, inc.
Posts: 42
Joined: Wed Jul 08, 2009 2:18 am
PostPosted: Tue Oct 26, 2010 7:23 am
We've had the same thing happen. I cut and paste the 4 Zulu scripts into our DB and they came across blank. I Imported them and although the scripts weren't blank, they emptied themselves within 24 hrs and couldn't be deleted. Even after a rebuild of the DB, signs of corruption were evident.

I spent a day recreating the database from scratch : (

Since other people have had the same experience, fingers could be pointed at Zulu. Any thoughts?
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Tue Oct 26, 2010 9:58 am
I'd like to get to the bottom of this as well. So far we're recommending that people add the scripts when the file is not being served, but that is a big inconvenience, I know.

The trouble is, this doesn't happen every time-- many files are just fine-- so originally I was "pointing the finger" at some initial condition in the target file.

Trouble is, I don't know what that would be. And I don't know why doing this with a served file is different than doing it locally. The problem, of course, is that once it happens you need to revert to a backup.

One thing that could help is for folks who've seen this to send me backups of their files from before Zulu was added: so that I can play with importing the scripts here to see if I can reproduce this / find something in the scripts or the target file to eliminate.

If you'd be willing to email me such a file, send it to john at seedcode.com
John Sindelar
SeedCode
Posts: 42
Joined: Wed Jul 08, 2009 2:18 am
PostPosted: Tue Oct 26, 2010 10:26 am
Hi John, I'll speak with the head honcho and get back to you asap (I don't see a problem though).
Posts: 13
Joined: Mon Sep 27, 2010 4:29 pm
PostPosted: Tue Nov 09, 2010 3:13 pm
John Sindelar wrote:One thing that could help is for folks who've seen this to send me backups of their files from before Zulu was added: so that I can play with importing the scripts here to see if I can reproduce this / find something in the scripts or the target file to eliminate.

If you'd be willing to email me such a file, send it to john at seedcode.com


Sorry I'm a bit late, I'll send you what I've got, although I didn't retain all of my different test revisions. Information and file incoming.
Stephen Hill
zo.com
IEC, inc.

Return to Zulu: iCal Server for FileMaker

Who is online

Users browsing this forum: No registered users and 2 guests

(855) SEEDCODE
[email protected]
Follow us: