Set Field to Copy Field?

[john12pm]

I need to write a script that will copy the entire field contents from 1 table to another. I need to do this for multiple fields. Can anyone help with the "Set Field" parameters to do this?

Thanks in advance for any help!

John

[Inky Phil]

Hi john

Parameters won't help you here. To set a number of fields you have to issue the same number of script steps.

If you haven't used the 'set field' step before you simply issue the line 'set field' then click the top box (bottom right hand side) which will allow you to select the field that you wish to be set and then click the bottom box in the same corner which will allow you to choose the field from where you wish to get the data.

Don't forget that you can change the list of fields to a related table by clicking at the top of the list

I am afraid that you will have to do that as often as is necessary

HTH

Phil

[Søren Dyhr]

that will copy the entire field contents from 1 table to another.

An honest demand indeed - which many you share with many, but structurally is it wrong unless you have to deal with historic instances, but even THEN would it ...again seen from a structurally point of view be quite overkill.

Take an itemline in an invoice, it belongs to the join table in between Invoice and Items, here is the only 3-4 fields that should get value.

1) foreignkey that tells the record to which invoice it belongs

2) the itemID

3) the historic registration of the price at the point where the invoice is issued

Depending on the technique you create related records in the join table, would 1) often automaticly be given, due to it's location in the invoice 's portal.

2) Is more or less what all depends on, if you set this value to a line, will it trig the reading of 3)

Now an Invoice line will often consiste of many other fields such as itemcount here is it the user that enter how many in the join tables ...but the rest of the values are piped thru the relations and only show up graphicly on demand.

When you wish to print the invoice, it done entirely from the join table, again pulling the values it can get piped in from a relation away to both sides.

So what appears to be a complet record, is in fact only 3-4 values which you, indeed can copy, but often is duplicate just the right command. Because it's added to the end of the list, but "knows" that it belong to a certain invoice and should pull certain values live from items.

Now often is information made by pulling from several tables, but it won't nessersarily demand more fields to be duped, because the structural dependency makes getting values from more than a table away possible.

Your question is indeed a FAQ, and unfortunately is the metaphor behind it structurally wrong, but even so, violated on every single day in the year - because the thinking behind referential integrity is too abstract for some!

But not really ...if you have a shop that allows people reserve some of the items on the shelves, would you then, for each order rush into the workshop behind and make a new copy or would you work with a stock on display, and attatch small stickers to each reserved item?

Refential integrity is about doing things efficiently eventhough you have vast processing power to your disposal, because every single system has it's bottlenecks, and with a fair share filemaker solution is it getting the balances to freshen in a multi user environment and locking other users out of a certain record.

--sd

[john12pm]

Thank you for the advice. I think I am close, however, my script will not copy the fields from Table A to Table B. Here is my script so far:

Go To Layout ["order tracking"(order tracking)]

new record/request

enter browse mode []

set field [order tracking::name; order import::name]

set field [order tracking::PO number; order import::PO number]

set field [order tracking::quantity;order import::quantity]

commit records/requests

Any idea why the records are not being copied from Order Import (Table A) to Order Tracking (Table B )?

Any help would be greatly appreciated!

Thanks in advance.

John

[Søren Dyhr]

Yes the tables are not related, therefore have invisible one of the records no focus. Is it the first record of them all in the table or the current we would like to copy? ...my writhings have apparently not had any effect to the way you reason?

What you try to do could erroneously be done this way:

Set Variable [ $a; Value:Untitled::a ] 

Set Variable [ $b; Value:Untitled:: ] 

Set Variable [ $c; Value:Untitled::c ] 

Go to Layout [ “Untitled 2” (Untitled 2) ] 

New Record/Request 

Set Field [ Untitled 2::a; $a ] 

Set Field [ Untitled 2::; $b ] 

Set Field [ Untitled 2::c; $c ] 

But as such is the concept unhealthy, because what you perform is syncronization instead of changing foreignkeys ...you're creating two instances of the same data, which of the ones turns vinegar first?

Roll up the sleves and learn about relations!

--sd

[john12pm]

I should have mentioned that Table A is just a temporary record until the data is validated by the user. It is deleted every time a new record is (hopefully) imported to Table B (permanent record).

Background:

In Table A users are importing data into about 20 fields. Once they confirm that the data is correct, I want it to be copied to the Table B for continued use. Table A is just 1 record that is used to confirm the fields are correct. Once validated I would like to move it perminantly to Table B.

I am currently doing this with a cut/paste script. However there is a problem in blank fields which are having data from other fields copied into them. I was hoping the 'SET FIELD' function would be a better method to copy the field data over properly. I tried your recommended script, and unfortunatley it does not seem to work either. This seems like it should be easy and it is driving me crazy. help!!!

John

[Søren Dyhr]

Your testing of my suggestion, is not done thoroughly enough, there must something you either neglect or something you take for granted. Is it that the $variables can't be passed inbetween files? If so am I absolutely with Kaschel when he writes:

For years we FMP developers moaned and groaned about having to create a separate file for every table we needed. Complex solutions could quickly run to quite a few files and many, many headaches having to maintain them all. We prayed for the day when an FMP solution could consist of just one file. Finally, with version 7, that day came.

I had no sooner gotten to the ee part of yippee, before some of the folks on some of the FMP discussion lists starting claiming that separate files were “faster”, more stable, better this, better that... there are some people out there who are just not happy if they can’t put a hole in your balloon.

Well, separate files may be faster, I don’t know (and I don’t care), and they may be better this and better that, but they are also one other thing: dumb!

Don’t fall into this silly trap. FileMaker developers have been begging for single file FMP databases for years. They are wonderful, and a great boon to development. Don’t let yourself be bullied into doing things the old-fashioned way for nothing.

Snipped from: http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

I do still think you're having a table too much, because the fact that a user have validated a record just is an attribute that turns data into information, which could be a number field formatted boolean.

Table A is just 1 record that is used to confirm the fields are correct.

Have you considered this single record might be a conflicting issue between simultaneous users, unless you make the fields global. One benefit from using globals is that there is no doubt about focus anymore - since they're privat to each user, and the relation they perhaps are tied to, have no significant importance.

I've toyed with your concept and made a template, exposing various ways to approach the matter ...more as inspiration than a genuine solution to your issue ...because I still doubt the healthiness of the approach of having two tables, for something just being an attribute to the data.

One of the major flaw with my templates idea is that in order to save a few scriptsteps (which I understand could be many with 20+ fields) have I utilized autoentering values from the globals ...this means that you in the user privileges remove the ability to create new records, except when under script control.

Other readers of this thread should beware that the use of tabs in the layout, is only for fm8 and beyond...

Then a bit of advice, eventhough you are struggling with a very specific issue, is the way to get good advice to supply the forum with mission and mission objectives ...instead of matters that doesn't work for you. It takes a great deal of guesswork to establish a diagnosis ...when what you do, is like a small child who in discomfort always points at the belly even though it's the head or the toe that have recieved a blow.

I can easily guess why, it's because you would hate to throw away perhaps work hours of cul de sac ...!

--sd

scratchpad.zip

Edited June 14, 2006 by Guest

[john12pm]

Soren,

Thank you for your in depth response, philosophy, and help. I was able to get the set fields to work using the Set Field/Set Variable script you posted up above. It wasn't working the first time and after closing Filemaker and opening it again it worked. Didn't think that needed to be done for the script to work, but it did. Thanks again!

John

[sbg2]

Why aren't you simply importing the records from Table B to Table A? This also begs the question why aren't the records already in table A with a status field (for example - Validated) which is empty or 0 until the record is validated?