I have both a 5.5 FMP database that 'drops' random fields of information when I open the file. It's about 6meg in size and about 1200 records. I've reloaded the data and the same problem occurs the next time I open it . . only to different fields.

I thought perhaps it was a 5,5 problem so I created a 8.5 database that duplicates the first. No help, same problem.

Is it related to my caching size or is there something else I should be checking. My problems are happening in XP.

Do you have an opening script? Has the file crashed recently?

I thought perhaps it was a 5,5 problem so I created a 8.5 database that duplicates the first. No help, same problem.

Since it also happens to a new 8.5 database, your setup might certainly be causing the corruption. How are you serving the file?

Sorry bout the delay in responding. Yes the file has corrupted several times [the 5.5 version]. I always restarted and had the file rebuilt, but with the same results.

My 8.5 solution was created from 'scratch' because of my continuing 5.5 issues. The same problem started almost immediately.

The ONE thing I did do was to import my data from the 5.5 tables . . could I possibly have a corrupt data field that I'm bringing forward?

This issue has been consist whether I've used the database from a local server OR from a local copy on my machine.

It is NOT normal to drop data, no matter the caching size.

This issue has been consist whether I've used the database from a local server OR from a local copy on my machine.

Even if a local copy, file could have corrupted first while shared. And is it a 'local server' or a dedicated FM server box (it should NOT be hosted on a regular server)? Are you up to spec on hardware requirements for that box? Are you using FMS or sharing a file? Do you have file sharing on that folder with possibility of another copy of the file elsewhere on the network where data can unexpectedly write to the wrong file on occasion?

The ONE thing I did do was to import my data from the 5.5 tables . . could I possibly have a corrupt data field that I'm bringing forward?

How did you import it? Did you convert your .fp5 data to .fp7 and then import it? Or did you properly run Recover on the 5.5 data, export that data then import into new .fp7 file? It *is* possible to bring a lower ASCII character back to a new file, even if you have exported first (although fairly rare); configuration issues would be much more likely.

It is also possible that you have a script issue. There is a lot of difference between script firing from vs. 5.5 to vs. 8.5; namely two (1) proper use of Commit Record/Request and 2) script-firing perspective, ie, script fires based upon the underlying table occurrence of the layout it is fired from.

Simply, we have not been given enough information. You might attach the new 8.5 file for us to check (you can attach an empty clone zipped). And provide specific, detailed information about how you are sharing you files as I originally asked. Neither did you answer John's question about whether you had an opening script. Surprisingly, we don't ask questions just to exercise our typing fingers; there are reasons we ask what we do.

LaRetta

Sorry bout the delay . . been outta town for awhile.

In response to your earlier questions

It is resident on a APPLE server

There is only one [1] copy of the document on the server

There initially was an opening script but there has been no startup script used for a while and the problem continues to exist

I converted the 5.5 table to 7.0 prior to importing the information.

File sharing has been turned OFF

I'll play around with it a bit more and check out some script possibilities and if that doesn't solve the problem I'll take you up on your offer to look at my application.

It is resident on a APPLE server

Major problem. This is guaranteed to corrupt a file.

CLARIFICATION: Not that it's an Apple server; just that it is on a server.

Edited March 16, 200916 yr by Guest