We have been using LLBLGen for a few release cycles now. Currently version 2.6; adapter.

Our product supports both SQLServer and Oracle. During our QA process we have a need to clone our SQLServer database on Oracle. I've been reading various post utilizing the serialization trick and the "ResetEntityAsNew". I implemented a CloneHelper class and have that working except for the primary key.

During debug, just before save, I can see that the Entity value of the PK field is that of the original (SQLServer) entity as expected. After the save the value in the new (Oracle) database is from the trigger / auto sequence. I suspect the query is omitting the PK field.

Is there a solution to this issue?

Regards

Hi Barry,

If you have a trigger-based sequence in Oracle, you can't disable it at LLBLGen Designer or at code, because that is in your database.

Now, if you don't have a sequence for that field in your database but you do see that LLBLGen is treating the field as an identity, you can disable it in LLBLGen designer by uncheck the "Is Identity" for that field.

Unless you are doing something very special in your migration process, I would recommend do this migration DB2DB directly, like a DTS or a migration tool. The reason is that you may need to enable/disable some things like identity, FK checks, etc.

Actually, you can notify the DQE that you use trigger based sequences, but it's a global setting (so it will assume all sequences are set by triggers).

See: Application configuration through config files

As a test I unchecked "Is Identy / Sequence field" for the PK in the LLBLGen Project. This resulted in a Insert Query with the PK field omitted.

What is the configuration that would result with the Insert query containing the PK?

Did you set a value for the Identity column before you did the insert ? Could you show us the code you are using?

I'd re-iterate David's point that, as good as LLBLGen is, there are some jobs where it is not the best tool to use, and this is one of them. You're trying to bend the framework to do something it's not really designed for.

I'd be looking at SQL integration services myself, the SQL 2008 version is very powerful and flexible.

Matt

Re-reading the original question, indeed integration services on sql server is likely your best bet. It used to be sub-par but it is pretty ok today. With it you can stream your sqlserver data to another database, do transformations along the way. This way you can quickly clone the DB. As it in some cases is able to bypass SQL pipelines it also can be faster as well