two keys in one field

From a “Few Good Men”

Rich: You want answers?
Jim: I think I’m entitled to them.
Rich: You want answers?
Jim: I want the truth!
Rich: You can’t handle the truth! Son…

This really is one of my favorites…
Simply brilliant

Must agree with Rich here

We used to use MLK (mulit line keys) in FM due to the limitation of FM versions prior to V7 only allowing 50 files open per client [for ‘file’ read ‘table’ !!] which was a huge restriction when it came to defining database structure.

It was for this reason that there used to be a gazillion ways to fake more normalised structures - which really meant replacing join tables - which would inflate the number of tables that made up a database in OLD FM - which meant problems handling the number of files which a client could have open - …oh, woe !

Since FM7 onwards there is now a whole new paradigm for the way FM operates [hooray !] which includes:
1 file = 1 database = multiple tables

Now that there is no limit on tables within FM there is no real reason to have to use MLK’s anymore !

Although, I will concede that you can use them for portal filtering and other spontaneous or runtime uses and I still use them for these types of purposes !

Cheers
Harry

OK, thanks for sharing Jim. And… I would indeed use a join for that but you already guessed I guess

I would use a join table as well for that, Marcel. If possible/practical, I would use one join record to express the join between the two contact records (in this particular situation), rather than two. Not possible/practical, so I use two records.

This isn’t a big religious or philosophical question to me; sorry if I offended anyone.

Peace,

Jim

Hi Jim, no I don’t think you offended anyone. It is more that I, and I am sure all the others that reacted, wanted to make sure that you would make the best choice.
Since many people are used to working the way you described every once and a while a discussion like this one pops up where somebody asks for a FM way to do something when there is a normalized way to solve the issue. Both for design and future development reasons it is good to have such a discussion I guess. So nothing religious :)

Cheers