New Related Record W/O Portal

[kenneth2k1]

Also, I think I will have to change my primary key because when I change the name of the producer associated with the prospect, it switches to a record that is related to that producer.

[Kurt Knippel]

I base all of my key/defining relationships on a non-user defined ID. See my article on how to do this...

http://www.fmforums.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=8;t=000018;p=

The benefit is that you can change any data and it does not have any possibility of affecting the relationships.

You can still create display and temp relationships based on other fields.

Also once you break the idea that your keys are user-defined data elements, it opens up the possibility to create records and relationships that are independant of the current record's data.

[kenneth2k1]

Kurt:

Thanks for the link. I read this post when it came out, but it still leaves my question open. Forgive me, but perhaps I do not fully understand the concept of using these serial numbers as keys. To me, it seems this will give you a serial number that is almost impossible to duplicate. Would I instead have this as my primary key? Wouldn't that yield the same result, but with a bigger number??

Sorry for the question, I think I will just have to go back and refresh my relation db material.

Thanks for your patience.

Ken

[IdealData]

Ken

Back to your original request.

There's nothing wrong with using a portal to create new records in the related file. Just make sure you've got all the related fields you need inside the portal.

Your portal rows can be as big as you like - so you could easily give the effect that the related data appears to be seamlessl part of the master file. You must have a scroll bar otherwise you can't get to the last portal row. (This is true in ScriptMaker too )

What's the real reason you don't want to use a portal ?

[kenneth2k1]

Hello!

I have been using relationships for a while now, but I have never had a use for creating a record in a related file - until now.

I have one file with prospective client records. I have related it to another file that contains producers (or agents). The primary key is the client record number.

Here is what I want: I want to be able to create a new producer record from the client file. But I want to be able to do it WITHOUT a portal, because I would like to be in a layout where you can enter name, address, phone #s, letterhead info, etc.

If you could point me in the right direction, I would be most appreciative!

Ken

[kenneth2k1]

Thanks Kurt and Mark for the replies. Kurt, I used your calc for record IDs in both my prospect file and my producer file. Then I went and related the two files via these ID fields. One thing that encouraged me was that I was able to create a producer record from the prospect file related to the producer file. Thats great. The only problem I am having now is that I cannot enter the name of an existing record in the related producer file. Can you help me resolve this?

Again, I have never had a need for a relationship of this type, so I am not familiar. It would appear that I have a Many-to-One relationship (because many prospects can have one producer).

Please advise. Thanks all.

Ken

[kenneth2k1]

Ok, here's how I solved my problem:

I created a relationship using a field "NameProducer_Last.p" (producer's last name field) as my primary key. Then I linked it to "NameProducer_Last.f" in the producer file. Then, I can enter the last name of the producer in "NameProducer_Last.p", hit Tab, and it will bring in all the related info I need. If I need to create a new one, I just hit enter on my primary key field and a new record is automatically generated because I used "Allow creation of related record".

Kurt, you were right. Not having relationships made with user-defined IDs is definitely the way to go. Only in this case, I am using a last name. I am still using your technique for creating a record ID, though.

Is this setup OK? Should I be aware of any problems? Thanks for your help.

Ken

[duncandawg]

I'm having a similar problem. Within a HUGE Credit Processing DB (several related files), I have a customer DB with several layouts. On one of the layouts, the user can enter various telephone nos for the customer in a portal, and assign a phone type (ie home phone, work phone, cellular, etc etc.) This is related to the Phone Nos DB by cust ID.

But, if the user does NOT enter a work phone no on the first layout, later when they are taking the customer's employment info, I still want the user to have the option of entering the customer's work phone no. - but just as part of the form, not within a portal this time. I would like to have a field on this layout which will allow a new related record to be created in the Phone Nos Db and be of type "Work Phone". I realize I could script this to happen on a field exit, but I haven't decided if I will be purchasing the external plug-in yet. So, is there a way to create a new, related record from a field on the layout, or if it must be from within a portal, is there a way to do this without scripting it? I hope I'm clearly explaining what I am attempting to accomplish. Thanks.

[LiveOak]

Ok, to clarify the whole situation and technique. You can create records in a related file using scripts, much as you can create them manually. To do so you must setup the related key field as part of the scripting. The basic process is:

1) Capture a copy of the key for the current record in your main file.

2) Go to the related file and create a new record.

3) Set the matching key in the related file to the value from the main file.

At this point you can access the related record's field from the main file. All of the above is done for you when you use a portal and "allow creation of related records" and enter into the blank portal row.

First, you need a way to take a copy of the Key in your main file. Copy and paste is not recommended. A better way is to create a relationship in every file based upon a constant. Create a fields in both (or all of your) files:

One (calculation, number, indexed) = 1

In your main file, create a field:

gKeyTemp (global, text)

Create a relationship from your related file to your main file based upon this field. This relationship matches every record to every record, so it is only useful for accessing globals in your main file FROM your related file. Your basic "create a record in the related file scripts" will then look like:

* In the Main file *

Set Field (gKeyTemp, YourKey)

Perform Script (external, related file, NewRecord)

* In the related file *

New Record/Request/Page

Set Field (RelKey, RelWithMain::gKeyTemp)

Of course the scripts will have other enhancements, but this is the basic approach.

-bd