Could anyone pout out some of the things that separate File Maker Pro from other Database's that are out there?

The things I

"The things I

Maybe it just a different prospective,

But if I want to have the ability to attach a list of email address to a client record, I need a table of email address that are related to clients record. So in the end I have two tables, with the related table being viewed with a portal. There is probably a better way to do this.. but this is how I know how to do it.

So I would have something like, pseudo code

Table Client{

Client_ID;

Global Client_ID;

}

Table Email{

Client ID Related to Client.Client_ID;

EmailAddress;

}

Of course, if the relationship allows creation of related records and you are using a portal, you merely type the new email address into the last line of the portal and omit creating a new record and transferring the ID steps.

I think you need to learn how to use Filemaker. There is ZERO code involved to do what you are trying to do. You just go into the define database dialog and set up a relationship between the two tables. I suggest you start with the tutorials.

I did a few examples before starting a multi relation database. I'm just using pseudo code to illustrate the steps involved (Coder for ).

I just don

Well it's hard to say without seeing all the table descriptions or descriptions of what you are trying to do. You keep mentioning some problem with lists and then providing absolutely zero descriptive information. Your statement "The things I

I just don

The company that I'm working at has 1200+ tables in its non-FileMaker ERP system. Many of the tables have only two columns and one row. Dozens of new tables are introduced with each new release.

Reporting off these highly normalized DBs can be a bugger. It's common to have to string 20-30 tables together to get a report.

Notice that I didn't say "highly normalized"

I used the conveniently vague term "properly normalized"

You can interpret that many ways, of course. While relational database theory often implies that a proper database be fully normalized, it rarely makes sense to do that from a practical point of view.

Well I