My project is using XData, Aurelius and Azure VM with access to Azure SQL server via a Private Link. When I run my XData server on my local computer, everything works fine (it is accessing the Azure SQL server). When I run my XData server in an Azure VM, everything works (creates the data table, can list records from the data table) except when inserting a record I receive an error:
raised exception class EXDataGetRequestException with message 'XData server request error.
Status Code: 500
Error Code: AureliusOdbcException
Error -1: [Microsoft][ODBC SQL Server Driver]Invalid precision value'.
The AureliusConnection is using the native driver for MSSQL. Do I need to install something, like a driver, in the Azure VM?
At first I thought this had something to do with some of the fields in my table, like nvarchar(max). I changed all of those to nvarchar(100) and I still receive the same error.
I have not installed (and am not aware of) ODBC anything on my local computer or in the Azure VM. I was surprised to the "ODBC" in the error message.
In the connection setup, should the parameters called MARS, OdbcAdvanced need to have values?
I have several memo fields in my table. For test purposes I have reduced the size down to 100 characters (Unicode). With the same issues. I'm sure the answer is a simple one.
I think I'll try switching the AureliusConnection to use an Adapter to see if that works. Or maybe switch DBs to ElevateDB (I already know that works). I was just hoping to use Azure SQL for this project.
Well, you stated it works when running from your Dev machine so, not a problem using Aurelius with Azure SQL.
This error is usually reported for one of 2 reasons: trying to insert on varchar(max) fields with older ODBC driver versions that do not support it or while using newer ODBC versions, do not correcly set the size property (length) of varchar fields.
I guess the Aurelius MS Sql Native Driver is tested against some ODBC versions. You may find usefull to check this other thread with a similar problem (issues with ODBC):
Sorry I don't have a more straightforward solution. TMS support you certainly point you in the right direction.