@patrick I still get the following error in the local Web Server Console on executing the Server Action:
App listening at http://localhost:3000
server-connect:router Serving serverConnect /api/1/1/domusNavi/aktivitaeten/listAktivitaeten +0ms
tedious deprecated The default value for `config.options.enableArithAbort` will change from `false` to `true` in the next major version of `tedious`. Set the value to `true` or `false` explicitly to silence this message. node_modules/mssql/lib/tedious/connection-pool.js:61:23
(node:1712) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
.returning() is not supported by mysql and will not have any effect.
The Server Action does work though. Is this something to worry about or can I ignore it?
At this moment these are just warnings, not errors.
The deprecation warning was added in NodeJS 12 and warns when you use an IP address for a TLS connection, you should update it to a valid hostname to ensure it will work in the future.
The second warning is that returning is not supported by mysql, this is something that was added to support postgres. As the warning tells, it won’t have any effect on mysql.
Will see if we can prevent the returning warning for mysql. The TLS warning is not something I can do something about. The tedious deprecation warning would probably be fixed in an update, but for that we depend on 3rd party updates.
You can test the following update, should prevent the returning() warning. Place in lib/core.
db.zip (1.2 KB)
@patrick I found a new problem with converting the UTC Time.
The following date is converted as follows with formatDate(‘yyyy-MM-dd HH:mm:ss.v’):
2021-03-28T17:30:46.003Z => 2021-03-28 19:30:46.3
The leading 00 on the milliseconds are missing. There must be bug in the formatter in case there are leading zeros.
Could you please check this?
Sorry to have another question on this topic 
I found out that there is a rounding difference with milliseconds in MS SQL.
In my MS SQL database I have the following date:
If I create a query with the condition of the changed date I get a wrong result. It does work though in MySQL:
{"var_date":"2021-03-30 17:06:33.066","q_mssql_date":{"Changed":"2021-03-30T17:06:33.067Z"},"q_mysql_date":{"Changed":"2021-03-30T15:06:33.066Z"}}
In this case I have a difference of 1 millisecond. It seems like that the problem only occurs if there is a 6 at the end.
Is this a problem with knex?
I also tested the Custom Query, but I get the same result:
@patrick did you find the reason for the wrong query result in MS SQL?
I know that it is only 1 millisecond, but I use the query for a import in my MySQL database and the data in both databases is not identical because of that.
I actually have no idea why that would be different.
it does only occur with MS SQL and a 6 at the end of the milliseconds. The same query in Navicat gives the correct result.
Could you reproduce it, or is it only on my side?
It is probably a rounding error in JavaScript, the floats aren’t very precise. Try typing 0.1+0.2 in the browser console, it will result in 0.30000000000000004. There is not much I can do for these kind of errors. If it is not that then it would be a bug in the mssql driver that knex is using, but it is just strange that it only occurs with a 6 at the end.
I think it is an issue with the driver, there seems to be multiple issues with rounding problems with milliseconds https://github.com/tediousjs/tedious/issues/391
It is definitely the Tedious driver, it rounds the time incorrectly. Is seems that mssql also rounds the miliseconds to .000, .003 and .007 milliseconds. There is a bug in Tedious that it does round the numbers not to .007 but to .006.
https://database.guide/datetime-vs-datetime2-in-sql-server-whats-the-difference/
Thanks a lot for your research. Do you know if there is a chance that the bug from the tedious driver is eliminated?