FM4 Crashing when a field is deletes

[Neville]

We are using FM4 for our real estate office. Vaghan has provided some useful information previously.

Now have another problem.

The DB has been going for about 4 years now and undergone many changes and enhancements (and several crashes and recoveries).

We were having constant crashes associated with large DB with photos.

Following Caughan's advice we are running the DB on a fast machine, using opener files on the other PC's, have the photos in a separate DB (now 800mb) and it works fine and we have had no recent crashes except---

As the db is old it has a lot of unused fields, test fields etc.

I want to clean it up and delete these unused fields but when ever i go to delete a field I dont want it give you "file damaged, continue exit" and then I get a GPF and it crashes. When restarting it is usually able to fix itself, but a couple of times I have had to do a recover form he backup (whish FM does using a script for each day when we close it)

I have tried saving a copy and also a clone, no records and tried deleting the unused field in both of them. Same problem it crashes.

Even though the Db works fine on a day to day basis, I am worried that there is some terminal damage that will eventually cause an unrecoverable error some time in the future.

Any suggestions?

I dont really want to have to export all the data into as tab delimited and import it into a brand new DB as I will then have to rebuild all the layouts (approx 20) and the scripts (pprox 30)

Advice appreciated

[Vaughan]

It sounds like your PC is having problems.

Install FMP on another machine, then try cleaning up a copy of the database on the other machine. If it works without crashing then the original machine is sick. Check the hard disk for errors. Install the latest OS patches. Install the latest FMP patches. Uninstall FMP and re-install it.

[Neville]

Vaughn

Thanks for the tips however no luck!

1 Ran surface scan - no problems.

2 I copied all files to another machine and tried deleting field - Immediately it comes up with the same "this file is damaged - use recover command to recover the file - if you continue I get "program has caused an illegal instruction and will be terminated". Can recover the file and when I try to delete on it I get the same problem on the recovered file.

2 Uninstalled FM4, downoaded Win 98 updates, FM 4.2, FM4.3 updates, reinstalled FM4 plus updates, tried again - same crashes.

The database has had a bit of a rugged history. Started as FM2, then upgraded toFM3, now FM4. With the previous crashes with the imbedded photos which you kindly provided a solution,(by the way the associated photo file is now 1.2gb!!) I have had to do a number of "recover" operations over the last couple of years.

While this has been no great drama it does have some nasty consequences. All fields are recovered but FM looses field definitions for some and names them "Recovered field 1" etc. Also some field formats are lost -ie fields with associated popup lists revert back to standard fields. Mostly the popup lists are still there and it is just a matter of going into layout mode and re assoicating the field format to the popup list. Also in the list of popup lists there is about 8 blank entries (in total about 20 with a gap of ~ 8 in the middle - a bit of a worry!

I think the old girl has had one too many heart attacks and one day it will just throw in the towel all together!!

I have incorporated a scrip in the exit routine that makes a backp for each day of the month (ie 31 backups of the main DB) so I have some security, but not a lot as all the backup files have the same "cancer".

Would making a copy of the file, deleting all records and then import all the records from the original (or a tab delimited copy) be a help?

The DB structure is fairly simple. The main DB with all the property details has abot 1200 records, approx 20 layouts, maybee 150 fields, about 3.5mb and 5 associated lookup files from a few k up to abot 80mb. There is the large photo file (1.2b as above)

Would an upgarade to FM5 be any use? (What is the approx street price for FM5?)

The problem is that because FM4 is so easy to use and versatile we are coming use it more and more from basic listings to running our rental lists on it storing all our digital photos. The reps are lost if it goes down even for a few minutes!. We print window cards with it, produce sales contracts from it, mail out XMAS cards from it, have links from it straight to our net listings - you name it - we use it!!. They use it as a marketing tool talking to clients and giving them details of similar priced properties etc. When the phone rings and someone asks about a property they go straight into FM find mode and bring up all the prioperty details to relay to the client - basically our office can't operate without it.

It has helped us to become the number one office in aour area with over 65% of the sales in our area going throgh our office.

(I must sound like a testimonal for FM! but it is great and we would be lost without it)

Any suggestions still appreciated.

Neville

(Standing by with the defibulator in hand!)

[LiveOak]

The two other things to try are 1) saving a clone and importing records and 2) saving a compressed copy. I'd try the clone first, just because it's faster. Make the clone and try the field edits. You could even try saving a compressed copy of the clone (I'm not sure what clean ups it runs on structure, but it's worth a shot). Working with a clone will eliminate the possibility of the problem being on the data side. In the most extreme cases, you can save a clone, export the data to a text file, and re-import the data. I'm not sure upgrading will fix anything, the best idea it not to upgrade until you have sound file. The other thing to try is all of the about operations on the Mac platform. I would expect it to be too different, but I know you won't get a GPF.

-bd

[DykstrL]

I have seen this happen before with versions 2.1, 3.0 and 4.1.

What we've found is that sometimes a graphic element located on a layout somewhere gets corrupted or an image in a container field has become corrupted.

