Transfer Project to .EAP and Compaction

[Paolo F Cantoni]

If you use the Transfer Project functionality to transfer from a SQL Server to an EAP file, the to make sure that you don't run into surrogate key problems adding any new items, you HAVE to do a Compact afterwards.  Thereafter all is fine.

Is there any rationale for NOT doing a compact as a matter of course following the Project Transfer?  If not, I'll pop in a Bug report.

TIA,
Paolo

[PeterHeintz]

Hi Paulo,
What is that surrogate key problem? I currently transfer without compacting (used read only).
I just want to know if I have to take care of something.

[Paolo F Cantoni]

Hi Paulo,
What is that surrogate key problem? I currently transfer without compacting (used read only).
I just want to know if I have to take care of something.

Hi Peter,

I'm not exactly sure what the exact problem is.  I have some ideas.  However it is IMPORTANT to understand that if you ONLY use the copy for read-only access you WON'T see the problem.

My guess is that when the transfer occurrs, because of the different underlying DB technologies (SQL Server vs JET 4.x), the last surrogate key used (Object_ID etc) is not reset properly.  So when you try to add a new item, there is a surrogate key clash with an existing object.  Compacting will reset the IDs to the last available.

We (as I have noted before) make clones often and I occasionally use them to add new items (for testing otr other purposes).  IF I REMEMBER to compact before I use it, then all is fine.  Otherwise, I'm (almost) guaranteed to create a clash.

Hence, why I believe the compaction should be part of the transfer (at least an optional switch on the dialog).

HTH,
Paolo

[PeterHeintz]

Ok! Thank you!
So we will compact our DB's in future as well, just to save for not jet known situations.

[Paolo F Cantoni]

See: Reset IDs... TAKE EXTRA CARE! for a related problem with Transfer Project to Server based DBMSs.

Paolo