File corruption can be so many things. One of the basics is corruption of the index. But rebuilding the file rebuilds the indexes and fixes that problem. Sometimes the layout can have a corruption in it. Can you make a new layout using the same table occurrence and fields and do they records all show up there? If so, then you have a corrupt layout that you need to delete and recreate.
Another situation that happens with the question marks is if you are making an ESS connection to a SQL database and not everything is being returned to FileMaker to display. Is there any chance this is the case?
The records with the question marks show up as question marks on different layouts, and the other records not, so I guess it has something to do
with the records, or index. Since I already imported in a clone should resolve the index issue, shouldn't it?
Ruben van den Boogaard
Converting to 12 completely rebuilds the file, so it would make sense that running a recover on that would pass muster.
When you import into the clone, are you importing FileMaker file to FileMaker file?
I would suggest trying to export to .mer file and then importing that into the clone. Any corrupted records will either be scrubbed or (my experience) not included in the exported merge file.
I would also take a closer look at the Recover.log and review it for keywords "modified" or "changed", and also any substantial differences in index counts for clues.
True.... and as ckeefe says, upgrading to 12 competely rebuilds everything. Is there any reason to not start working in the 12 conversion file? That is what I would do. But if not, you are correct, the data is corrupt and exporting and reimporting as some type of text export would be a good idea.
we had so hoped converting to v12 would fix the ? mark problem we have been experiencing in some files with increased frequency. however, it did not fix the problem, the ? marks persisted into v12. we are now reconsidering the best method and will most likely clone the file, export all data, convert to v12, import the data in v12 into all tables within the file. if others have other suggestions please post.
I just tried if a conversion to FM 12 would clean up the question marks (it did not). My client has no FM 12 licences so that is not an option
When I export the records to a merge file, the records with the ?? end up empty.
I guess I have to collect all the records again and export them to a merge file and import them again in a clone and see if that would solve
Thank you for your thoughts.
Ruben van den Boogaard
Unfortunately, recurring question marks is an all too comon problem. see here:
Export / Import as text is best, and yes, you may lose some data, since the internal record ID's got scrambled
if you lose a lot of data, try exporting from a Recovered file instead, and check the Recover Log
> When I export the records to a merge file, the records with the ?? end up empty.
This type of corruption happens a lot more on client peer-to-peer solutions. All kinds of problem creep in when say the computer crashes, or an app crashes, or loss of power because if FileMaker client has a file open when it crashes, corruption easily happens. And not all corruption is apparent at first. While FileMaker's Recovery has improved over the versions, it does not fix everything. Files that are put on an FMS server operating as a service tend to have much fewer corruption issues because a service is a lot less likely to crash than an application. For this reason, even on my development machine where I am the only user, I still host the files on an FMS service instead of opening locally. If you pay the $99 Technet fee, you can get a developer's version of FMSA which is a great deal and lets you test things out as they are hosted on a server. Basically you get a $3000 FM Advanced Server for $99. Granted it only has a limited number of users, but the $2900 savings is sweet deal for a developer.
thanks for the reminder about the server version being available to
btw, the file system my client has had trouble with has been around
since .fp5 days and has always been on a server.
the corruption was primarily in one table in a main file, but we have
now seen ?s in a few records in another table/file.
as you say, the corruption was probably not apparent at first.
Not true. All of my solutions are on server, and I still see question marks periodically
This has been discussed for years now. I am convinced there is something screwy in the engine.
> This type of corruption happens a lot more on client peer-to-peer solutions
I deal with a lot of FileMaker files and the only time I have run into the question marks have been on locally opened and corrupted files and ODBC connections where the communication fails. I have never run into this on a Server only hosted file. Another reason why I don't think this happens on my servers is I always host my data externally on a RAID drive with RAID 10 (preferable for databases) or RAID 5 (more usable space, slower performance on writes). FileMaker can't do much about hardware loosing data and all hard drives eventually fail. Basically these and other best practices for servers pretty much eliminates corruption problems.
The difference between an intermediate FileMaker developer and an advanced one is knowing how to deploy FileMaker using appropriate server hardware and server best practices. You can be FileMaker certified and all, but if you really want to be able to offer clients a full deployment, you need to know and understand the hardware, the networking, and how other services and programs work with FileMaker (e.g., Directory Services, PHP, SQL/ODBC/JDBC, Apache/IIS, etc.). Granted the local IT manager should be able to arrange for these other things, but many clients hire a FileMaker developer expecting us to know more than just FileMaker.
I've seen this type of corruption in 2 specific cases:
- Time Machine, or another backup software, running on the host machine.
- Users navigating to the network folder and opening the file by double-clicking it. Instead of Open Remote.
Good points Josh. Backsup performed on live FileMaker databases are no bueno. And letting a user have access to directly open an already open server file is not an appropriate security control.
I also have run into Windows Servers with an Antivirus program scanning a live FileMaker database and completely corrupting it. It didn't just corrupt some records and leave question marks, the whole thing was unrecoverable. But those are server best management practices.
In conclusion, implementing appropriate server best management practices pretty much solves these types of problems. FileMaker may not be a reliable tool without an appropriately designed and implemented server.
Looking at the Recover Log ( back channel ) it appears that many of your field indexes were off
and the only real "error" were two grouped objects on your layouts, which is harmless. The upgrade apparently fixed these
do you get the question marks when you do a Find ( an index problem ), or when you Show All Records ( a Record ID problem ) ?
see here for more info:
> When I run the file through FM 11 recovery I get the message that the file should not be used.
When I upgrade the file to FM 12 and run the recovery I get the message that the file is OK?