Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Salesforce origin, offset converted to scientific notation

When using a numeric filed as offset which is longer than 8 digits, decimal 13 to be exact, it seems that Salesforce is providing the offset in scientific notation.

During the initial execution of the query, using the init offset, the new offset returned by the SOQL gets stored in scientific notation, but this format is not usable as offset in the where condition for repeating queries anymore. The scientific notation causes an exception on Salesforce side during execution.

1526394852000 => 1.526394852000E12

Although the number is shown correctly when using the preview function as well as in the Salesforce developer console, it seems it gets delivered in scientific notation by SOQL without a chance to influence that.

Currently I'm not sure if that is a bug/issue and how to address this.

We were thinking of several workarounds and tried quite some stuff to overcome that issue using text fields, format() with alias on SOQL, using Streamsets functions (str:, math: these only seems to be accounted in input fields not in the query itself) all without success.

The only thing that worked was directly changing the source of the salesforce_lib to convert the offset back in the desired format.

If needed I can provide logfiles & configuration or file an issue if necessary.

Best regards Peter

Salesforce origin, offset converted to scientific notation

When using a numeric filed as offset which is longer than 8 digits, decimal 13 to be exact, it seems that Salesforce is providing the offset in scientific notation.

During the initial execution of the query, using the init offset, the new offset returned by the SOQL gets stored in scientific notation, but this format is not usable as offset in the where condition for repeating queries anymore. The scientific notation causes an exception on Salesforce side during execution.

1526394852000 => 1.526394852000E12

Although the number is shown correctly when using the preview function as well as in the Salesforce developer console, it seems it gets delivered in scientific notation by SOQL without a chance to influence that.

Currently I'm not sure if that is a bug/issue and how to address this.

We were thinking of several workarounds and tried quite some stuff to overcome that issue using text fields, format() with alias on SOQL, using Streamsets functions (str:, math: these only seems to be accounted in input fields not in the query itself) all without success.

The only thing that worked was directly changing the source of the salesforce_lib to convert the offset back in the desired format.

If needed I can provide logfiles & configuration or file an issue if necessary.

Best regards Peter

Salesforce origin, offset converted to in scientific notation

When using a numeric filed as offset which is longer than 8 digits, decimal 13 to be exact, it seems that Salesforce is providing the offset in scientific notation.

During the initial execution of the query, using the init offset, the new offset returned by the SOQL gets stored in scientific notation, but this format is not usable as offset in the where condition for repeating queries anymore. The scientific notation causes an exception on Salesforce side during execution.

1526394852000 => 1.526394852000E12

Although the number is shown correctly when using the preview function as well as in the Salesforce developer console, it seems it gets delivered in scientific notation by SOQL without a chance to influence that.

Currently I'm not sure if that is a bug/issue and how to address this.

We were thinking of several workarounds and tried quite some stuff to overcome that issue using text fields, format() with alias on SOQL, using Streamsets functions (str:, math: these only seems to be accounted in input fields not in the query itself) all without success.

The only thing that worked was directly changing the source of the salesforce_lib to convert the offset back in the desired format.

If needed I can provide logfiles & configuration or file an issue if necessary.

Best regards Peter