There are a few terms that you might

want to remember when coming into the world of

FileMaker. So you understand the correlation between FileMaker and enterprise level databases.

FileMaker = Translation

File = Table

Search = Query

Find = Query

Anyone else want to add to the list?

What's the key field?

Is it like: when you relate two FMP files, you go to the "define relationships" dialogue and choose your related file, then you select the records in each database which should match (eg. Cust_ID and Cust_ID).

Would these be key fields? Is that all there is to key fields, or can they be more complicated? I've heard of superkeys as well -- what would be an analogue in FMP? Or are they just like regular key fields, just a bit more "special"?

Found this in a theory book written for Access:

>it appears that the best procedure for good database design

>is to mix eight parts intuition and experience with two

>parts theory

Perhaps a good byline for this forum?

>>Anyone else want to add to the list? <<

How About...

Portal = Sub-Form

Script = Macro

Script to List View = Report (kind of)

Later :-)

quote:

---

Originally posted by dylan:

What's the key field?

---

A key field is simply and identifying field. A Name could be a key field. Keys are then subdivided into primary, secondary, tertiary which are the keys that are actually used to related records.

quote:

---

Is it like: when you relate two FMP files, you go to the "define relationships" dialogue and choose your related file, then you select the records in each database which should match (eg. Cust_ID and Cust_ID).

---

This is a type of key.

quote:

---

Would these be key fields? Is that all there is to key fields, or can they be more complicated? I've heard of superkeys as well -- what would be an analogue in FMP? Or are they just like regular key fields, just a bit more "special"?

---

You can have compound-keys (i.e. 2 or more keys added together) or multi-keys (i.e. 2 or more keys seperated by return characters).

The one thing that I advise is to use ONLY keys that are NOT based on any user-definable data, because as soon as the user changes the data (and they will) the realtionships break. Random keys are also bad, because they can be duplicated. Simple sequential serial numbers are also a bad idea, as they are not unique enough and are easily replicatable.

I use the following calc to generate my keys: Right( "00000" & Status(CurrentRecordID), 6 ) & "-" & Right( "00000" & Status(CurrentTime), 6 ) & "-" & Right( "00000" & Status(CurrentDate), 6 )

This generates a non-random, unique key, that is almost impossible (say 99.999999999%) to duplicate, except by deliberate effort.

------------------

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=