Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
fosuzuki
Partner - Specialist III
Partner - Specialist III

SAP Connector migration error

Hello everyone,

We are trying to upgrade the SAP Connector from v6.0 to v6.2 (could be v6.3 but we heard that it has some bugs...), but we noticed that some fields, that once were interpreted as numbers, are now being interpreted as texts.

We discovered that starting from v6.1, Qlik has modified the behavior of the query engine and the resulting dataset: "The SAP data types CHAR (character) and NUMC (numeric character) were previously interpreted (in the Qlik script) as ‘numeric’ if they contained only digits. Leading zeroes were removed. (0000141000 became 141000). Now they are always interpreted as ‘text’. Leading zeroes are kept. These data types are not often used in calculations, but if they are the new behavior might require script changes since calculations expects numeric values" (extracted from Release Notes v6.1).

I've attached a QVW comparing the resulting QVDs from VBAP table. The production environment is on v6.0 and test on v6.2.

We have a big 3-tier (extraction, transformation and viz apps) environment, and until now identified two options:

1. Isolate the solution in the extract layer, applying the number interpretation function in the sql queries so that the resulting QVDs remain the same as the old QVDs from v6.0: we consider this as a workaround, but easier to measure the effort. All the new queries would have to have this interpretation workaround to match with the rest of the data.

2. Assume that the query results are now "correct", and adjust all the transform and viz apps tiers to reflect this change: this option is "cleaner" (conceptually there would be no workaround involved), but more difficult to measure the effort. Probably we would have to do this by trial and error, adjusting the problems as they are identified.

Now we have to decide which way to go.

Can you share your thoughts? Any help appreciated.

Thanks in advance

Fernando Suzuki

1 Solution

Accepted Solutions
Anonymous
Not applicable

Hi Fernando,

I suggest that you wait for the 6.3.2 release of the SAP Connectors. It is planned to be released this week. The new version has two new flags that can be used to maintain compatibility with load scripts developed before version 6.1 of the connectors.

The following description is from the release notes:

MixedMode (0 or false / 1 or true. Default/off = 0 or false.)

When MixedMode is enabled, the NUMC and CHAR data types are sent as UNKNOWN instead of ASCII, and it is up to Qlik to decide what their content is. A numeric string with a maximum length of 14 characters will be interpreted as numeric in Qlik (the same behavior as in the legacy connector).

NulldateLegacy (0 or false / 1 or true. Default/off = 0 or false.)

When NulldateLegacy is enabled, the property Nulldate behaves as it did in the legacy connector, returning an empty value when Nulldate is enabled and returning "0000-00-00" when Nulldate is disabled.

When NulldateLegacy is disabled, null is returned when Nulldate is enabled and 0 (displays as 1899-12-30) is returned when Nulldate is disabled.

It is recommended that you do not use NulldateLegacy for new development.

Best regards,

Daniel Martinsson

View solution in original post

7 Replies
Anonymous
Not applicable

Hi Fernando,

I suggest that you wait for the 6.3.2 release of the SAP Connectors. It is planned to be released this week. The new version has two new flags that can be used to maintain compatibility with load scripts developed before version 6.1 of the connectors.

The following description is from the release notes:

MixedMode (0 or false / 1 or true. Default/off = 0 or false.)

When MixedMode is enabled, the NUMC and CHAR data types are sent as UNKNOWN instead of ASCII, and it is up to Qlik to decide what their content is. A numeric string with a maximum length of 14 characters will be interpreted as numeric in Qlik (the same behavior as in the legacy connector).

NulldateLegacy (0 or false / 1 or true. Default/off = 0 or false.)

When NulldateLegacy is enabled, the property Nulldate behaves as it did in the legacy connector, returning an empty value when Nulldate is enabled and returning "0000-00-00" when Nulldate is disabled.

When NulldateLegacy is disabled, null is returned when Nulldate is enabled and 0 (displays as 1899-12-30) is returned when Nulldate is disabled.

It is recommended that you do not use NulldateLegacy for new development.

Best regards,

Daniel Martinsson

fosuzuki
Partner - Specialist III
Partner - Specialist III
Author

Wow Daniel, this is excellent!!

I was really wondering why Qlik didn't put a 'legacy mode' to maintain this compatibility...

Thank you for the info.

Regards

Fernando Suzuki

Anonymous
Not applicable

Hi Fernando.

Did you solve the issue? How did you set the parameters to get the previous SAP field interpretation? Thanks for your answer.

Kind regards

David

fabio_ribeiro
Partner - Creator
Partner - Creator

Hi David.

Yes a version 6.3.2 solved this issue.

In connection string you must put follow parameters:

MixedMode=1


NulldateLegacy=1 (com este parametro data null ficará 0000-00-00)

Anonymous
Not applicable

Thanks Fabio

I tried these parameters with 6.4 - it still gave me the wrong date field formats.

Qlik released Connector version 6.5. There the wrong date field formats have been corrected.

NulldateLegacy now works as wished, before version 6.5 date fields were interpreted as text, which was a different behavior.

Relaease Notes:

"NulldateLegacy: Now sends the data type DATS values as DUAL's as in the legacy SQL connector."

Kind regards

David

Anonymous
Not applicable

Hello All,

How do you upgrade the connector ?

Do you uninstall  the previous connector and install the latest version ?

Any advise on it ?

Thanks,

Nisha

fabio_ribeiro
Partner - Creator
Partner - Creator

First Step - Deploy new transports on SAP.

Remember that transport must be installed according to the SAP version.
For each K file (headers) it has an R (request) file. Example:
KXXXXXXX.E6D
RXXXXXXX.E6D


Watch out for the SAP version and if you will use BEX, according to this information the order of the files may change.


After deploy all transports required, remove old version and install newwer version.


Do not forget to see all the comments made above to build the new connection string. Depending on the old version you have installed, you may need to use some of the parameters.