One more oddity. When we use the period with FM14 some records auto populate with data from a previous season. When we switch to the hyphen this behavior goes away.
Something truly strange going on with periods in FM 14
The searching behavior is completely normal. FileMaker treats a period as a word delimiter (i.e., a break between words). So if you search for a string, FileMaker will do a partial match and return those results, even if you use the "=" qualifier to match whole words only.
You can solve the problem by typing "==" and enclosing the search string in quotes, like this:
To the second, it sounds like you have a relational join that's performing a lookup or other auto-enter. Again, since a period is treated as a word break, FileMaker will match anything that has "12" OR "LL" OR "01" on the child side of the relationship. If that is the case, you need to create a second field that removes the period characters and match on that.
Mike is correct, the period is assumed to be a delimiter and is ignored.
In all our solutions we give the user the ability to search phone numbers for a particular record. We use a custom function to auto-format a phone number after it is entered into a field, ie 2153642676 -> (215) 364-2676. Before the calculation occurs, all other characters and spaces are removed with another custom function, so that 215-+364-*2676 -> 2153642676.
The same scenario is used for all phone number on a particular record. The Home, Work and Cell phones are put into a calculated field that scrubs for extra characters and spaces and creates a multi-key lookup field with a <cr> between records. When a user searches using a pop-over. the phone to search for is entered into a global and when the find is initiated this field is also scrubbed and then the search uses the combined numbers field.
I understand these responses. I suppose my question is why did our searches work before the FMS 14 upgrade and not after? Why do all of our lot numbers, locus numbers, etc. created before FM 14 work perfectly and all created after the upgrade have issues?
Did FileMaker change the way periods were handled in FileMaker 14?
This issue can't be limited to the sciences of anthropology and archaeology. In graphic design many files names end in .tif, .psd, etc. Why would FileMaker default to using the period as a delimiter in the case of storing a string of numbers or a name?
Uh ... because a period ends a sentence?
A text field in FileMaker is always a text field. The parser has no idea what the meaning of the text is; it just knows there's a string of characters. There are no special fields for scientific identifiers.
I do not believe there was any change to word delimiter behavior from 13 to 14. A period has been a word delimiter for a long time. What version did you upgrade from?
Our university upgraded from 12 to 14. The solution was built on 12. I'm just a tech "grunt" in the field working with the scientist keeping everything working. The database was designed by 2 PHD's with much more DB experience than me, I helped build and implement it based on their wishes. I know the issues of using periods was discussed at the time and determined to be the correct thing to do scientifically and for the database by them. Up until the FMS 14 upgrade it all worked 100% of the time without fail. Now we are experiencing multiple failures across several forms used by the team.
Were we wrong to use periods in our lot numbers and location identifiers? If so why did it work until now? Any suggestions moving forward? We have 4 seasons worth of data already and are 3 weeks in to a short 5th season. We can't have the scientific findings corrupted or become questioned in any way.
Were we wrong to use periods in our lot numbers and location identifiers?
We have 4 seasons worth of data already and are 3 weeks in to a short 5th season. We can't have the scientific findings corrupted or become questioned in any way.
Up until the FMS 14 upgrade it all worked 100% of the time without fail. Now we are experiencing multiple failures across several forms used by the team.
That indicates, as we've discussed, the problem is at the schema level. (Unless you have the same Script Triggers on all the malfunctioning layouts.) I suggest you do this:
1) Check your auto-enter calculations. Data are being copied incorrectly, which means something in the auto-enter is resolving wrong. (Whether it was working before is largely irrelevant; it's not working now, so it has to be dealt with.)
2) Create a blank layout for the table where the problem is occurring. Display the related data via a portal. See what happens. (This eliminates the possibility of a Script Trigger being the problem.)
3) You can change your existing data using the Replace Field Contents command to adopt a new convention if you wish. (Do this on a copy of the database first.) See if using hyphens or underscores helps.
This related thread may also be of some use:
I'm not seeing the issue though. I've added a table to one of my test files hosted on FMS14. Using FMPA14.
Added some dummy data:
When I do a search for "AB15B.0024" (so no "==" in front of that), I properly find that record.
So I think something else is going on. My recommendation:
- do a test recovery on a *backup* of the file to see if the recovery log reports anything
- again on a backup, use the recovery options to only remove the indexes, see if that fixes the issue.
Thanks for the good replies. Looks like I have some more testing and trouble shooting to do. Will report back with good or bad results.
A quick test for damaged indexes would be just to turn them off (under Storage in the Manage Database dialog) and let FileMaker rebuild them.
In view of Wim's test and your reporting that: "Now we are experiencing multiple failures", I suggest you closely examine the data that is failing to check specifically for spaces after periods—i.e. could you perhaps have "LL. 12" where "LL.12" is intended? I suggest this because (a) this would cause the behaviour change you are experiencing, and (b) it is increasingly common default behaviour when typing text in various Apps for a space to be added after punctuation.
building on keywords: pay special attention to scenarios where people may be copying from some application and pasting into FM. Sometimes that may bring across invisible characters that can produce weird results in indexing and the resulting searches,
And Wim's and keyword's observations are yet another reason not to allow end users to edit key fields ...