AnsweredAssumed Answered

Overkill or not?

Question asked by ChrisJohnston on Jul 21, 2014
Latest reply on Jul 24, 2014 by ChrisJohnston

Like • Show 0 Likes0
Comment • 10

Title

Overkill or not?

Post

I have a solution that makes archives of information related to item we sell. Let’s say the archive name is teapot, we will give the archive record the same name. The information is in a table ITEMS::, the archives are also in their own table called ARCHIVES::. Up til now I have been creating scripts that create variables, for example ITEMS::item_name = $inm and then use the set the field script step and write it to ARCHIVES::archive_name. Would it make better sense just to use a calculation that sets ARCHIVES::archive_name = ITEMS::item_name?

philmodjunk Jul 24, 2014 9:05 AM

Correct Answer

Its using a field that just needs to be copied over

Copied over from what?

This lack of detail is why I have been confused about what you are doing.

If there is no relationship linking the target record to the source record, then using a variable is one of several standard methods for copying over the data. If there is a valid relationship linking the two records, then Set Field can do it all in one step, but only if that relationship is in place.

Other methods for moving data from one place to another:

Set a global field to the value. (This is how we did it before we had variables.)

Pass the data in a script parameter (and you can put multiple data items in a single parameter.)

Copy to the clipboard, paste from the clip board. (Don't use this method unless you have no alternative as the other options keep data copied by the user to the clipboard intact. This method is useful for copying data to/from a different application or, In versions older than version 13, with "copy all records" to quickly build a return separated list of values from a found set of records.)

See the reply in context

No one else had this question

Outcomes

philmodjunk Jul 22, 2014 11:30 AM

Why do you need to archive this data in the first place? What issue does this solve for you?

Actions

ChrisJohnston Jul 23, 2014 8:33 AM

That is a great question. It is records that I create that comes along with the web page archive I am keeping. These web page archive will be an exact view (of a web page at a particular time) that we can keep for as long as we need. It gives us a way to be clear what the web page content was at a particular time. These archives solve the issue of web pages that you view at a particular time not being the same at a later time. Firefox has a way saving these and they will be files that are pointed to by the FileMaker archive records? Thanks

Actions

philmodjunk Jul 23, 2014 8:41 AM

But that simply requires that you import this data into FileMaker, not that you then copy this data from one FileMaker table to another. If you are taking "snapshots" of the data at different points in time, you can record the date and time this data was imported as a way to track when each "snapshot" was taken.

So I still don't see a reason for "archiving" the data by moving it from one FileMaker table to another.

Actions

ChrisJohnston Jul 23, 2014 10:50 AM

I always look at what you say as good questions for my database/solution because you have provided me with the best practices and knowledge that have been very beneficial to my FileMaker development. So what you are saying now is making me ask do I need a record or each archive? I still think my answer should be yes because I take a snapshot of a page at a time, the purpose being a record of a page that could later change. They are related to a sale. SALE:: could have one archive (snapshot) or many.

     ITEM::pk --< SALE::fk
     SALE::pk --< ARCHIVE::fk

Actions

philmodjunk Jul 23, 2014 10:56 AM

I don't think that I understood you original description of the issue and am not sure that I do now.

Actions

ChrisJohnston Jul 23, 2014 12:03 PM

It might just be the way I am trying to describe something very esoteric. At this stage we are please of what it is doing for us. I have a script that creates a record in the ARCHIVES:: table. Its using a field that just needs to be copied over (in this case the name). I was creating a variable in the script and and then setting a field. I have tried it now by just setting it equal to that field via a calculation. It works. I just don't know if that is the better way or was creating a variable and setting a field overkill. Thank You always!

Actions

philmodjunk Jul 24, 2014 9:05 AM

Its using a field that just needs to be copied over

Copied over from what?

This lack of detail is why I have been confused about what you are doing.

Other methods for moving data from one place to another:

Set a global field to the value. (This is how we did it before we had variables.)

Pass the data in a script parameter (and you can put multiple data items in a single parameter.)

Actions

ChrisJohnston Jul 24, 2014 10:30 AM

Yes the record is related. Great I did not know that with a related record you can just use set field! That is extremely helpful to know. I was setting variables on when I did not have to because the records are related (overkill). I also tried it with setting a calculation to equal it, and it worked, is this a bad way? But this is great, as usual you get it done! Thanks

Actions

philmodjunk Jul 24, 2014 10:33 AM

It will work as long as the relationship matches to the correct record. Keep in mind that a relationship can be "one to many". Your reference to a field in a related record thus will refer to the "First" related record in such cases and that may not be the correct record.

I also tried it with setting a calculation and it worked,

Again, that's a bit vague.

If you mean you tried using a calculation field or field with an auto-entered calculation, that can also work, but pay attention to the picky details to avoid possible problems. A calculation field will be unstored and unindexed. This means it will always update any time you change the value in the original field--which may or may not be a good thing, but sorts and finds that refer to it will be slower than on an indexed field. And you won't be able to use it as a match field in a relationship in many cases.

If you used auto-enter (or the looked up value setting), you are copying the data over from the other record just like set field. This gives you a sorted, indexed field which is useful, but the value will not update automatically when the value in the original record is changed. This might or might not be a good thing.

Actions

ChrisJohnston Jul 24, 2014 10:41 AM

Yes... I have experienced that and other things with a "one to many", what you explain here clears up a lot that I have encountered. Invaluable, Thanks!

Actions

10 Replies

philmodjunk Jul 22, 2014 11:30 AM
Mark Correct
Correct Answer
Why do you need to archive this data in the first place? What issue does this solve for you?
Like • Show 0 Likes0
Actions
ChrisJohnston Jul 23, 2014 8:33 AM
Mark Correct
Correct Answer
That is a great question. It is records that I create that comes along with the web page archive I am keeping. These web page archive will be an exact view (of a web page at a particular time) that we can keep for as long as we need. It gives us a way to be clear what the web page content was at a particular time. These archives solve the issue of web pages that you view at a particular time not being the same at a later time. Firefox has a way saving these and they will be files that are pointed to by the FileMaker archive records? Thanks
Like • Show 0 Likes0
Actions
philmodjunk Jul 23, 2014 8:41 AM
Mark Correct
Correct Answer
But that simply requires that you import this data into FileMaker, not that you then copy this data from one FileMaker table to another. If you are taking "snapshots" of the data at different points in time, you can record the date and time this data was imported as a way to track when each "snapshot" was taken.

So I still don't see a reason for "archiving" the data by moving it from one FileMaker table to another.
Like • Show 0 Likes0
Actions
ChrisJohnston Jul 23, 2014 10:50 AM
Mark Correct
Correct Answer
     I always look at what you say as good questions for my database/solution because you have provided me with the best practices and knowledge that have been very beneficial to my FileMaker development. So what you are saying now is making me ask do I need a record or each archive? I still think my answer should be yes because I take a snapshot of a page at a time, the purpose being a record of a page that could later change. They are related to a sale. SALE:: could have one archive (snapshot) or many.

     ITEM::pk --< SALE::fk
     SALE::pk --< ARCHIVE::fk
Like • Show 0 Likes0
Actions
philmodjunk Jul 23, 2014 10:56 AM
Mark Correct
Correct Answer
I don't think that I understood you original description of the issue and am not sure that I do now.
Like • Show 0 Likes0
Actions
ChrisJohnston Jul 23, 2014 12:03 PM
Mark Correct
Correct Answer
It might just be the way I am trying to describe something very esoteric. At this stage we are please of what it is doing for us. I have a script that creates a record in the ARCHIVES:: table. Its using a field that just needs to be copied over (in this case the name). I was creating a variable in the script and and then setting a field. I have tried it now by just setting it equal to that field via a calculation. It works. I just don't know if that is the better way or was creating a variable and setting a field overkill. Thank You always!
Like • Show 0 Likes0
Actions
philmodjunk Jul 24, 2014 9:05 AM
Unmark Correct
Correct Answer

          Its using a field that just needs to be copied over

     Copied over from what?

     This lack of detail is why I have been confused about what you are doing.

     If there is no relationship linking the target record to the source record, then using a variable is one of several standard methods for copying over the data. If there is a valid relationship linking the two records, then Set Field can do it all in one step, but only if that relationship is in place.

     Other methods for moving data from one place to another:

     Set a global field to the value. (This is how we did it before we had variables.)

     Pass the data in a script parameter (and you can put multiple data items in a single parameter.)

     Copy to the clipboard, paste from the clip board. (Don't use this method unless you have no alternative as the other options keep data copied by the user to the clipboard intact. This method is useful for copying data to/from a different application or, In versions older than version 13, with "copy all records" to quickly build a return separated list of values from a found set of records.)
Like • Show 0 Likes0
Actions
ChrisJohnston Jul 24, 2014 10:30 AM
Mark Correct
Correct Answer
Yes the record is related. Great I did not know that with a related record you can just use set field! That is extremely helpful to know. I was setting variables on when I did not have to because the records are related (overkill). I also tried it with setting a calculation to equal it, and it worked, is this a bad way? But this is great, as usual you get it done! Thanks
Like • Show 0 Likes0
Actions
philmodjunk Jul 24, 2014 10:33 AM
Mark Correct
Correct Answer
     It will work as long as the relationship matches to the correct record. Keep in mind that a relationship can be "one to many". Your reference to a field in a related record thus will refer to the "First" related record in such cases and that may not be the correct record.


          I also tried it with setting a calculation and it worked,

     Again, that's a bit vague.

     If you mean you tried using a calculation field or field with an auto-entered calculation, that can also work, but pay attention to the picky details to avoid possible problems. A calculation field will be unstored and unindexed. This means it will always update any time you change the value in the original field--which may or may not be a good thing, but sorts and finds that refer to it will be slower than on an indexed field. And you won't be able to use it as a match field in a relationship in many cases.

     If you used auto-enter (or the looked up value setting), you are copying the data over from the other record just like set field. This gives you a sorted, indexed field which is useful, but the value will not update automatically when the value in the original record is changed. This might or might not be a good thing.
Like • Show 0 Likes0
Actions
ChrisJohnston Jul 24, 2014 10:41 AM
Mark Correct
Correct Answer
Yes... I have experienced that and other things with a "one to many", what you explain here clears up a lot that I have encountered. Invaluable, Thanks!
Like • Show 0 Likes0
Actions

Overkill or not?

Title

Post

Outcomes

Related Content

Recommended Content