I'm providing limited detail we will open a support case if need be. But we might be able to figure out the problem if we just knew what the message means and how to interpret it. General context is MobiLink using .NET downloads connected to an Oracle 12 database. It started happening sometime after the upgrade to SA 17 which coincided with supporting Oracle 12 for our product, but we didn't see it for at least a year. Once it starts happening, it continues to happen consistently on the same table, but when the consolidated db is restored here and synchronized, we cannot reproduce it. So far we haven't seen it against a SQL Server or SQL AnyWhere consolidated db. The documentation on the error message (-10206) says it is an error from a .NET invocation and shows the text as '%1'. I presume this means it dumps the exception and stack trace to the log because that's what I'm seeing in the ML server log. From the message and stack trace I get that some value cannot be stuffed into the download stream, and I even know the table, but I don't know what the numbers refer to. We've seen "3 13" and "7 13" depending on the table. We don't have 13 columns in the tables, so I guess that number means something else. I conjecture the 3 or the 7 might be the column, but I don't know if it might be 0 or 1 based numbering. Our message and stack trace looks like [-10206] 'System.SystemException: Parameter 3 13 is out of range for conversion at Sap.MobiLink.MLDownloadParameter.MoveCSValueToNative() at Sap.MobiLink.MLDownloadParameterCollection.MoveRowToNative(Boolean& row_was_filtered) at Sap.MobiLink.MLDownloadDbCommand.ExecuteNonQuery() at our code... asked 21 Sep '18, 19:40 remmert Comment Text Removed
|
The parameters are zero based, so parameter 3 refers to column #4 in the table. The second number represents the data type we are expecting. 13 refers to a wide character or multi-byte character, likely an NCHAR column at the remote database. In cases such as this, first check for schema differences in the table between the remote and consolidated, then check the .NET code to check the data types (or casting) you are using when setting the parameters for the IDbCommand returned from GetUpsertCommand or GetDeleteCommand. I won't spend any time defending the poor error message. The error message is so poor IMHO that I spent the time to improve the message. The following fix was merged into v16.0.0 build 2748, v17.0.9 build 4885 and all future releases above 17.0.9 : If user defined .NET code had been executing in the MobiLink Server to populate the download_cursor or download_delete_cursor and the value being bound to a particular column had been out of range for the data type, an unhelpful error message would have been printed similar to "[-10225] User exception: Parameter 1 7 is out of range for conversion: SystemException". The error message has been improved and now reads similar to "[-10225] User exception: Parameter for column #2 is out of range for conversion to data type integer: SystemException".If you are using a older version of the ML Server without the fix, here are the data types the error is referring to with the 2nd number. DOUBLE 1 BIGINT 2 BINARY 3 CHAR 4 DATE_STRUCT 5 INTEGER 6 REAL 7 SMALLINT 8 TIMESTAMP_STRUCT 9 TIME_STRUCT 10 UINTEGER 11 USMALLINT 12 WCHAR 13 UUID_BIN 14 UUID_STR 15 TIMESTAMP_ZONE_STRUCT 16 TIMESTAMP_ZONE_STRING 17 UBIGINT 18 BITSTRING 19 Reg answered 24 Sep '18, 10:32 Reg Domaratzki 2
Thanks Reg - that's what I needed. Now we'll see if I can apply it and figure out what changed. And no worries on the message; I can guarantee I've written more obscure messages myself.
(24 Sep '18, 10:46)
remmert
Replies hidden
Feel free to post a follow up question on the thread if you have more questions on this.
(24 Sep '18, 10:55)
Reg Domaratzki
2
I edited my original answer today to include information about the fix I submitted to make the error message more useful.
(11 Oct '18, 10:28)
Reg Domaratzki
Replies hidden
> make the error message more useful In-the-heat-of-the-coding-moment messages don't work, that much is clear. Neither do Microsoft-Bob-Style Messages.
(11 Oct '18, 12:50)
Breck Carter
|