---

 Comments

---

There were two issues here:

1) The loading of the updates would hang during the dependency calculation phase where ElevateDB was trying to determine the proper loading order of the tables, and the tables had circular foreign key/primary key dependencies where:

Table A -> Table B -> Table C -> Table A

2) There was a more general problem with the approach to the loading taken by ElevateDB. Even with the fix to the dependency calculations, the loading logic was wrong for certain sequences of operations, and would result in constraint errors on the target database. One of these loading sequences was (assume FK constraint on Detail that refers to the PK in Master):

Add Master row with ID #1
Add Master row with ID #2
Add Detail row with Master FK ID #1
Update Detail row with Master FK ID #2
Delete Master row with ID #1

In the above scenario under 2.04 and lower, ElevateDB would try to load all of the Master updates first, and then the Detail updates first. This is fine in most cases where primary keys are not modified or deleted in the Master updates. But if such updates do occur, then ElevateDB would be unable to successfully load the updates.

---

 Resolution

---

Fixed Problem on 11/26/2010 in version 2.05 build 1

---

 Products Affected

---

ElevateDB Additional Software and Utilities
ElevateDB DAC Client-Server
ElevateDB DAC Client-Server with Source
ElevateDB DAC Standard
ElevateDB DAC Standard with Source
ElevateDB DAC Trial
ElevateDB LCL Standard with Source
ElevateDB PHP Standard
ElevateDB PHP Standard with Source
ElevateDB PHP Trial
ElevateDB VCL Client-Server
ElevateDB VCL Client-Server with Source
ElevateDB VCL Standard
ElevateDB VCL Standard with Source
ElevateDB VCL Trial