thanks David.
I am using the default DB for testing.
I did try the dummy-fk option and it did not seem to work in this instance.
I used only the two records I included here for testing.
I was not looking to put more code for looping, more passing thru to the db for
processing.
Maybe adding a new parm for passthru. and have that in the parms for the DB.
and a more elegant error message that might inform the Admin that data was to
large for the memory and possibly increase the memory var on startup.
David E. Jones wrote:
Sorting a graph with loops to avoid any constraint breaking is an
NP-hard problem. In other words, there is no perfect solution and there
are cases where even with very complicated efforts there is no guarantee
of a solution.
This is why we have the dummy-fk and other such tools. You might also
try turning on the initially deferred option for foreign key definitions
in your database so that fks are not checked until the first phase of
the commit.
-David
On Feb 24, 2007, at 2:25 PM, BJ Freeman wrote:
I search the Jira but asking here in case I missed something.
when a complete entity export is done.The dependent entities are not
sorted so they are import after the parent Id are. I am not sure at
this point if it is entity specific.
example
<PartyType partyTypeId="Fullfilment" parentTypeId="Suppliers"
lastUpdatedStamp="2006-06-18 02:50:03.697"
lastUpdatedTxStamp="2006-06-18 02:50:03.587" createdStamp="2006-04-10
14:21:32.027" createdTxStamp="2006-04-10 14:21:32.027"/>
is before
<PartyType partyTypeId="Suppliers" hasTable="Y"
lastUpdatedStamp="2006-06-18 02:50:03.737"
lastUpdatedTxStamp="2006-06-18 02:50:03.587" createdStamp="2006-04-10
14:19:13.297" createdTxStamp="2006-04-10 14:19:13.297"/>
so when it imports, there is a error and and the import for the file
is rolled back
