Created multiple related files w/ expanded info.

[mehronx]

I currently have a contacts database in which each contact type is designated by a value list.

I would like to create a related database for each type in the value list. So for example, I would have a database with all the "Personal" contacts from the main contacts database in it. I'm not sure if this is impossible or even very simple. I've played a little, but haven't got it yet.

Maybe I should just make several new layouts in the main file?

Or maybe the only way is to make each related file store the info for the main database as in any other many to one relationship.

[mehronx]

This might also have to involve some kind of portal if it can be done at all. There really isn't really any unique key for each record, just the type designation, so I don't know how I can get the group of records to start with.

[mehronx]

How about this:

Can anyone suggest a strategy for keeping a contacts database with specific information for specific types of contacts?

So, for example, Employees would need to show a SS number and birthday, but no one else would.

Should there just be multiple layouts? This doesn't really seem like the best strategy, considering the user could easily end up in the wrong layout for the contact type.

[EllenG]

I just do it with one db and relationships. The user can select a name from a popup list (that contains all contacts), then click OK, which runs a script and selects the correct layout depending on the contact type.

I also have a search screen setup as a portal, that uses a relationship of a global_text (gType) field to Contact Type. The user can select the contact type from the list into the gType field. The portal lists the records from that relationship, and the user can click on the name field (scripted) to go to the detail record.

It works just fine. I think that's cleaner that having a separate db for each type. (In my case, the user can define new types, so a separate db wouldn't work anyway.)

[mehronx]

This sounds like something that could be tailored for my situation in some way or another.

But it also sounds like you have far less contacts. I have close to 9000 contacts.

[ernst]

Make your Contacts database with an ID field for every contact and a text field with a valuelist attached which flags if that contact is an employee, a customer, a supplier, etc.

Then define one calculated ID field for each flag, with calculations like:

Case(PatternCount (text field, "employee") > 0, ID)

Case(PatternCount (text field, "customer") > 0, ID)

Case(PatternCount (text field, "supplier") > 0, ID)

etc.

For each calculated ID field you should then define a relation to the file that holds information specific to that flag, like the employee file could hold the social security info of that employee, the customer file things like preferred shipper and payment method, and so forth.

Regards,

Ernst.

[EllenG]

No my contacts list is not that large, but it made me think about that, as my potential users could have several thousand contacts... To see the impact, I populated my test db with over 9900 records. (Exported and Imported the same data in a script until I reached over 9000.) The concept still works and retrieval is very fast (almost instantaneous.) The only problem is the number of rows I can display on a screen in portal mode; and the user has to use the scroll bar down to see the remaining records. However, I integrated this concept with an alpha lookup as well, so that the user can list all the Supplier records, for instance, or list suppliers beginning with A, B, C, etc. I created 3 relationships, so they can do the search on Company Name, Last name or first name. Then I have related scripts for each, so that the user can select the name in any of the screens and the script will get the ID number from the portal record selected by the user and retrieve the detail screen. A different detail screen may be used based on the contact type.