Duplicate Portal Data from unrelated Tables

[michael.free]

Hi

 

I've been thinking for a few hours on this problem...

How i can duplicate the hole content of a portal from one layout to a portal on a another layout (unrelated tables)?

 

I have an idea with importing the data, but I would need an abstract of a script showing the different steps.

 

Could anyone help me? Please.

 

Thank you. Greetings from Switzerland (that's not Sweden ;-) )

[Maarten Witberg]

Hi Michael,

 

If I understand correctly, you want to view the same lineitems in "ChildTable" that you're seeing in, say ParentTableA, in ParentTableB? Then there's no need to duplicate the items. You'd need to have a second foreign key field in ChildTable, this time for ParentTableB. The steps would be

 

1- pick the ID key for the record in ParentTableB using $ParentKeyID

2- go to ParentTableA (and make sure you're in the right record)

3- go to related records in ChildTable

4- go to first record

5- set field [ChildTable::ParentKeyB ; $ParentKeyID

6- replace field contents [ChildTable::ParentKeyB ; current contents]

 

But I am curious why you want to do this?

 

kjoe

[michael.free]

Hi Kjoe

 

Thanks for your response.

 

Yes it sounds strange to have 2 tables with the same content.

 

Let me explain the situation:

I have two child tables for the portals. One called "OffersPositions" and the other called "OrdersPosition". I want to be able to switch an existing offer to an order. The offer should still persist. But I must also be able to create an order without having an offer first.

 

So the data in the two child tables would only be the same in the beginning.

 

May be my current design isn't the best...

but if I had only one child table for both offers and orders I wouldn't be able to have the same ids for offers and orders.

e.g create order with id 1, create order with id 2, create offer ---> then the id would be 3 and not start with 1 again (for offers).

 

I will think about it further...

 

but thanks for your input, it helped me to change my point of view.

 

Michael

[Maarten Witberg]

Hi Michael

 

What if you simply put a status field in the offers table? It could read "offer" by auto enter, but through a value list you might change it to "order". I suppose that an offer and an order may have related child records as line items, for instance if an offer consists of multiple products or services. The benefit of keeping the table and changing the status is, that you can make do with just one parent-child set. And you might view them any which way, filtered by status or all together.

The same kind of status field might be applied to the child records, so that a client may say: I want to order this and this from your offer, but not that. And all you have to do is change the status of a few line items and there you go.

But I'm just thinking aloud, as I do not fully know what you're working towards.

 

maarten

[Maarten Witberg]

but if I had only one child table for both offers and orders I wouldn't be able to have the same ids for offers and orders.

e.g create order with id 1, create order with id 2, create offer ---> then the id would be 3 and not start with 1 again (for offers).

 

I forgot to ask: why do you worry about this?

[michael.free]

Good morning Maarten

 

I thought about exact the same thing with a status flag.

But when I change an offer to an order the offer must! still exist with all its original data.

 

Why do I worry about the ids sequence?

Well, I my opinion it's quite logical to have independant ids for offers and orders. I don't like when the system design defines the rules.

Of course if everything else is too complicated to realize then I would concede.

:-)

 

 

Have a nice day.

 

Michael

[Maarten Witberg]

Hi Michael

 

OK I understand. Here's a sample that shows how to duplicate records and selected child items or all child items at once.

 

MichaelFree.fp7

 

Maarten

[michael.free]

Hi Marteen

 

Thanks for your sample database.

I have already solved the problem in very smiliar way.

 

The discussion with you helped me to solve the problem :-)

Talking is the key!

 

Greets Michael