Hi Guys,
I created a process model which let the user inserts his information then save them to the database, it worked fine, but doesn't save the data to the database. When I did refresh I got this.
Discussion posts and replies are publicly visible
Hi,Can you please share what the error message reads?
An error occurred in executing an Activity Class.
Details: An error occurred while trying to write to the entity "Employee_DB" [id=f3650a76-b78b-4f7b-a711-d3d7efd05e08@4093, type=ES_Employee (id=4016)] (data store: ES_Employee_DS). Details: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): ESEmployeeDT6506 Data: TypedValue[it=4016,v={Ali,<null>,AA@gmail.com,05347384882,Low-Code Team}]
Recommended Action: Examine the activity class to correct the error and then resume.
I got this on my email.
Can you please share what data are you trying to save.you can go to process details>variables and then find the variable that you're using to write data to the database.
[Emp_ID=, Emp_Name=Ali, Email=AB@gmail.com, PhoneNO=112525, Department=IT]
those the data I tried to save into the database.
If you're still getting the same error then either your DB table or your CDT are not configured properly for auto-incrementing primary key. Just in case, also, you should try a new process instance, as i think re-starting the failed node in the existing process instance might still be trying to use the old version of your CDT assuming it was updated.
Emp_Id is Blank.
I made it auto generated.
I made new process model, but still the same thing.
I already configured the id as the primary key.
Pls, share the structure of the database table
here's the structure of the database table.
Please share the CDT structure as well along with the primary key pop-up.
Based on your screenshot, your primary key column, "empid", is not configured for auto-increment. As I noted before, this is required for your case.
This is what it looks like when the column is properly configured in this regard:
Hi everyone!
I seem to stumble upon the same problem as Ali, and I have configured my CDT to have a primary key and auto increment since the start of creating a new process model. The error specifically "An error occurred while trying to write to the entity "CDThouseauction" [id=fb4a1477-ec44-4115-992e-67516aaaf0d8@5304, type=AP_CDTAuctionHouse (id=4230)] (data store: AP AuctionBidDSE). Details: org.hibernate.id.IdentifierGenerationException: unrecognized id type : double -> java.lang.Double Data: TypedValue[it=4230,v={23456.0,<null>,8,,,<null>,,,,}]"
I've tried re creating the CDT since I fiddled with the last CDT trying to change the primary key. I made sure to adjust the rule inputs I had previously as well. Yet my related actions are still struggling to send the input to the cloud database.
Unlike the previous person I responded to, your table does look to have a correctly-configured auto_increment PKID column. Except why is its type "double"? Generally that should be int(11) just like your subsequent ID columns. Additionally the associated type for that column should be "integer" in your CDT definition. I'm not sure an auto-incrementing integer ID field can work right if it's not set as Integer.
Hi Mike,
I was mostly suspicious of the houseBid being a double after reading the error a couple of times. In my CDT it is referred to integer and when looking at the cloud database its double. I believe it takes houseBid as an amount that is being bid on and therefore doesn't default it to an integer. My overall problems seem to have been solved by recreating the CDT and using bidId as the primary key, and bidAmount as integers and other fields. Can't personally understand why it defaulted to Double in the cloud database outside of it being an auto language detection thing.
aaron.li said:I believe it takes houseBid as an amount that is being bid on and therefore doesn't default it to an integer.
that would be a strange thing to set as a primary key id field, then.
i'm a little unclear here whether you created the DB table then the CDT based on it, or the other way around - but if you create the CDT first, you'd need to make the PKID field Integer type. If you create the DB table first, you'd need to use int(11) type. "Double" is merely the DB-side type for the Appian data type of "decimal" as seen in your screenshot. (I know you might know these things already, but adding just in case clarificaiton is needed.)
Either way, at the end of the day, it seems as if something was not set correctly at creation time. I hope you have it working now as hinted by your reply.
Thank you for the clarification, its very much appreciated for my understanding. You are in fact right that I made the mistake of using the PK the for the houseBid which in my mind was supposed to be the Bid Amount hence the decimal type. Therefore it's now obvious why it made it a Double because it was a decimal type chosen by myself... Unclear setting up as to what fields I actually wanted which I've now done correctly which for anyone reading this in the future:
bidId (Int) (PK)
bidAmount (int)
other fields etc.
Thanks, I edited from the database, and it worked, but when the user inserts his information, it creates two copies into the database. is it because the process model or what?
this is probably due to something incorrectly configured in your Write to DSE node. It's hard to tell exactly what that might be though - can you post a screenshot of the data tab configuration of that node?
What does the process instance data look like after the node is run? What does the DB-side row duplication look like? Can you verify that there aren't 2 proecss instances being launched at the same time by accident somehow?
As a side note, though this likely isn't related to your particular issue, you don't want to have the "saveInto" set in the Data Input tab - the value that gets saved back into the PV from that configuration will *not* have the created primary key populated.
Mike Schmitt said:Can you verify that there aren't 2 proecss instance
Actually it does, but I don't know why