Hi Everybody,
Has anyone had success implementing data synced record types on database tables that use GUID unique identifier as database fields?
In one of our example tables the primary key uses unique identifier. I can configure the data synced record type and perform full sync with the record. But when I use the Write Record smart service I get the following error.
Unable to write to the source due to system error.Error Details: The generated key type is not supported. Unable to cast [null] to [java.lang.Number].
Workarounds involve using the Query Database smart service to execute SQL Statement for inserting then running the Sync Records service. But I feel like we are losing value having to resort to Query Database smart service.
Asking the community if there were any success stories using unique identifier data type with their data sync record types.
Thanks In Advance
Discussion posts and replies are publicly visible
Did you try this: docs.appian.com/.../configure-record-data-source.html
Thank you for your suggestion Stefan. I should have mentioned that we are using Microsoft SQL Server as our database. The option to use a sequence for primary key generation isn't available.
Sequence for primary key generation is available. Have I misunderstood what you meant?
The MS SQL Server uses the IDENTITY keyword to perform an auto-increment feature. In the example above, the starting value for IDENTITY is 1, and it will increment by 1 for each new record. Tip: To specify that the "Personid" column should start at value 10 and increment by 5, change it to IDENTITY(10,5) .
Hi Stewart,
For our Primary Key we use unique identifier datatype instead of int.
I understand this is still possible with the same concept:
www.mssqltips.com/.../
Note that the article suggests using GUIDs is not optimal and that you'd be better of with sequential integer values.
Thank you Stewart for sharing the articles. We use sequential integer for our new database object but our legacy tables were originally built with uniqueidentifier many years ago and are part of a wider system of applications. The work effort to convert all these systems is out of scope for us to perform.