Thank you for posting.
I use this feature every day without problem. Are you sure you don't make confusion betweenLayout Name by calculation...AndLayout Number by calculation...
Please let us know...
Yes I am sure of that. I also checked and doublechecked if my layout names had any extraneous spaces. The script works fine if the layout name is not the same as the table name.
But I created a test file and lo and behold, the script works fine. So I guess the issue is related to the file. A consistency check gave no problems.
I remember i had some problems with this feature when i used special chars in Layout's name like "^" (in french we have a lot of accents).
If a recover doesn't solve, i think you should verify if is it table's name depending...
The layout names are all straightforward A-Z characters as you can see in the screenshot. The test script grabs the layout name, goes to that layout and says sorry, 105.
Recovery seems to have resolved the problem, even though it did not report anything out of order. Thanks for your assistance.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Thanks, I know the drill. I have just started building this solution. It has a limited number of tables and TO's, and only a dozen or so scripts and I suspect this problem has been present from the get go. So I guess to be better safe than sorry, I will take a couple of hours to rebuild it from scratch. I really hate when this happens. Especially since nothing seems wrong and the issue has been resolved. It feels like throwing away food before the sell-by date.
For what it's worth, this is what the console log says:
Herstellen heeft een nieuwe database gebouwd zonder problemen vast te stellen. U kunt de nieuwe database veilig gebruiken. Controleer de resultaten echter zorgvuldig en maak up-to-date back-ups van uw databases.
2013-07-16 16:45:31.853 +0200 testreco.fmp12 0 Opmerking: Herstellen controleert alleen de gegevensblokken van het bestand en genereert een nieuw bestand van die gegevens. De consistentiecontrole controleert alle blokken van het bestand en vindt mogelijk meer problemen in het originele bestand dan Herstellen.
In dutch, this says that I can safely use the recovered (new) database. It further suggests that a consistency check may find other problems, which I ran, and it found no problems.
So... Does a consistency check plus a succesfull recovery with no problems found (which did however resolve my issue) cover all possible problems?
As stated in my previous post, your best practice is not to use a file that has been recovered if you have an alternative to doing so.
I know of the best practices, but the dialogs Filemaker returns after a recovery that returned no problems say it's safe to use the file.
This is what keeps nagging me because it is either safe, in which case what common best practice says is wrong, or it is not safe, in which case common best practice is right and the dialog and console log text are wrong.
Ah well, time to put this to rest. Thanks for your input.
It is "best practice" because once you recover a file, you have no 100% gaurantee that recover fully and correctly fixed the problem and you have no gaurantee that recover found all the issues that were present and needed fixing. Plese refer to items 2 and 3 in my original post.
Thank you for your posts.
I am unable to replicate the issue. As an extreme case, I created a file "Layout.fmp12", that contains the table "Layout" with one text field named "Layout" with one record with the contents "Layout". I also created a second table "Table" with one text field named "Table" with one record with the contents "Table".
I set up a couple of scripts to Go to Layout by Name and by Calculation, and the scripts work correctly whether I'm using "Layout" or "Table".
Create a new table, add some fields, and the new layout will have the same name as the table. Create another script with Go to Layout by Calculation and see if this fails.