Best way to deal with multple contacts

[esegal]

I am new here and have tried to find a solution to this problem by searching, to no avail.

I have a Records DB related to a Contacts DB. In the Records DB I have, say, a fax cover page. I type in a last name to locate and insert all pertinent contact info from the Contacts DB (first name, company, fax #, etc.), however there may be many people with a same last name in the Contacts DB. Typically the wrong contact pops up and fills the blanks, so I currently have a pop-up menu listing all people with matching last names and I can pick the correct contact from that list. It is not a very elegant solution. I'm about to release my DB's to the whole office to use, but I need it idiot proof first.

I thought that in the case of multiple returns, a dialog could pop up asking to pick a particular contact from a list. Are there pop-ups like this?

I'm wondering how others handle this situation. I have begun to flirt with Portals but am too much of a newbie to figure it, at least at the moment.

I hope this was clear.

<<edit>>

Oh! Also, when a DB file is refreshed (records imported into new file) my contacts last names are re-looked up and the old records will now have been refilled with the wrong peoples names and info. Is there a way to lock a record once created so the values can't change? I do have uniquely serial # ContactID fields in all of my DB's.

[Ender]

Welcome esegal!

One approach is conditional value lists: Select a last name in a value list showing all last names, then choose from a conditional value list showing only the first names that have the selected last name. This approach has a major drawback; if there are thousands of records in the Contacts file, these value lists can be too large to use effectively. There is also the possible problem of having a mismatch because of two contacts with the same first and last name.

Even with a regular portal, your users might have to sift through hundreds or thousands of records. Filtering a portal is a way to reduce the number of the related records: If you have a second relationship to Contact that is based on a global Name field, you can use that to make the portal show just those contacts that match the Name, then use a button in the portal attached to a script that sets the Record's Contact ID to the related Contact ID.

Another approach is to perform a find for the contact in the Contact file, then jump to the Records file and set the key, creating the relationship.

It's not clear what's in your Records file or how much data your planning on having, so it's hard to recommend one over another. WAN speeds can also be an issue with some approaches.

[esegal]

Thanks for the Welcome!

For starters, I have about 4,500 contacts in my Contacts DB. Any one of them may be invoked into my Records DB, so isolating contacts into groups doesn't really work since there is no real group criteria. I did try to set up a portal in the Records DB to show the other contacts in the Contacts DB with matching last names, but don't know how to update my record from the portal. What script would that be?

My Records DB has Fax Cover Pages (First Name, Last Name, phone #, fax #, etc.) Transmittals (same as fax but with address, too), Letters, Memos, Reports, Logs and a myriad of industry other forms that use the same types of standard contact information. All records access the Contacts DB the same way, though a last name search. This is why when records are re-looked up, all the contact info in the record changes. This is very bad for archiving files.

Thanks for the help!

[-Queue-]

Put a transparent button within your first portal row. In the script attached to it, Set Field [somefield, relationship::somefield], where 'relationship' is the one used by the portal, all the necessary fields in the Records file. This will set your fields based on the record you click in the portal.

[Ender]

When matching a Records record to a Contact record, it is important that you use the Contact's unique ID, and not the name for the relationship. To do this with your existing Contact by Name portal, create a button on the portal attached to a script in Records, we'll call it "Set Contact ID button", that has this script step: Set Field [ Contact ID , Contacts by Name::Contact ID ]. This sets the Contact ID in Records to the Contact ID of the portal row that was being clicked.

I still don't really grok your Records DB. Maybe it's the name. Would Note DB or Transmittal DB be more fitting? Doesn't really matter, I guess.

Why do you have to relookup data for existing records? What needs to be updated--just the newly imported records? If records do need to be updated, then can you find the ones that need it and update just those?

[esegal]

Thanks for the suggestions. I'll try incorporating those ideas right away. To answer Ender's question: when I say "Records" it is in place of the name of whatever project the DB is for. I have a different DB for each project I am working on and the DB is to generate and track all correspondence and record keeping for a project.

Re: Relooking up records: What I've done in the past (and I'm sure it's the long way around) is to use a project DB daily while I make the next generation DB on the side. When I'm ready to update, I export and import all the records from the old DB to the new. The problem is that for whatever reason many of the people who the record was intended for change to other people with the same last name. I want to avoid this from happening.

My goal is ideally to have one DB for all my projects, I'm just not experienced enough with FM Pro to work that out yet. This still won't solve people changing when I upgrade files. That's a problem when there are 1000's of records in the DB to hundreds of people.

[Ender]

You can avoid data changing on import by deselecting the "Perform auto-enter options while importing" checkbox.

You just have to remember to update the "serial number next values" on your ID fields so they match what you had in the previous file.

[esegal]

Your suggestion works great! Thanks to you both. I'll take your advice on the auto enter option next time and see what transpires.