Auto-create related record

[JimmyLewis]

Hi,

I am using several different tables including employees and contacts, the relationship being 1->1;0, and i wanted to create a button in contacts that will automatically go to my employees layout/table, create a new record and in the kp_id (the related field serial between employees and contacts) i want it to automatically insert the record ID of the related record i am coming from, i.e. simply create a related record.

I have been told by many people that for each copy/paste there is a better and more logical approach. Can anyone suggest any?

thanks in advance,

Jim

[Søren Dyhr]

I have been told by many people that for each copy/paste there is a better and more logical approach. Can anyone suggest any?

These suggesters are not as daft as it might seem, however are there at least a handfull of answers to choose from here, first would I know if you deliberatly ignore the native "allow creation of related record..." option found in the relations def. and if why?

You have to consider that the phantom'ish view in a layout could be prevented by having two relations def.'s one for the creation of child records and one for the portal display purposes.

But why not throw you into the deep end of the pool, right away to see what a many headed beast you actually are approaching:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000927

--sd

Edited August 2, 2009 by Guest

[Søren Dyhr]

BTW, I'm not saying the method referenced by Søren is wrong or worthless.

Thank you for pointing this out, hence the desire to throw someone out in the deep end of the pool. From a designing angle is the question if scripting as such should solve every encountable problem or more structural methods exists, and least not that developers might consider both - even using a bit of both to provide reusable code:

http://web.mac.com/zueiv/iWeb/FileMaker/Script%20Killing%20Techniques/AFA363C6-2D85-4C6D-82E2-273F3722A69E.html

...thowing some of the scripting into a custom function, to prevent inconsistent scripting.

--sd

[JimmyLewis]

Thank you both for your insightful advice. The truth is due to the fact that i am a beginner, LaRetta's option seemed more suitable for my understanding, which is crucial for me.

My issue was that i wanted this record to be created automatically, but through your explanation i realized that by creating a field in my contacts describing the status of that contact as an employee i could then use LaRetta's script and create a script trigger on the modification of that field to "Active".

-----------

The script is essentially two, and looks like this:

if [CONTACTS::status = "Active"]

Show Custom Dialog [Create Employee Record?"....]

if [Get (LastMessageChoice ) =2]

Perform Script ["LaRetta's Script"]

End If

End if

-----------

Is this a good approach in your minds?

Are there any issues i should be aware of in the future using this technique?

Thanks, really.

Jim

[comment]

I don't see why you need to create a blank employee record, just because someone selected "Employee" as the status. If you have actual data to enter into the record, you can simply enter it into fields from Employees placed on a layout of Contacts. This will create the related employee record automatically (provided you have enabled automatic creation in the relationship's definition).

[Søren Dyhr]

provided you have enabled automatic creation in the relationship's definition

But is the cool factor high? : ... it takes next nothing to debug if a checkbox is chosen or not, while scripting could call out for casualties....

--sd

[JimmyLewis]

well, your question is one i have raised several times, but has two aspects: one a layout aspect and one a logical one.

As far as the relationship logic is concerned, contacts and employee is a 1 to 1;0 relationship, hence it should have a separate table.

Moreover, "contacts" contains all the contact info of a person; his designation as an employee (or applicant/interviewee for that matter) and all the attributes that follow that designation i separate to different tables because (a) visually contacts would be bulky filled with info that one would not need to see when viewing a single record, and (: for the end user, separating such fields with help dictate the workflow one SHOULD take;

for example, a contact can be created, but when his designation changes to employee, this is the time when his start date/end date/salary etc are described by the user. Why not separate the layout, relate the employee record to contacts, have a drop down to select the "contact" in which to create the employee record with, and have the basic contact info appear there, obviously taken from contacts?

Does this not seem like the smart way to do it? Your input is well appreciated, i am really just a beginner here...

[comment]

I am afraid you are missing my point. See the attached file for a rough sketch of what I meant.

OneToOne.fp7.zip