Jump to content

Best way to deal with multple contacts


esegal
 Share

This topic is 6436 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 6436 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.