I just tried this on a completely different file with an iMac i7, OS 10.6, FMPA 11, and got the same results: The Preview display screen indicates a previous name for the file and not the current file name!
Why would the programmers want to keep an internal (self-modifying?!) index of a prior name of each file but then use that name incorrectly on the user interface?
Well thank you, Michael!
Let's see, either run my file through a Windows system so that Windows can reset the file's name log, or "Recover" the file. We're a Mac house and have no Windows systems here, and I believe FMI, itself, advises against continuing to use a file after it's been "Recovered", and so both "solutions" appear to be non-starters. Quite strange.
Well, there's another option: learn to live with it. After all it's only a cosmetic bug. At least FMI must think so, since they've been dragging it from version to version for so long.
Yeah, thanks Michael, it very often does boil down to 'live with it', eh? That's fine, I just wanted to be sure it wasn't another sign of a corrupt file -- I had posted another problem a day earlier about corruption in the Script list and portal row deletion which I eventually fixed by manually rebuilding the file.
But when I come across things like this, it's like seeing what looks like a harmless mole on your skin: you'd like to THINK it's merely "cosmetic", but you can't help but wonder if it might actually be an indication of something much nastier going on under the hood.
From a programming perspective, it's disconcerting that there is any record maintained at all about the file's naming history within the file, itself, let alone the fact that the history is used incorrectly as part of the user interface (at least in Macs) with ramifications of it causing a fair share of confusion in the printed archival records, and that it has been "known" for many versions of FMP and remains uncorrected.
Such an error on the printed archives of a programmer's code is really not merely "cosmetic", especially if the error implies misleading information about the code's version.
In any case, thanks so much, folks, for verifying that this is a systemic design flaw and not an isolated instance of file corruption.
Could you please confirm whether this persists in FMP 12?
The knowledge base article (repeated here) gives the strategy:
In FileMaker 10 FileMaker introduced a way to get around this (mentioned briefly and incompletely at the end of that KB article).
Use the File > Recover > Advanced Options, and only select the "Delete cached settings (page setup, sort order, etc.)" check box.
This is not one of those Recover features that you have to be careful of, going forward. It is meant to correct your file so you can use it in production.
Beatrice Beaubien, PhD
i2eye, Toronto, Canada
FileMaker Business Alliance
FileMaker 12 Certified Developer
Knowledge Translation Certified Professional
Well that's pretty amazing, Beatrice. Thank you so much for that!
Of course, it must be said that this appears to be a case of sloppy coding and you'd think that by now FMI would just direct its programmers to stop meddling with that cache list, eh? The problem has persisted through FMP 11; I haven't tried it in 12 yet, but no one has chimed in that it's corrected in that eiher. At least my faith in the integrity of the file's data has been renewed.
Philip A. Femano, Ph.D.
CEO, MIC, Clifton, NJ