genevieve charbon Posted January 16, 2008 Share Posted January 16, 2008 (edited) Hi, I've an annoying problem. I have a ghost record in a table (see attachement). I can't delete it (in fact I can delete it, but the total record count doesn't decrease and then it's back on reopening the database). I can't search it either. See attachment. I god rid of it once by cloning, but since it's in a file that has many table, it's very cumbersome to clone it and restore it. This table is emptied every day (delette all) and filled up with an import. Did someone noticed that kind of Ghost records ? How to avoid its creation ? Thanks P.S : also occured with server 8 and 8.5 client Edited January 16, 2008 by Guest Link to comment Share on other sites More sharing options...
Genx Posted January 16, 2008 Share Posted January 16, 2008 Looks like corruption. Link to comment Share on other sites More sharing options...
genevieve charbon Posted January 16, 2008 Author Share Posted January 16, 2008 certainly, But why does it keep comming (even after cloning, its ok for some time and then gets back). Did someone else get recurring corruptionlike this ? Link to comment Share on other sites More sharing options...
Lee Smith Posted January 16, 2008 Share Posted January 16, 2008 certainly, But why does it keep comming (even after cloning, ... Because the file is corrupt. You do not prevent corruption by cloning a corrupted file, and reusing it. You either recreate the file, or revert back to a pristine backup copy, and then importing your data into it. Lee Link to comment Share on other sites More sharing options...
AudioFreak Posted January 16, 2008 Share Posted January 16, 2008 I had a file that was doing basically the same thing. It turned out that the ghost record would only show if finds were performed on specific fields. It turned out to be indexing. Turning the indexing off then back on solved it, but I am rewriting the file anyways because it was one of my first hack jobs. Link to comment Share on other sites More sharing options...
genevieve charbon Posted January 16, 2008 Author Share Posted January 16, 2008 > Audiofreak Thanks, you're awesome. It was excatly that, I reindexed and everythng is ok now. Many thanks >Lee Smith You do not prevent corruption by cloning a corrupted file Are you sure, I always thought that the save as clone command would recreate the file structure in a new file. Link to comment Share on other sites More sharing options...
AudioFreak Posted January 16, 2008 Share Posted January 16, 2008 (edited) > Audiofreak Thanks, you're awesome. It was excatly that, I reindexed and everythng is ok now. Many thanks >Lee Smith Are you sure, I always thought that the save as clone command would recreate the file structure in a new file. Cloning can help at times but is not considered the fix. An old copy or rewrite is the real fix to corruption. P.S. Glad that helped for now, but most likely it will come back and you will have to do it again. The corruption is most likely still there. Michael Edited January 16, 2008 by Guest Link to comment Share on other sites More sharing options...
Lee Smith Posted January 16, 2008 Share Posted January 16, 2008 Are you sure, I always thought that the save as clone command would recreate the file structure in a new file. Of course I'm sure. : Do a do for search for Corruption on the Forum, and you will find tons on the subject. You might find this Link of interest. Lee Link to comment Share on other sites More sharing options...
Genx Posted January 16, 2008 Share Posted January 16, 2008 (edited) You know, this is THE question, and the thing that most annoy's me: I understand that files can be corrupted by power surges, and by bad hard drives, and can NOT be prevented. What I don't understand is why FileMaker can not detect it. There is no validation utility. When damaged files run, backups and "master" clones are useless. It is difficult to develop an effective backup strategy, when there is no way to be sure that the files you are backing up are OK. [color:yellow] Edited January 16, 2008 by Guest Link to comment Share on other sites More sharing options...
AudioFreak Posted January 16, 2008 Share Posted January 16, 2008 This just dawned on me with all the problems people had with files quitting when printing specified page numbers, how many corrupted files are out there being used today? I'm sure the number is quite high. Michael Link to comment Share on other sites More sharing options...
aholtzapfel Posted January 23, 2008 Share Posted January 23, 2008 yes, and the more users you have, the greater chance of having some corruption. (I would argue that any file that has been used for any length of time is likly to have some corruption in it.) My experiance says that almost all corruption can be fixed, "saving a copy as..." will eliminate most corruption with the exception of indexing problems (the most common form of corruption I have come across). Of course a corrupt index can be fixed by turning indexing of a field off then back on. (or using the recover command on the file after which the file should not be used except for data recovery). The biggest problem with corruption is not how to fix it (there are ways to fix it) but how to identify it. (you can't fix corruption unless you know where it is and you often will not know until a user says somthing like "I did a find for last name 'smith' and could not find the record but I found it by looking for the 'Job #'".) Additionally, with no way to identify corruption you can never be certain that any filemaker file that has been used for any length of time is free of it. Just my 2 cents worth, Allen Link to comment Share on other sites More sharing options...
LaRetta Posted January 23, 2008 Share Posted January 23, 2008 My experiance says that almost all corruption can be fixed, "saving a copy as..." will eliminate most corruption... I do not believe that corruption can be safely repaired. It may fix the most obvious problems but FM has yet to provide a method for repairing it properly. Anyone reading this thread should be aware that, by reusing a file which has crashed or shows obvious signs of corruption, they are playing Russian Roulette with their data. 'Close' doesn't count in file repair. 'Close' is as bad as 'missed by a mile.' There is a webinar FileMaker is presenting Feb 12th called File Maintenance and Recovery Best Practices. If it were as simple as Save A Copy As then I doubt webinars (and DevCon sessions) about it would be necessary. Never trust a file which has crashed. Several have said it here and I want to strongly add my voice as well. I've had the 'privilege' of playing with several 'fixed' files which seemed fine and they are NOT fine in most cases (I've found problems hidden in them - major problems). Do not trust a corrupted file just because you don't SEE the problem. Neither does number of Users indicate instability (in my opinion). Rather, improper network setup or inferior hardware are the main causes of file crash. FileMaker can handle large numbers of concurrent Users quite well if properly administered. ..you can't fix corruption unless you know where it is... Corruption does NOT always show itself. Even if it does, how would you fix it? What are your repair methods? And how do you know you're repaired it all? Sorry, but it'll take a lot more than a statement from ANYONE before I buy into this statement at all and trust a file which has crashed. Link to comment Share on other sites More sharing options...
aholtzapfel Posted January 24, 2008 Share Posted January 24, 2008 Corruption does NOT always show itself. Even if it does, how would you fix it? What are your repair methods? And how do you know you're repaired it all? Here lies the problem, Corruption does NOT always show itself, there is not any good way to check a file for it, and there is NOT any why to be sure you have repaired it all. Link to comment Share on other sites More sharing options...
David Jondreau Posted January 24, 2008 Share Posted January 24, 2008 I suppose one thing the webinar will address is a definition of 'corruption'. I've seen the term 'corruption' apply to a file with a lost/bad index, to a file with scripts or custom functions that cannot be easily deleted and to files whose entire relationship graph has disappeared. In my experience, a corrupt index can be repaired using Save As Compacted, undeleteable functions or scripts can sometimes be deleted with a the right combo of Save As Compacted and deleting, and a missing relationship graph means you're hosed. In the second example, a bum script that won't go away with a simple delete, I've seen a Save As Compacted, then immediate delete work. But not always. I'd say if it worked, the file is longer corrupted (though I'd switch to backup if I had one or I'd keep an eye on it) and if it didn't the, I'd trash the file. An FM koan: If corruption can't be detected, is it really there? Link to comment Share on other sites More sharing options...
aholtzapfel Posted January 24, 2008 Share Posted January 24, 2008 In my experience, a corrupt index can be repaired using Save As Compacted,... No, any sort of save as does NOT rebuild indexes (only field and file structure). They can be rebuilt manually (turning indexing off then back on) and "Recovering" a file will also rebuild the all the indexes but a recovered file should not be used. Again the problem isn't in fixing the corruption (as I said before most corruption can be fixed) but identifing it. I long for a tool that can "look" at a filemaker file, and report on any corruption there. In the real world, clients crash and networks will become instable (hopefully this is a rarity). Unless you are running filemaker in a vaccum of a network (no internet, no other apps, running bug free OS's, no viruses, no need for virus protection) I say there is going to be some corruption in any filemaker file running. That Corruption may not cause any problems, but then again it could take the entire thing down and could take weeks/months/years to do it. Link to comment Share on other sites More sharing options...
David Jondreau Posted January 24, 2008 Share Posted January 24, 2008 (edited) Right about the indexing, that's the point of the thread, fingers faster than brain there. I just jumped onto this thread and should have made it clear I'm agreeing with you. I've had files that show evidence of corruption that have never crashed, that have never left my personal hard dive. We toss around the word "corruption" like it means something. Technically I suppose it does, but I don't know enough to come up with a working definition. But practically? Practically it sounds like every file has some corruption but it may or may not show itself. So what use is the term if not to mean something that is affecting the file? Edited January 24, 2008 by Guest Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 5961 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