Data Structures

[kc0hwa]

how do you make Data Structures in filemaker!!

I did this in FM 1 and 2! I forgot what I did!!

thank for you all of your's time

[LaRetta]

Do you mean how do you create relationships? I think we need a bit more information... :wink2:

[kc0hwa]

IS THERE MORE THEN LOOK UP FOR relationships!

[LaRetta]

I cannot understand your request. Please type more than one sentence. If you have trouble with language, I would understand. But I need more words to work with to know what to give you.

[LaRetta]

Okay, I'm going to try and guess what you are asking ...

Attached is a file which shows a basic relationship. Every table should have a unique, auto-enter serial (which is called its primary key). In the attached file, you will see that each table has one (and I have called it by its name so it is clear ... ParentID and ChildID).

Then, when you want to create a relationship, you place the primary key from the parent in the child table. You will notice the child has a ParentID as well. The ParentID, when it resides in a DIFFERENT table other than itself, is known as a foreign key.

So your child table has a primary key (ChildID) and a foreign key (ParentID). If you look in the graph (File > Manage > Database > Relationships tab), you will see they are joined on this ParentID (double-click the = between them to bring up the relationship dialog box).

You asked about Lookups ... now since the two tables are related (on ParentID), you can (from your Child table), 'look up' parent information. If you check File > Manage > Database > Tables tab, and select the Child table, then go to Fields tab, you will see I have added a calculation on the CustomerType field, telling it to 'look up' information from the parent.

But, you don't always need to have duplicate fields. As you can see on the Child layout, the yellow field is a field from the parent! You can cross-place related fields which saves having duplicate data and cuts down on the number of fields. In a 1:1 relationship (one parent, one child) you can cross-place both directions and it works perfectly. In a 1:n relationship (one parent, many children), you can place the parent field on the child and it works perfectly. You can also place the child field on the parent BUT ... you would only see the first child in the field on the parent layout. To see ALL children on a parent layout, use a portal.

LaRetta :smile2:

Relationship.zip

[kc0hwa]

a. entry Serial

b. name as [xname]

c. bday as [xdate]

xname

[

alpha as string

bravo as string

Charlie as string

]

xdate

[

yyyy as int

mm as int

dd as int

]

I hope that help

ya I do have Getting Ideas to the real word Problines

[LaRetta]

I am sorry. I have no idea what your example is showing me.

I hope others can step in and help as well ... :crazy2:

[bcooney]

OK, I'm gonna give it a shot, lol.

In Manage Database, you define fields. Each field can be one of several types.

Names.

I'm assuming that you want a first, middle and last name. Then, you want to put them together. So, you'd create a third field, Name_Full, which would concatenate the three strings together to produce a full name.

Date is a type of field. So, birthday would be a date field. You can extract the month, day and year from a date field using Date functions.

Have a look at the InvoiceDemo I just posted. I think it's a nice simple database to take apart. InvoiceDemo

[kc0hwa]

Dynamic (relationships)!

dynamic databass is what I did on filemaker pro(v1)

[Ocean West]

kc0wa

if English is not your native language please try this:

http://translate.google.com/translate_t?hl=en#

[Søren Dyhr]

I did this in FM 1 and 2! I forgot what I did!!

Wrong! ... relations apeared with fm3, although there were lookups back then, but they worked the same way as spread sheets linking functionality.

But only on special occasions where historic facts needs recorded, such as a snapshot of fluctuating price in an invoicing solution would lookups be needed. The general aim with relational approaches is to prevent redundant storage which might go out of sync' eventually. The earlier versions you mention were what is considered as flat structurally speaking.

Giving you a link to a relational theory primer, is a bit tough - but to give you some ideas of referential integrity's implementation with this tool could this movie possibly be quite enlightning:

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

--sd

[kc0hwa]

ya

I know I had to code to get that to work before!

I thing the .mov help! any more?

trouble with relashionship

1. get a list

and

2. if not in list it make new entry!

thank for all your time!

Edited February 5, 2009 by Guest