Jump to content

Store Multiple Fields from Portal


airborne
 Share

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

Recommended Posts

I have two data tables that are each storing relation information into a third table. The two data tables have ID and also an additional field with information of the type of data the table is storing. Well, via a portal, the user gets to store some other data and what I want to do, is store in the relation table, the ID, and this other table identification field along with the other information that the relation table is designed to store.

The problem is that I am only able to store one of the two fields and not both. I need both because the combination of the two fields is the unique key. I created a relation in the data table to the relation table for the ID, and it stores fine. I created a relation for the other data, and that is stored too, but I can't seem to get both pieces of data to be stored.

Any clue would be helpful. If what I am describing isn't clear, also let me know and I can try to further explain it.

Link to comment
Share on other sites

There is almost certainly a solution. The trick is understanding the problem. Could you restate it in a more legible form? (Hint: Try calling your tables "A", "B" and "C", or give them short names that describe what they are. Then specify which fields [and name the fields, too] and which tables you're talking about.)

Link to comment
Share on other sites

Ok, regardless of whether or not this is the best implementation. I would still like to solve the problem in the way that I will describe. The reason I say this is because I will try to get the question across without getting into the entire project. Please bare with me.

Table "A" stores information about CUSTOMERS, table "B" stores information about DEALERS and table "C" stores phone numbers. Now table "C" needs to store the not only the phone numbers, but also the unique ID as well the indication of which type of person the number belongs to. Basically, the data that the "RELATION" table "C" needs so store, is the "PhoneNumber","Id","CUSTOMER" | "DEALER".

I was able to get the ID or the DEALER | CUSTOMER indication, but not both.

I hope this helps

Link to comment
Share on other sites

In the CUSTOMERS file, create a calc field that appends a code to the ID field, for example:

phoneID(calc,text) = "C" & customerID

Do the same in the DEALER file:

phoneID(calc,text) = "D" & dealerID

Match each of these to the phoneID field in the PHONES file. If you need to have separate fields for type and ID, then you can use calc fields in PHONES to extract them:

contactType(calc,text) = Left(phoneID,1)

or

contactType(calc,text) =

case(

Link to comment
Share on other sites

Based on your reply, I am guessing that there is no automatic way to have both fields come from the parent table. I guess that will work then, but my next question is how one would trigger the code? I am more familiar with event driven programming where I can say something like OnInsert(...), but at what point do I execute the script to add that code.

So when the user enters a new record, is there some type of OnNewRecord event or something similar that I can have envoked? It appears that the one field is being stored via the Relation and I have to populate the second but again, at what point.

Sorry for the repetative question above, I just wanted to make sure that the question clear. (I hope is was)

Link to comment
Share on other sites

Once you create all the fields, create a relationship, called Phone, from CUSTOMERS:phoneID to PHONES:phoneID. Check the box to allow creation of new records using this relationship. In CUSTOMERS make a portal using the Phone relationship. Put the Phones::PhoneNumber field in the first row. In Browse mode, every time you enter a new phone number into the last blank portal row, a new record in PHONES will be created and will automatically get the PhoneID of the current CUSTOMERS record.

Do the same for DEALER as you did for CUSTOMERS.

Link to comment
Share on other sites

This topic is 7237 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.