Creating a related record without switching layouts

[Ron Cates]

I recently read a post or a blog or something describing a technique for creating a related record using a global field to trigger record creation through a relationship. I have been trying to find it for a couple hours wiith no luck. Can anyone point me to a post or blog that describes this technique?

Thanks

Ron

[Ocean West]

here are a few options

http://fmforums.com/forum/files/file/19-context-free-record-creation/

http://www.filemakermagazine.com/videos/super-quick-data-entry.html

[Ron Cates]

I think the "Super Quick Data Entry" is very close to the one I had read previously, but hey, this one has a video. Sweet!!

Thanks Ocean

Edit:

What a buzz kill. I downloaded the full version video and it comes up audio only :(

[bruceR]

Or try this example: #3

[Ron Cates]

Thanks Bruce. That example looks like exactly what i'm looking for. Still looking for a write up to explain it all though.

[Vaughan]

This is what you need.

http://www.filemakerhacks.com/?p=2364

[Ron Cates]

Woohoo!! That's the one I was looking for.

Thanks Vaughan :)

[bruceR]

Hm, FileMaker Hacks web site seems to be down...

[Ron Cates]

Wow!! I have to say this magic key technique is awsome. I am about to start a rebuild of the Database I've been working on for three years and I am seriously thinking about using this as a standard method for creating related records. For those who are familiar with the technique I wonder if you could tell me if this makes sense to you.

Include a magic key global in every table

Create TOs for creating related records with the magic key

Standard new record script would be accomplished without having to set variables or switching layouts

In one example In the current Database I have a process that

loops through a sometimes very large found set of records.

For each record it ;

sets veriables,

goes to another layout,

creates a new record

sets fields with the variables.

Go back to original layout

Next record repeat

With the magic key technique it would be

For each record it sets fields directly through the magic key relationship thus creating the record

Clear the magic key

Next record repeat

Seems like that would be a very significant difference in processing time.

Any thoughts?

[LaRetta]

Any thoughts?

Ron, although I am usually one to jump on new things, I would hesitate to use something unusual that may change in subsequent versions. I have not had a chance to test ... does this work the same back through version 9 or prior?

[bruceR]

There is nothing unusual about this. It is expected and documented behavior of the "allow creation of related records" method that has been here since what - FileMaker 3? By definition, fields will be populated on the other side of the relationship. Relationships are two sided.

[LaRetta]

I understand quite well how allow creation works, Bruce.

[Ron Cates]

Thanks for your input and I do feel your concerns LaRetta. I have not had a chance to test on any other versions other than 10 and 11. But as Bruce said it isn't an abnormal behavior, just a different way of taking advantage of the way things work. I feel confident that there would be no reason for this to change.

[dansmith65]

I use a modified version of the "magic key" method...

Rather than creating a field named "g_magic_key", I use fields that already exists: constant_1, and modifiedTimestamp. In place of "g_magic_key", i use "constant_1", and in place of the "id" field in the related table, I use "modifiedTimestamp". It produces almost the same effect, I just don't have to bother clearing the "g_magic_key" field.

In regards to using it as the standard method of creating related records...

I only use it when I don't want to either change layouts or create a new window to create a related record; which is to say, I use it sparingly. Partially, I think, because I don't like having a bunch of relationships only used for creating records. I think it's a preference thing though; the technique is definitely cool.

I forgot to mention, the first time I heard of this basic technique was from Kieren MacMillan's FastCreate demo. I cant remember where I found it though, otherwise I'd link to it.

Actually, since he's got his name in the demo file, I'll attach it here.

FastCreate.zip

[Ron Cates]

In regards to using it as the standard method of creating related records...

I only use it when I don't want to either change layouts or create a new window to create a related record

I can't think of any times right now that I would want to change layouts or open a new window if I have the option not to. Unless the process requires staying on the new layout for further action. I agree that probably the one drawback would be having to create special TOs for each related table you would like to create related records in. But for me, because I have my solution organized in a way that new records are only created from a few places I don't think this will be a problem. Especially when it can save me all the trouble of having to script a way to preserve portal scroll location and tab views which are always lost when switching layouts.

[Lee Smith]

Kieren MacMillan's FastCreate demo. I cant remember where I found it though, otherwise I'd link to it.

Actually, since he's got his name in the demo file, I'll attach it here.

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

Lee

[bruceR]

I use a modified version of the "magic key" method...

Rather than creating a field named "g_magic_key", I use fields that already exists: constant_1, and modifiedTimestamp. In place of "g_magic_key", i use "constant_1", and in place of the "id" field in the related table, I use "modifiedTimestamp". It produces almost the same effect, I just don't have to bother clearing the "g_magic_key" field.

I can see that it would allow creation; but often when you create a new record, you may want to place data in several fields in the record; and you may wish to re-select the record at some other time to update it. If you are linked by the time-modified field; and then you modify the record - then it seems to me you are no longer linked to the record. Or did I miss something?

[dansmith65]

you may wish to re-select the record at some other time to update it.

This is true, my method does not allow for this; it is for creation only.

If you are linked by the time-modified field; and then you modify the record - then it seems to me you are no longer linked to the record. Or did I miss something?

That's what I thought at first too, but testing showed that the relationship is active until the record is committed. This means you can have two or more set field steps in a row, the first one will create the related record, the subsequent ones will edit that record.