TOPIC:

Greetings,

I have run into an issue that I finally resolved, but only after a bunch of newbie experimenting.

I was going from CSV to SQLite3

I setup all my fields and setup a AUTO_INCREMENT as the first field. I then selected the Document Number
as a Primary Key. Turns out the Document Number was not unique. I got a UNIQUE ... Constraint Violation on
the Document Number field. I de-selected that as Primary Key and when I went to run the transformation again
I got the same error. So I went to remove the O/P DB (I was creating a new DB from scratch) and found I had to
Shutdown the Studio (see other post regarding that) and fired up Studio and when to run Transformation again.
I still got the error (UNIQUE ... Constraint Violation). I made the Auto_Increment the Primary and it ran.

It would appear that even though I removed the original Primary Key setting and the UI showed that it was cleared
that something was not getting reset properly in the in FH config file.

Through changing I got it to work BUT by the time I figured I should document this, the trail was gone. You might want
to see if you see anyway this can happen for correction in a future version.

Regards,
Keith

Hi Keith,

I´m not sure whether I understand you correctly.

I mean that´s not a bug/issue because if you switch the “Primary Key” or “Auto Increment” option in a FlowHeater Definition, FlowHeater does not change the underlying table schema. Only in the SQLite Adapter these options are using once in case the SQLite table should be created.

Note: Only the SQLite Adapter does currently support the feature to create not existing tables before importing.

If the table already exist these option are only using for information purpose (e.g. Auto Increment) or find some possible records for updating. In special cases with this you can tell the database Adapter do not use the tabled based primary key for updating just use the in the Definition defined Primary Key fields.