new record portal to portal

[George Swisher]

I have a database with a layout that has 2 portals. We will call this db A, with related db B (portal and db C (portal C).

I am trying to create records in portal C from data in portal B. Here is the script I have. I can get one record to be created correctly but can not get past that first one.

I have a button for each record in portal B that performs:

Go to Portal Row [select, "db C::field A"]

Set Field ["db C::field B", db B::field B"]

...and there are a few other set field lines.

My problem is that I can not create a second record regardless of how I try to set the Go to Record function or Go to Portal Row. The first one is fine, but I need to be able to do this multiple times and always want the button for the portal B fields to go to the next row in portal C to create a new record on portal C. Everytime I add the Go to Record command to create new record, it does the function in db A.

any suggestions?

[Søren Dyhr]

At first hand odes it seem like you have forgotten to turn on allow creation of related records via the portal to db A.

Now thats the pure tecnical issue, which it might suffer from - another thing is the structural considerations behind. An ideal when dealing with relational database is to keep data one single spot, and made it referenced if needed elsewhere, unless you try to reflect a historical event/circumstance.

For instance registrations of orders in a turbulent environment where prices changes or go out of stock now and then, a good candidate for such an approach, but usually handled by lookups.

It could also be sets of coherent items, you wish to enter in one blow, say a collection of parts that makes an engine assembled.

This can be handled this way:

http://www.dwdataconcepts.com/dl/tm/Compile_INV2.sit

--sd

[George Swisher]

I may have mis-written this in the other post but I am able to create the first record (using db A layout with portals B and C) from information contained in fields from portal B to portal C.

I should have also specified that I am using FM 5.5, the reason for the related files vs tables. I am converting to 8 over the next month but trying to figure this function out before I move everything into one db with tables. Which I am more comfortable using beceause I derived my db knowledge from ACCESS but enjoy FM better.

So, I have the allow records for each relationship and portal. I am able to create the first record successfully, I just have a problem creating the second record in portal C. The reason for the portals is that db A is the main db for storing job ticket records with a JOB NUMBER. That job number is the basis of all shared db's and I need to create POs (db B and portal : and ORDERS (db C and portal C) that are related to db A JOB NUMBERS. I have the other related db's working as tables to store the data because there are multiple POs and ORDERS for each record in db A JOB NUMBERS. The ORDERS (portal C) are created in reference to PO's (portal and need to view both at the same time and they share data like AMOUNT, etc.

Thought the overview might help in trying to resolve this. So again, when I am in db A's layout that has portal B and C, I click the button (that is a button for each record in the portal layout) on the first record and it does create the first record I need iin portal C. The problem is that when I go to the seconf record in portal B and click the button (to create the related record in portal C, just like I already did on the first record) It does not create the record in portal C. It seems like it goes to the next record in portal C but does not create a new record and carry the data from portal B.

Sorry if that was long but i really need to get this resolved if I can or create another solution.

thanks for the help!

[Søren Dyhr]

Although I hardly ever endorse generation of related records through a portal can it be done this way - investigate the template!

--sd

portaltransfer.zip

[George Swisher]

I agree but it is the limitation I have the 5.5 now. This, I am sure, will be better once I go to v8 and the use of tables vs. related db as tables.

Thanks for the help and I will take a look at what you sent.

[Søren Dyhr]

This, I am sure, will be better once I go to v8 and the use of tables vs. related db as tables.

I wouldn't say that radical changes have been introduced, ever since fm3 have the opertunity to do it outside the portal existed, but $variables in being multi dimentioned to cover all fields involved in one blow, have made it easier seen from a scripting view.

But what if we made both portals the same file/table, all it would take then is a duplicate record and change the foreingkey in it.

I've made a yet another template showing this, the gain with it is that using the interface takes time, so why bother when it isn't nessersary.

There is one snag to though, the autoID'ing of the main record shouldn't collide with the constant relations keyfield, since it here is one and the first autoID is 2 are we here safe, but we could change the ID'ing scheme into say text with a prefix, or make the constant a letter in text format.

--sd

Transfere2.zip