And what is the error text?
What OS are you using?
Have you tried running a recover on the file?
Force quitting FileMaker (or a crash) can damage a FileMaker file and a damaged file might bring about such a crash. So for both reasons, I'd recover the file to check it for possible damage.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Process: FileMaker Pro 
Path: /Applications/FileMaker Pro 13/FileMaker Pro.app/Contents/MacOS/FileMaker Pro
Version: 13.0.4 (13.0.4)
Code Type: X86 (Native)
Parent Process: ??? 
Responsible: FileMaker Pro 
User ID: 502
It does appear the file is damaged after running a recovery.
I will have to go through my back ups and recover them to see if i even have an undamaged version. There has been some significant development recently. If i do not have an undamaged copy, i might be forced to work off the recovered file :( thank you
It's almost always OK to use a recovered file that Recovers with the "OK to use" message. It's just that there is a small chance that the recovered file may still be damaged or may have been "repaired" in a way that changes your intended design of the file. This chance is generally quite small, but reverting to an undamaged back up would normally have a 0 chance of that so selecting a back up copy is a little bit better option.
My recovered file is not "OK to use"
I have a copy from before a major upgrade that would take a very long time to bring up to the current file but it is an option.
If i clone the current file, the empty clone returns OK to use. I am testing the best way to perform the export/import process. I will not be able to transfer my containers contents. I could transfer those manually if I had to.
From your experience, What is the best/simplest way to export/import to a clone?
What would you say is the best
Are you cloning the recovered copy or a copy that was not recovered?
If you are cloning the recovered copy, I would not consider it OK to use. The reason that you go this message is that a significant part of your file is no longer present, or no longer functional. A follow on recover may not detect that issue.
But if a clone of the unrecovered file comes up "Ok to Use", Then it might be worth importing all data from the recovered copy into the recovered clone and testing it--both with a recover and by using the file, to see if it will work for you.
In the past, I've been able to review the recover log looking for error codes and entries that say "changed" to determine what part of the file was identified as "damaged" during the recover. I've then been able to take an unrecovered copy, delete that part of the database (a table, layout, script...) and then test the file by seeing if it recovered "ok to use". If it did, I could then take this recovered copy and rebuild just the portion that I removed. This sometimes involves some trial and error to delete the smallest possible portion of your database and still get an "Ok" recover before then manually recreating the damaged portion of the file.