bug with relationships?

[imz]

I

[Robert R]

I'm not an expert by any means, but I know that FM ignores certain characters, when doing a comparison, by design.

Putting in an extra space does NOT make an item unique. You need to do your database a little differently... maybe you could either combine fields, or create calculated fields to index on...

[Robert R]

After rereading your message, I am not totally certain I understand what you are trying to do. Are you creating a database that checks for duplicates in other databases which you did not create? Like a utility for FM users? If that is the case, you may have to do a secondary comparison of your own design to search for characters that must not be ignored.

[jwallace]

I think if you modify the indexing of the fields to be ASCII instead of whatever language you are currently using, it should do the trick.

For example, in English, "Roger" and "roger" are not different. In ASCII they ARE different and would result in a non-match.

Hope this helps.

[LiveOak]

The way FM indexes a field (you can view the index to verify this) roger indexes as "roger" and roger harris indexes and "roger" AND "harris". A normal find for "roger" will find both "roger" and "roger harris". This is just the way it works.

You don't mention whether you are doing a find or building an index. If you are building an index, don't use names as a field to relate two files. Use the autoentered record number or some other unique UNCHANGING number. If you use Robert Smith and later change the name to Bob Smith, YOU WILL BREAK ALL THE LINKS TO RELATED RECORDS! First rule, never relate files using a field that the user recognizes (or sees).

-bd

[This message has been edited by LiveOak (edited January 29, 2001).]

[imz]

thanks a lot to the valuable replies - especially to jwallace, who managed to solve the problem!

thanks also to LiveOak for his general advice, although it is not of any use for the problem i had, because it