What you describe should work. You'll need to dig deeper. Feel free to supply a more detailed description of how you have designed your layout.
Thanks for responding.
It does in fact work as expected but only for newly added records.
The question is why is the condition not applied to the expiry date for the existing record "existing entry"?
here is the screenshot showing the condition set on the field.
If you open Manage | Database | Fields, can you confirm that Expiry Date is a field of type Date?
yes field Expiry Date is of type Date.
I created a small test file but am unable to reproduce this using FileMaker 11 on my windows XP system:
Just my luck that it had to be something weird. I guess it means that on my system a pre-existing value is not recognised as a correct date, eventhough it really is correct.
Thanks for taking the time.
I suppose I will need to create a function that can iterate over all my date fields, take the existing value, reformat it as required and replace the old value with the new one (in theory).
Try testing this on a small new file. Perhaps the issue lies with a problem in your file or this specific layout.
If the test file correctly applies the conditional format, perhaps your current file is damaged. you can run a recover on the file and check to see if the recovered file works.
Another possible difference is that my machine's locality settings are for the United States with the default MM/DD/YYYY format instead of DD/MM/YYYY format of european locations. I used a custom date format to match the format shown in your example. The date format should not change the behavior of the conditional format, but stranger bugs have surfaced in FileMaker systems and that's not one that I checked for.
You might also try using a formula instead of the value setting:
YourTable::ExpiryDate < Get ( CurrentDate )
should produce the same results.
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).
I fixed my problem by re-importing my data which is an csv file into the related table.
FPM did not recognize the value of my date field correctly (for the purpose of conditional formatting) if I adjusted the field type after data import/table creation.