Fields can be TEXT, Number, or Date (among others)
If it is a text field, the date could be 5/9/09 or 5/09/09, searching for 5/9/09 would return ONLY that text.
If it is a number field, the same would be true.
If it is a date field, the records with the same date SHOULD be returned in a search.
Are the dates being entered into a field of type date or a field of a different type?
Enter Layout mode (There's a pop-up menu in the lower left corner of the window for this.) and note the name of the date field.
Pull down the file menu and choose Manage | Database and click the fields tab.
Locate your date field and check to see whether it says "Date" in the type column.
If it says "Text" or "number", highlight the field and choose "Date" from the type menu in the lower right corner of the window and click the Change button. Click OK as needed to return to your layout and see if that changes what happens when you search for date.
The file's index could be damaged.
Close the file, but keep the filemaker application open.
Choose File | Recover.
Select the file you just closed to recover.
Click save to save a recovered copy of your file.
Open the recovered copy and test it to see if that has fixed the problem.
Notes on file recover operations:
Not all damaged files can be successfully recovered.
Recovered files should not be used after they are recovered. If possible, open an undamaged back up copy and import any new data into from the damaged copy.
Very large files (more than a gigabyte) can take hours to recover so you may want to start the process at quitting time and check back in the morning.
by all apperances it seems to be a true date field. When i make a new record it automaticaly fills in the date for me. Is there a way to know for sure if that is a date field or just a number or text field that is displaying dates?
See my previous post for how to check the field type. The behaviour you describe is typical of a field of type date. You may need to recover the file.
Ok so i looked at the date field and it's type is indeed listed as "Date" I tried the recovery option but I don't think i can do it because the file is served from a remote location that I do not have enough access to. I don't even see a way to save the file normaly myself.
Yes, you would need to have a non-hosted copy of the file in order to recover it. You may need to get the techs who support your server to do this or for them to send you a copy in order to try this option.
Let's not rule out any other possibilities here. If you're reading this thread and think of another possibility, please chime in.
I'm suggesting recover, because I saw the same behavior a time or two when I attempted to find a specific date, range of dates, or just tried to sort the file on the date field on a file that turned out to have some hidden corruption.
Sorry but I feel like I need to say something here...
I have seen many threads where you have recommended using "Recovery" on the file.
Recovery should NOT be used so lightly as a solution...
The procedure ALWAYS is to try Saving as compact FIRST.
Yes the new recovery options as much better in FM10, however, first how do we know the poster has 10? Second, why should one recover the file on an index issue?
The poster should have tried the following in sequence.
- Reindex the field by turning off indexing, saving the changes, then reindexing it again. If that didnt work then step 2.
- Save a copy as compact. If that didnt work then step 3.
- Export the data to make sure that the data is correct. If data is correct then step 4.
- Try recovery when all else has failed...
Another thing worth checking, esp. if the data was imported, is invalid dates. These can be found by entering a question mark as the search criteria.
"I have seen many threads where you have recommended using "Recovery" on the file.
Recovery should NOT be used so lightly as a solution..."
I agree with your notes of caution whole heartedly. If you read back a few posts in this thread, you'll see a similar list of cautions that I posted when I first suggested recovering the file.
You'll also see that I don't recomend using the file, merely recovering the file and testing it to see if that fixes the problem. I don't ever recommend using a recovered file if there is any alternative.
I recommend the recover process as a test, because this is often an easier and more comprehensive check for trouble with the file--especially for someone who may be fairly new to working with databases.
Believe me, I know what you're saying. If my posts have implied otherwise, here or elsewhere, my apologies.
I've spent way too many hours rebuilding files after clients used recovered files instead of replacing with a back up to ever recommend using a recovered file.
Thankyou mr_vodka step 1 was all it took. Good Job!