Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Get value from field on layout in background


kristans

Recommended Posts

I'm popping open a window to allow users to choose among addresses. However, to write the selected address to a table I also need a value available on a layout open in the background. Is there a way to look up the value in a field on that layout in the background?

Link to comment
Share on other sites

Would you like to clarify your question? I think I understand the first sentence. The second sentence I don't understand and don't agree with. smile.gif

Link to comment
Share on other sites

Thanks for the comments, comment.

 

Sorry I was unclear. Situation is this. I have a layout that shows address records. A portal is used to show all of the addresses that are associated with a contact's ID. I want to enable users to add another address record for a contact and so I pop open a window that allows them so see available addresses. I want them to be able to click on an "Assign" button and have the address info written into the appropriate table. But, to do that I need to know the ID number of the contact on the underlying layout (pre-pop up window). I'm wondering how I can get that value.

Link to comment
Share on other sites

I believe the originating contact record is waiting for you on the "underlying layout" where you'll end up after choosing the address and closing the new window.

 

I wish I could be more clear, but I don't know:

Where are the addresses coming from?

What is the relationship between contacts and addresses - it seems this is a many-to-many?

 

IOW, give us a fuller picture of your data structure.

Link to comment
Share on other sites

Thanks for the comments over the weekend. I didn't want to bore you with the details in case this were an easy question, but it seems the details are essential.

 

There are two critical tables in the picture. A "Contacts" table has info such as name and title, and it also has an auto-assigned contact ID field. A related table has address information, address IDs. The two are linked by a table instance that combines address IDs and contact IDs (because a contact can have numerous addresses).

 

In our layout, we show the basics on the contact (name, title, etc.) and then use a portal to retrieve all of the addresses associated with that contact. What I want to do is pop open a window that allows a user to associate a contact with another address. I can use a script to write values into the contact-address related table but I need to retrieve the contact that is "active" at the moment. That value is available on the layout from which the pop-up window was launched but I need to retrieve that value to use it in my script.

 

That make more sense? I'm also open to other suggestiosn on how to accomplish this.

Link to comment
Share on other sites

I can think of several ways to accomplish this, here's a very simple one:

 

Have a global field gContactID in the Addresses table.

Start the script with:

Set Field [ Addresses::gContactID ; Contacts::ContactID ]

 

Another way is to let ContactID be the script parameter. Much depends on how you prefer to actually create the records in the join table.

 

 

As an aside, the structure seems to be a bit strange. Unless you're a landlord, or a housing agency, that assigns people to one of a known set of addresses, that is.

Link to comment
Share on other sites

Thanks for the suggestion. I'll give that a shot!

 

I work for a foundation. We're working on the redesign of a very old FMP database that has, among its many problems, the unfortunate situation where we have multiple instances of the same address because several people that we would like to contact are at the same address. By maintaining a centralized listing we're hoping for one-time updates rather than having to have people remember to find and replace on all addresses or have a script that checks for other instances and then go update them.

Link to comment
Share on other sites

Here's why it seems illogical to me:

 

What do 2 contacts at the same address have in common?

 

Unless they work for the same organization, if one of them moves, the other one stays. So you would need to unnasign the moving contact from their present address, and assign them a new address. If the organization that moves has 20 contacts in your database, you need to do this 20 times. The only scenario where this will come in handy is when they change the name of a street - then this structure will be a winner.

 

I'd think the answer to the question is: they belong to the same organization. So they should be assigned to an organization, and the organization has an address (or several ones). If 2 organizations happen to reside in the same building, that's a mere coincidence - like 2 people named John. You wouldn't assign all the Johns in your database to a "John" record in a Names table, would you?

Link to comment
Share on other sites

  • 2 weeks later...

Kristans -

 

Attached to this post is a copy of a database I'm working on with, I think, a similar purpose - allow users to choose from several addresses, phone numbers, etc., all of which are kept in related tables. Mine is a work in progress, and I'm also new at this (I've needed lots of help from the likes of comment, kjoe, ender, et al) but you might find it helpful. Ultimately, the organization I work for hopes to use this database to handle donations and pledges, too. If you have any comments, please post!

Link to comment
Share on other sites

To alterbentzion,

 

Thanks for the attachment. I just took a quick gander after the system notified me of your post, but the relationships map that you have looks very, very similar to what we are trying to do with our system here. With my colleague, we've been talking through our logic model and trying to find situations that break it or play to its strengths and it seems to hold up really well.

 

We'll look at your file much more to see if there are elements that we can learn from.

 

The layout designs are really cool.

Link to comment
Share on other sites

Good points, comment. No, the Johns thing is not something we would do. But we do have situations where someone has a home address, a work address, a summer address, is associated with multiple organizations, and is visiting a particular organization for a period of months so that is also a contact address. It's mind-numbing to try to capture all of the address and telephone combinations. So, we normalized the data and it seems to cover the situations that have troubled us in the past.

Link to comment
Share on other sites

Thanks for the link, comment. (Downloaded one video, but haven't seen it yet. Talk about on-the-job training!)

 

The main reason why I've structured my database this way is that I need to be able to consistently associate donations with donors - many of whom (e.g., "snowbirds") have multiple addresses/phones/etc. Until now, we've been using MS Access on Windows, and the old database had all personal and contact info in one table, with limited/inflexible fields.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.



×
×
  • Create New...

Important Information

Terms of Use