I agree that this sounds like a damaged record. We had a problem like this a year or two ago. The bad record must be removed before exporting or the problem just moves with the data. Our bad record was in the Names file, with the problem record right in the middle of the file. Fortunately, we had good backups, but even the oldest backups were corrupted. So I could replace the file when it crashed, but couldn't stop the crashing.
The hardest part was identifying the bad record. I finally wrote a little loop script that went through all records (probably about 15,000 at that time). Since it crashed when it came to the record, identification was difficult. So I created a new 2-field file, made a relationship and set my loop script to write every record ID (or maybe it was record number, I can't recall) to the new file. When it crashed, I looked at the newly written list of IDs and knew that the bad record was next after the last ID written. A quick look at that record (and the ensuing crash) confirmed my suspicion. Our file crashed when the bad record was opened on the Home layout. If your situation is more subtle, the looping script may have to run the Replace Current Find Fields script to trigger a crash. You might want to go to lunch while it runs. The next problem was getting rid of the bad record. I couldn't delete it directly because going to it would cause a crash. I have discovered two solutions for this problem. One is to scroll to the previous record, record its data, then recreate it as a new record. Do the same for the trailing record, never stopping on the bad one in the middle. Then omit all earlier and later records, using Omit Multiple, until just the 3 record sandwich remains. Then Delete All. One time this worked for me and another time it didn't. When it didn't work, the solution was to make a found set of all prior records. Export them to a new empty file. Then make a found set of all following records and export them. Set the serial number to 1 more than the final record. Again, you may have to sacrifice the two adjacent records. You'll end with a new file, not containing the bad record. You may also want to delete any payments linked to the bad record. Then the only issue is identifying the person whose record went bad and reconstructing their data. Hope this is useful, Gary > Subject: Re: Help! > From: Dave Shaw <[EMAIL PROTECTED]> > Date: Mon, 8 Apr 2002 17:47:22 -0700 > X-Message-Number: 7 > > >Our database won't stop crashing. I've trouble shooted the problem down > >to the "Replace All Find Fields" Script. Everytime I run this script the > >database crashes soon thereafter. > > Good bit of troubleshooting - small comfort, but it's a good start on > a solution. > > >So essentially I stopped running this > >script, but lately have found that many of our records in the names file > >are not current with the payments file. > > That script updates some fields in the names file with current values > from payments. So, you're right - without running that script, your > names records go out of date. > > >I've been experimenting with > >running the script from a recent start date. I was successful in going > >from the beginning of our fiscal year (10/01/01) without any problems, > but > >when I ran the script from our previous fiscal year (10/01/00) the > >database crashed again. > > Again, that's a good piece of troubleshooting. What it looks like to > me is a damaged record. I suspect that either a payment record from > the previous fiscal year or a names record is damaged, so when > FileMaker attempts to copy the data from payments and write it into > the Fast Find Fields in names, it crashes. The other possibility is > that the update script is damaged, although if you can run some part > of the records without a problem, that's less likely Maybe someone > who knows more about what goes on inside FileMaker can comment. > > Walt's suggestion is basically right - you will need to abandon this > file set, since it has been crashed repeatedly. The problem is that > if a record is damaged, when you migrate the records to a new file > set you'll take the damage with you. > > I'm not entirely sure how to find the damaged record, but I would try > first exporting all the fields in all the records from both the > payments file and the names file. If FileMaker chokes during the > export, you might be able to identify the record it stopped on. If > the export doesn't fail, then move the data to a new file set and try > your update scripts again. > > I'm sure this sounds like a lot of work, but I'm quite sure there is > no shortcut such as replacing only the damaged script, or even the > damaged file. The ebase files are interlinked in a way that makes > that impossible. > -- > -- > Dave Shaw H4 Consulting > tel: 206-954-7526 fax: 206-625-1338 > ------------------ Reminder to each recipient: To change your list account preferences, go to http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address you used to subscribe to the ebase support list:: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------------------------------------------------------------------- ebase - Relationship Management for Nonprofits, http://www.ebase.org ---------------------------------------------------------------------
