-
1. Re: Overkill or not?
Why do you need to archive this data in the first place? What issue does this solve for you?
-
2. Re: Overkill or not?
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
-
3. Re: Overkill or not?
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.
-
4. Re: Overkill or not?
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
-
5. Re: Overkill or not?
I don't think that I understood you original description of the issue and am not sure that I do now.
-
6. Re: Overkill or not?
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!
-
7. Re: Overkill or not?
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.)
-
8. Re: Overkill or not?
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
-
9. Re: Overkill or not?
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.
-
10. Re: Overkill or not?
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!