I am in need of help! I can't open a file I am working on. I can see that there is approx. 777 kb on the file, so I know that something is there. I spent the last nine hours creating that something, so I would really like to have it open!!!

I tried the "recover" command in FM, but that didn't work. Any suggestions?

(attached is the recovered file that does not open).

Also, I am new to Tiger; I thought it might be an OS glitch, so I transferred the file to another computer with Panther. Still didn't work.

Thanks.

dan

RMacarthurCorp4_Recovered.fp7.zip

Well, my only question is what happened to make it close?

I closed it on my own. My last move was that I copied a layout and pasted it to another layout. I thought I should back up the db before deleting the elements on the new layout.

More info: this is not a data problem, but a design problem. I have the data in other versions of this solution. What I want to recover is 9 hours of work designing the interface (buttons, consistent field height/width between layouts, tab orders, etc.)

Well if you closed it on your own there's not likely going to be anything wrong with it..

Why exactly can't you open it.

PS. Don't use the recover command, its ah... not good.

When I try to open the file I get the following message:

The application FileMaker Pro Advanced quit unexpectedly. Mac OS X and other applications are not affected. Click Reopen to open the application again. Click Report to see more details or send a report to Apple.

There are three buttons in this "Error Message" box: Close, Report, and Reopen.

Attached is the Error Report.

FMErrorReport.txt

... What happens when you try to open filemaker by itself?

FM opens fine by itself. I can also open other dbs. I have tried the recover command several times. A new recovered file is created, but I cannot open that one either.

Hmmm,

Sounds like it's screwed then..

Might wait on a second opinion though.

Edited June 23, 200718 yr by Guest

Thanks GenX. It's a bit frustrating, but not terrible. Just 9 "billable hours" down the drain.

I think I'll call this a "battle-scar!"

Most important thing is backup...

If you've got FM Server, use it purely for backups. I've had enough File crashes to nearly give up on projects sometimes...

So I use FM Server - backup 24 times a day (because sometimes i work through the night lol - and archive 1 copy a day == Pretty well covered if something goes wrong.

... If you don't... join technet for 99 bucks and you get a free developer copy which will run your backups and let you test i think 3 network connections.

... but in either case like i said, it sounds screwed if recover won't work on it (but you might try the save compacted and whatever the other command is to get it open).

Just 9 "billable hours" down the drain

It happens to all of us. Since a crashed file must be tossed (keeping it can introduce corruption no matter HOW fine it may appear) then it is wise to exit the file and zip a backup every 1-2 hours. You can zip (or I use rar) set to store only, which means that archiving even a 1GB file takes only 5 seconds. And, in truth when designing, one should hesitate for 5 seconds every hour anyway (at minimum); a lesson I'm still learning...

I'm sorry for your loss. Losing work always hurts even if it's only 30 minutes. In your case, the decision was made for you but there will be times you'll have the choice ... don't ever bargain with it; ALWAYS trash a crashed file. I could not be more serious in this recommendation.

LaRetta

...(but you might try the save compacted and whatever the other command is to get it open).

... only to save data which it sounds like isn't the issue. This is a design loss. Do not try to save any elements from the file either. I played with the file. It has been toasted. Let it rest in peace.

Edited June 23, 200718 yr by Guest

... only to save data which it sounds like isn't the issue. This is a design loss. In this case, do not try to save any elements from the file either. Let it rest in peace.

I'm 100% with LaRetta on this one -- always trash crashed files... But just because your design is "lost", if you can get the file open doesn't mean you cant use the object tool to get co-ordinates, sizes, colors etc. and rebuild your layout at a much more rapid rate.

...BUT NEVER COPY ANYTHING FROM THE CORRUPT FILE... or you risk corrupting the clean version too.

Data you can risk because it's not likely to infect your clean file's structure even if it is corrupt.

Edited June 23, 200718 yr by Guest

Agreed, Alex, I've forced open trashed files to print scripts (never import scripts) or to help me recover the logic I was working on.

Can you explain what you mean by "Data you can risk because it's not likely to infect your clean file's structure even if it is corrupt." It makes me very nervous and I think it wise if you clarified because, if there is corruption in data and it is imported from one FM file to another, it can be brought over. Corruption in DATA can cause the file to crash which can cause design corruption - a house of cards.

Corruption in DATA can cause the file to crash which can cause design corruption - a house of cards.

Really?

Lol, well then i take that advice back, lucky I am never really in the situation where i'm developing on live files (and that you're here to tell me off ) ... I still think the data corruption would be self contained but that's not based on any fact and is probably a bad assumption to make.

Edited June 23, 200718 yr by Guest

I am never really in the situation where i'm developing on live files

But you said you used server to back up 24 times(?). Corruption can happen whether the files are served at the time or not. I rarely design on served solutions. But a crash while designing stand-alone can damage design or data also. Example: If a script is running through data and a served solution loses power (or otherwise improperly closes) it can damage the record being written in the moment of crash. Then, each time a script hits that record, it'll crash again - even if the design is a prior good clone. That's why data must always be cleaned after a crash.

But you said you used server to back up 24 times(?).

Live on my local server hooked up directly to the pc with a crossover cat 6 cable - as opposed to live on a client's server where the solution is being used and data is constantly being added, deleted and updated. If a file crashes, it is closed and replaced by a backup from the hour before or earlier (no data import because generally there is only sample data in there).

That's why data must always be cleaned after a crash.

How abouts do you "clean" the data? Cycle through it and see if it crashes?.. (I haven't had to do it before, so it would be good to know).

Thanks.

Edited June 23, 200718 yr by Guest

It seemed you were suggesting that you designed on served solution and simply let server backups protect you. Thanks for clarifying for us. I saw your added question about how to clean the data ... I was responding to your statement that "Data you can risk because it's not likely to infect your clean file's structure even if it is corrupt."

Corrupt DATA corrupts structure!

You clean your data by treating a crash like a world plague ... use standard data-retrieval process, ie, recover, export the data, import into clean good clone. But yes, I have replicated crashes caused by data corruption (one record). Corruption doesn't mean the file always improperly closed - damage to data can happen in perfectly good files. If I KNOW FOR SURE that the design is fine; that it hasn't crashed; hasn't produced scanning at startup, and I come across a bad record, I export then import all records in that table.

FM is blowing it - when they don't allow cloning with option to select WHICH TABLES to include data in. I'm hoping future versions address this issue. I don't mean to sound like a fuss-bucket, but this is a very serious subject as you know. I remember thinking (when still new) that Steven Blackwell appeared to be overly fussy about protecting the data - until I went through repeated hell with corruption. Now I'm overly fussy as well. I hope my almost-phobic behaviours on the subject are tolerated - much better to be overly safe than lax on this one. :wink2:

Lol phobias are fun.

But... I personally wish FM would just do a better job at recognizing damned (and that's probably gonna be stared out even though you can say bloody) corruption - so very frustrating

EDIT: Omg where's the filter... *******, Hell.

EDIT EDIT: Okay, lol, it seems to like adjectives.

Edited June 23, 200718 yr by Guest