topic Re: Data Transfer MS SQL Direct Access - Error loading timestamp in Move to Qlik Cloud Analytics

Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Tue, 27 Jan 2026 10:45:26 GMT

Hi,

I get the following error:

(Connector error: Status(StatusCode="InvalidArgument", Detail="Input string was not in a correct format."))

I implemented Qlik Direct Access on the on-premise Server. Everything works fine except of the timestamp.
The System is Microsoft Navision with Microsoft SQL.
The format of the timestamp-field is f.e. 000000000265524E.
I can see the field in the load-Manager without any errors:

If I remove the field "timestamp", I can load and store the table without any problems.
Directly on the on-premise-Server I can load the field using Qlikview without any problems.

Any suggestions?

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

NadiaB — Wed, 15 Feb 2023 15:40:09 GMT

Hi @ManuelRühl

By any chance could it be possible to confirm the data type for that column in the table? the field is called timestamp but wanted to double check what is the actual type was set when the table was created, could it be possible to share the details?

Kind Regards.

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Fri, 17 Feb 2023 12:23:27 GMT

The sqlcolumns; command returns this:

SQL Configuration:

Google translate:

Microsoft SQL Server ODBC Driver Version 10.00.17763

Data source name: ***
Data source description:
Server: ***
Database: **
Language: (Default)
Convert characters: Yes
Log long-running queries: No
Protocol Driver Statistics: No
Use country settings: No
Prepared statements option: Delete temporary procedures on disconnect
Use failover server: No
Use ANSI Quotation Marks: Yes
Use ANSI nulls, spaces, and warnings: Yes
Data encryption: no

Hope this helps, tank you! 👍

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

Albert_Candelario — Fri, 17 Feb 2023 21:08:49 GMT

Hello @ManuelRühl,

If you quote the field with the square brackets, does it work?

Please test it and let us know.

Cheers,

Albert

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Tue, 21 Feb 2023 10:17:01 GMT

@Albert_Candelario

Like this?

SELECT [timestamp] FROM *****.dbo."*****$Item"; -> Does not work, same error.

SELECT [No_] FROM *****.dbo."*****$Item"; -> Works

But I want to do this:

SELECT * FROM *****.dbo."*****$Item";

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

Albert_Candelario — Tue, 21 Feb 2023 11:51:23 GMT

Hello @ManuelRühl,

yes, like I we saw in the picture:

SELECT [timestamp],

No_,

and so one.

Can you also confirm you get the issue with that script?

Cheers,

Albert

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Tue, 21 Feb 2023 19:34:10 GMT

@Albert_Candelario

Yes:

Der folgende Fehler ist aufgetreten:

(Connector error: Status(StatusCode="InvalidArgument", Detail="Input string was not in a correct format."))

Der Fehler ist hier aufgetreten:

SELECT [timestamp], "No_" FROM *****.dbo."*****$Item"

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Mon, 06 Mar 2023 08:16:36 GMT

@Albert_Candelario

Any Update on my problem? 😮

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

marcus_sommer — Mon, 06 Mar 2023 09:15:22 GMT

I suggest to try to exclude potential causes, for example just to rename the column, maybe to _Zeitstempel_ to exclude that timestamp is a reserved term and/or also a variable/routine/table-name and/or treated as function-call. A direct renaming within the query or in the table might be not sufficient/sensible but the column or the table might be duplicated.

Another way may be to create a new table just with such timestamp column (with this name and also another one) and a few definitely valid values. The same checks like above mentioned would be possible and also that further properties on the column and/or any invalid values breaks the query by returning a misleading error-message.

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

Albert_Candelario — Mon, 06 Mar 2023 09:36:54 GMT

Thanks @marcus_sommer for sharing your insight.

Cheers,

Albert

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Tue, 07 Mar 2023 06:15:40 GMT

Thanks @marcus_sommer for replying. The timestamp field exists in nearly every table. I don't need it. If I create new tables within the database I will have to update them as well when something changes. My solution will be to do this within the Qlik script.

But: I had the possibility to check with another Navision-System (Newer version, Business Central).

Same Item-Table, same timestamp field: works perfectly. 🤷‍♂️

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

marcus_sommer — Tue, 07 Mar 2023 07:25:21 GMT

My suggestion wasn't meant as solution else to find the real cause behind the error. That's working with a newer data-base is a good sign and may already exclude one cause - if the identically driver with the identically configuration is used. If it's a different driver you could try for a test to use the other driver with the newer navision-version.

If this worked, too the driver isn't the problem and reverse if not you would have found the cause. If it's the driver you could try to use the newer one also against the elder system and/or an investigation to the differences of both drivers/configurations - newer data-types, 32bit vs. 64bit, ...

If not the driver is the issue you need to investigate the matter within the data-base. Helpful for it may be to reduce the data-set of query to just a single record which has definitely a valid timestamp-value to exclude invalid data as cause. Further if nearly all tables have such timestamp-fields - what happens by loading the timestamp from there? Each time the same error or does some be working? If any timestamp-query is working it exclude the previous mentioned things of reserved terms and/or variable/procedure-names and you have something to investigate the differences between these tables/fields.

The last relates to look on the real stored values in these fields because the data-base UI may not mandatory show the absolute truth else any converted/formatted/decrypted version of it. Also the properties of the tables/fields may have an impact like no-read-rights or encryption/hashing, ... In this regard a test with another user may also helpful.

If it happens only to this table and/or just a few the worst case of a corrupt table might be also considered. Beside all of above I think the solution must be found within data-base/driver because Qlik doesn't execute any SQL else transferred only the query-statement and get back a result data-set.

ps: just take a look if a variable timestamp exists within the Qlik application ...

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

NadiaB — Tue, 04 Apr 2023 14:03:06 GMT

Hi @ManuelRühl

The underlaying issue is that timestamp is an unsupported data type:

https://help.qlik.com/en-US/connectors/Subsystems/ODBC_connector_help/Content/Connectors_ODBC/SQLServer/SQL-Server-connector.htm#anchor-3

We have seen different issues where the reload works on prem and not in QCS, same thing will happen if you try to load varbinary , it will wok on-prem and not in QCS where it will error out.

We have heard from our R&D team that although it might work in on-prem as the data type is not listed in the supported data types is not expected to work.

It is suggested to file a Feature Request to support timestamp data type.

Hope it helps !

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Fri, 14 Apr 2023 06:27:14 GMT

@NadiaB

Thanks for investigating this issue.

But i can access timestamp-fields of another Navision System without any problems.

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

ManuelRühl — Wed, 17 May 2023 11:25:18 GMT

I don't know what happend, but now it works perfectly.
Maybe there was an update of the connector?

Re: Data Transfer MS SQL Direct Access - Error loading timestamp

Albert_Candelario — Thu, 18 May 2023 04:46:41 GMT

Thanks for letting us know!