CDT Write to Data Store error: primary key "doesn't have a default value"

I created a CDT mapped to a data store entity with an auto-generated primary key (field name = "id").  I have a process that inserts one new instance of the CDT each time it runs.  The first two executions created two entries in the data store as expected.  The third and subsequent tries failed to insert, and produced this error message:

Details:  An error occurred while trying to write to the entity “CB_PWDBW” [id=b20cef01-aa95-4382-84eb-14de73b1a967@4057, type=CB_PWDBW (id=2778)] (data store: CB Data Store). Details: org.hibernate.exception.GenericJDBCException: could not insert: [CBPWDBWDT1716]: java.sql.SQLException: Field 'id' doesn't have a default value Data: TypedValue[it=2778,v={Bainwright Corporation,9998887776665,1,1,0,0,1,{,Chicago,IL,,USA,},<null>}]

I'm puzzled by this error, as the field"id" is defined as a primary key, with the auto-generate option checked:

Any help would be appreciated.

  Discussion posts and replies are publicly visible

Parents
  • Hi petef,

    how did you configured the id column in your CDT?

    check the table structure in database whether the id column is primary key or not.

    if everything looks fine then drop the table and create again by save and publishing the data store.
  • Bhanu, Venkat, all--thanks for the pointers. I figured out what the problem was. The revelation to me was that I could use the Runtime Data engine to view and even modify all of the tables in my database. Once I had that visibility into what my CDTs were becoming in the (SQL) database, it was clear what I needed to fix. I had created some nested CDTs with the wrong type of foreign key relationships. When you have nested CDTs simply to encapsulate details, such as an address CDT that is within a customer CDT, it should be set up with a One-To-One relationship, and only the "Updates to a parent value should also update the associated child values" box checked.
Reply
  • Bhanu, Venkat, all--thanks for the pointers. I figured out what the problem was. The revelation to me was that I could use the Runtime Data engine to view and even modify all of the tables in my database. Once I had that visibility into what my CDTs were becoming in the (SQL) database, it was clear what I needed to fix. I had created some nested CDTs with the wrong type of foreign key relationships. When you have nested CDTs simply to encapsulate details, such as an address CDT that is within a customer CDT, it should be set up with a One-To-One relationship, and only the "Updates to a parent value should also update the associated child values" box checked.
Children
No Data