I know there is several ways to handle this -- I am looking for best examples and why for moving field data from one layout to make a new record on a different layout.

I would like to physically copy the data... in about 17 fields

Should I use the set field with variable function or is there another way to move this much data?

Joseph,

Records do not belong to layouts, they belong to tables. Layouts display the records.

You have a layout that shows about 17 fields from one table. You wish to, perhaps, copy/duplicate this record?

Edited October 13, 201015 yr by Guest

Sorry -- I knew that --- Opps

I would like to duplicate the data in some fields (table 1)into another table (Table 2)with the same fields but a totally different layout.

Have you posted a simple diagram of your table structure? I'd like to help you with the design or data model.

Redundant fields are often a red flag of poor design.

But, to answer your question, you'd probably import from one table to another, being careful to limit the found set in the source table.

Oh good thought...

Here is the Structure:

Tables:

CALL_CallLog

INS_Insured

Releationships:

ID_CallLog -- id_calllog

Script:

Set variable [$ID_CallLog; Value:CALL_CallLog::ID_CallLog]

Goto Layout [iNS_Insured]

New Record

Set Field [iNS_Insured::id_CallLog; $ID_CallLog]

Commit Record

Fields want to transfer from CALL_CallLog to INS_Insured

CALL_CallLog Fields:

Caller_FirstName

Caller_LastName

Mailing_Street1

Mailing_Street2

Mailing_City

Mailing_State_Province

Mailing_State_Zip

Phone1

Phone2

Fax

INS_Insured Fields:

Ins_FirstName

Ins_LastName

Mailing_Street1

Mailing_Street2

Mailing_City

Mailing_State_Province

Mailing_State_Zip

Phone1

Phone2

Fax

Yikes!

CALL and INS should be related by INS_ID. That is:

CALL

__kP_Call_ID

_kF_INS_ID

Note (contains the text of the call notes)

INS

__kP_INS_ID

Ins_FirstName

Ins_LastName

Mailing_Street1

Mailing_Street2

Mailing_City

Mailing_State_Province

Mailing_State_Zip

Phone1

Phone2

Fax

To create a new call entry you need to populate somehow the foreign key INS_ID into a call record. This can be done in several ways.

The CallLog will happen first -- this is why I related the Insured Id to that... Not all callers will get mad into a Insured record...

Thank you for your help so Far

Edited October 13, 201015 yr by Guest

Oh, now I get it. You are capturing data about a caller, and then at some point you'll "promote" them to an Insured record. Is that correct?

Perfect -- But only if they meet basic requirements... The calllog is really for understanding where the market is -- the insured page is where the real work starts...

Any thoughts on how to promote the fields..

Is the call log prepopulated from a leads table? Or, are you really asking someone for all that info? What is the biz process.

(The overriding concern is to not duplicate a person).

How about staying in the same table (I'd call it "PEO") and just adding a flag_Ins that equals 1 when they are "promoted?"

Again, I need to know more of the biz process.

hmmm -- I thought about keeping the CallLog and Insured in one table but I think It will work better to keep it separated...

The Biz:

We will be fielding calls for a product -- Some callers will qualify and other will not --- Yes all of the CallLog Questions will be entered by a team of Analysts... This will be our first input...

I just did not want to have to type the info over again in the insured table...

Very important -- there cannot be duplicates of the calllog table --

Problem: I do not yet have a unique Code so this does not happen -- I do not want to ask them for more than I have to in this first step... so I was thinking making a identifier by Firstname, first 2 letters of last name and state of caller -- thoughts?

OK. Whether or not you separate the Call Log people from the "Insured" people is not the whole issue.

How do you know who to Call? How is a Call Log record created? Do you import leads?

You will not have to type over the info. Either you'll import the record data into the other table, set a flag in the current record, or create a subtype table.

How do you know you aren't talking to someone who's already Insured?

Meanwhile, to avoid duplicate entries, I usually suggest a Find, and if not found Add New routine. Here's a demo http://fmforums.com/forum/showpost.php?post/324068/

OK: Had time for a demo. This uses a subtype table for those people that have been promoted. This allows for a list view that only shows those that are Insured. Now your only issue is to avoid duplicates in the Call Log table.

CallLog.fp7.zip

Edited October 13, 201015 yr by Guest

How do you know who to Call?

How is a Call Log record created?

Do you import leads?

How do you know you aren't talking to someone who's already Insured?

All the same questions I asked myself...

We are not calling they are calling us -- from marketing material sent out... Each record will be created when they call.

Your last question is the real question... I think your demo might take care of that one --

I would like the info to be on the insured page not just related to it -- this way the real record keeping will start from this table... is there away to physically move it?

But how do we take care of having duplicate callers... meaning if the caller calls once and then calls back again... Must need someway to search -- names are to common and SSN are to invasive --- I was thinking about a combo of firstnamelastnamephone?

Edited October 14, 201015 yr by Guest

What is the advantage of "moving" the data from Call to Insured? I see, actually, several disadvantages.

If you are mailing to a person, then you have their info, don't you? Why aren't you simply Finding them and then "promoting" them.

You do not need a concatenated key to Find. You can find on phone number and then ask the person for their address. Then, you'll know the record.

Again all good points --

I just was thinking the Caller might not be the Insured... meaning they may be his parents, sibling etc... there for I would have them assopciated with the insured but different names... but if it is a direct Call (meaning the insured calling) i can start the record..

Thoughts?

Again thank you for the discussion -- its probability the hardest part of any database is flow of info...

I need to know what data you start with, if any.

You indicate that you do mailing, and someone calls back...if they are a sibling, parent, etc., wouldn't they have the same phone number?

They might have the same phone -- I really cannot count on it -- also I will not have any info on the caller before they call... I will be gather lots of info on the call --- Should make it easy if they call back --- I prob can just search by full name....