EllenG Posted February 5, 2005 Posted February 5, 2005 I sure hope someone will know what's happening here and how to fix it! I have a massive upgrade ready to go out on my runtime application. I have scipts that run to import the data from the prior version into the new version. I have never had a problem in the past. Now, however, on my largest and main database file (Herd.AE1), when the Import script tries to run, I get the following error pop up: Error in file "Herd.AE1" Sorry. Filemaker is unable to read the disk this file is on. Click Continue to try again, or click Exit and copy this file to another disk. Here's the interesting part: The script runs just fine in FM6 (Herd.fp5). It is only in the runtime version that I get this error!!! I'm ready to CRY...
stanley Posted February 5, 2005 Posted February 5, 2005 EllenG: Have you tried moving "Herd.AE1" to another drive? How about exporting the data from "Herd.AE1" and then importing from the exported file? -Stanley
Fenton Posted February 5, 2005 Posted February 5, 2005 This error can be about something fairly minor. It has something to do with File References (which, unfortunately for you, are "behind the scenes" in 6, but are both visible and editable in 7). It would be the file reference in the Import script (these are stored only per script step). But you say this is part of an updtate routine, which makes me suspect there's more going on. It will occur if you try and Save A Copy of file on top of itself. It will occur in 6 if you try to import into a file from itself (a "same-named" file) and both files are open. People sometimes try this when they have a scripted "update" routine. The source (original) file must be closed. This means that no other file with a active reference to that file, like a portal or related field, can be open either; or it will reopen the file in the background. It's good policy to switch to a plain or blank layout when doing these kinds of updates. You don't make it clear exactly what files you're talking about. When you say it works fine in FileMaker, are you opening the "runtime-bound" file with FileMaker (which you can do using the Open command), or are you opening the original FileMaker file, before it was bound.
SteveB Posted February 5, 2005 Posted February 5, 2005 While it certainly doesn't make any sense, and as a last resort try recovering the file. Steve
EllenG Posted February 6, 2005 Author Posted February 6, 2005 Well, although I still don't know what exactly the cause is, I have been able to narrow down the problem, and even found a work around for it. It apparently has something to do with the size of the file (in the new version, not the old.) Herd.AE is 2.5 MB (without any records!) The prior version was 2.1 MB (and that one was allowing the imports with no problem.) What I also discovered was that a small number of records would import fine (about 10), but any more then that and I get the error! BTW, I exported records to excel to see if that would make a differenec and it doesn't! I can still only have about 10 records in the file I am importing from or I get the error message. I think my long term solution will have to be breaking up Herd.AE1 somehow to make it smaller, but that's too much work to do it now, since I have this upgrade promised for March. My work-around is this: I created a new db called "Herd_Import" that has all the same fields as Herd, but without the layouts, value lists and relationships. I re-wrote the script to import all the records into Herd_Import and then Herd_Import runs a script that retrieves each record, one at a time, and calls an import script in Herd to import each record, one at a time. It slows the import down a bit (suprisingly, not as much as I thought it would), but it works!! Thanks for the feedback. If anyone knows why this happens, please let me know. 2 more questions (I know the info is somewhere, but I can't find it)... What is the limit on open files in runtime, and what is the maximum db size or runtime appl size? Thanks.
Newbies drcaggiano Posted February 6, 2005 Newbies Posted February 6, 2005 this is an oblique approach to your problem, but in my experience it's better to wait if you're not sure it's going to work right, even if you promised it for March. SAying, " I don't want to give anyone something questionable" sounds good. Also, you could warn everyone it will be late and work with a few understanding customers to try out the upgrade before you distribute it widely.
EllenG Posted February 6, 2005 Author Posted February 6, 2005 Actually, I have a dozen clients who have volunteered to do user testing for me. If we find other snags, I have no problem delaying the release to fix problems. But the import was a major issue! If I couldn't get their data into the release, then what? This approach seems to work. Haven't tried it on the MAC yet; will do that today. I will have other users test it out next week. Thanks for the assistanc.
Recommended Posts
This topic is 7229 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now