In the case of a layout element, we have just started deleting parts of the layout one at a time until the crashing quits, then start rebuilding the layout with newly created elements.

The other option is to delete the entire layout and then rebuild it using new elements.

With a corrupted image in a container field, it is a matter of finding the record that has the corrupted image. Export and delete the records one at a time until the offending record is found - not a small task if there are a lot of records.

There will eventually come a time when the Recover command won't be able to recover the file.

I haven't seen this type of corruption happen with FMPRO 5.0v3, but I agree with LiveOak, that until you've found the reason for the crashes, upgrading probably won't fix it - but might prevent it down the road once the offending file is repaired.

[ June 29, 2001: Message edited by: dykstrl ]

[LiveOak]

The few times I've had corrupted layouts or records, the crash depended upon looking at (or sometimes trying to move an object on) a layout or landing on the corrupted record. If the problem seems to occur when you try to delete a field, I'd be hard pressed to tell what the actual corruption is. I'd still go down the list of creating clones and compressed copies and see if anything works. Just as a test, see if you can delete fields in the clone.

This will eliminate data as the possible source (the clone has none!). If you still crash, you can take another fresh copy of the clone and try deleting all the layouts before trying to delete a field. Enough of these experiments should help isolate the problem.

-bd

[Neville]

Thanks Everybody for the tips but none would work. In the end it seemed that the problem was in the popup list definitions (the 8 blank ones in the middle of the list). If I tried to delete ones either side of these I got the smae crash.

As these were corrupt and I knew of no way to save a copy of the file without the corrupt lists I gave up.

I tried everything clones, compressed empty files, deleting graphics, script, layouts - nothing worked.

In the end I created a whole new database from scratch, defined all the fields new, copied all the layouts from the old file, re entered all the scripts from scratch, fixed up all the lost files associations, Created new popup lists etc and got it going. No crashes.

In the end the new DB with the same amount of data has gone from 3.5 mb down to two mb, which to me seems like the old girl had pretty serious cancer!! and some bad problems.

It took me about a day and 1/2 to recreate everything (and I bet I will have missed some popup lists etc but the reps will quickly let me know about them!)I can now delete fields etc with no drama.

An interesting side issue was the opener file which started the old DB on user PC's. The way I had set it up preventing operator intervention, there was no way to get back into the startup file/script and point it at the new DB which meant that I had to go back to Forums and Brain food and re learn startups and create a new startup file and script. (I have now allowd operator intervention so that in the future if it happens again, I don't have to go back to school and re learn opener files!)

Thanks again for the helpful suggestions.

I now hope the "old Girls" cancer is remission and has a few years of life left in her!

(A side side issue, not really associated with the crashing, is the Photos file which as mentioned previously is now 1.2 gb. I backup to CD and previously zipped it up and burnt a CD of it. Now Winzip gets a hernia trying to zip this huge file up so now I have to create two files being the first and second half of the photo file (based on properties under/ over a nominal "for sale" price so they both are about the same size) and then burn separate CD's for the two parts of the file.) A bit kludgy but it works - guess I am in for a dat tape to handle the backups in the near future unless some one has a good suggetion for this!)

Thanks again for the help and suggestions

FM forums is great!!

Neville

[garhop]

Neville,

Re: DAT backup; You might want to take a look at IOMEGA's new "Peerless" External Removable Hard Drive (USB); Comes in 10gb ($360 USD includes 1 disk) or the 20gb ($400 USD with 1 disk). Extra disks are 10gb ($160 USD) and 20gb ($200 USD)

They are advertising transfer rates of up to 15MB/sec (approx 1gb/min). Sounds like a good bet for doing backups. Sounds like an Adv. but I'm not associated with Iomega and don't sell computer equipment.

Gary

[Kurt Knippel]

quote:

---

Originally posted by Neville:

... If I tried to delete ones either side of these I got the smae crash.

As these were corrupt and I knew of no way to save a copy of the file without the corrupt lists I gave up.

I tried everything clones, compressed empty files, deleting graphics, script, layouts - nothing worked.

In the end I created a whole new database from scratch...

---

Ohh, that is too bad!

I had a similiar problem and after I upgraded to FMP 5, I was able to delete without crashing. Although that would not have helped in your situation.

Sometimes an element of a file just gets corrupted and nothing will work. One good reason to have copious amounts of backups.

[LiveOak]

DAT is not bad. Personally I don't like methods with expensive media. It is a good idea to use rolling backups. One media for each day to 2-3 weeks. With $160 media, this is too expensive. The advantage of this many backup copies is that often accidental deletions are not discovered until a week later. If you write over your backup each day, the last "good" copy is long gone by the time the problem is discovered. I would also recommend writing copies to CDR (not CDRW) once a month or so. CDR's are cheap and provide a backup that can't be erased and can be stored in a safe place off site. It is very important not to have your machine and all the backups in the same physical location. If you do, a fire or theft can wipe out all the backups at once, not a good thing. DAT media doesn't last as long as they say. The use of rotating heads wears tape media faster than fixed heads (like DLT). I would replace DAT tapes every 12-18 months.

-bd