|
Hi, we had an effect in the MobiLink server log file. By accident a synchronised column in the consolidated db has a longer varchar datatype (varchar(14) meant for timestamp in character format) then the corresponding column in the remote db (varchar(8) meant for date in character format). As to expect one day it happens, that the actual value in the consolidated was longer than allowed in the remote. That gave a sync error in the log file: "[-10038] A downloaded value for table 'LFV_LGER' (column #8) was either too big or invalid for the remote schema type" That's correct but (because we are logging with -v+) looking at the value in the server log it shows only the first part of the actual value in the consolidated. So at first sight that looks okay. Maybe in such case the log should show the actual value rather than the part according to the remote type declaration? (using SQL Anywhere 16.0.0.1915, MobiLink-Server on a Windows box) TIA, Chris Werner |
|
This is an expected behavior. Here is the reason: The MobiLink server does not describe the columns of the result set returned by the download_cursor or download_delete_cursor script, because some of the ODBC drivers do not support the necessary functions. Therefore, the MobiLink server will allocate a buffer for each column of the result set and the buffer size will be determined using the column definition of the sync table in the remote database. If the data in the consolidated database is longer than the one in the remote, the ODBC driver will warn the MobiLink server during data fetch. Then the MobiLink server will warn the user and stops messing up the remote database.
Does that mean the ODBC driver won't tell the "too long" value, and it can't therefore be shown in the log file? (Otherwise I'd second Chris's suggestion to enhance the log output with the "disturbing" value.)
(04 Sep '14, 03:54)
Volker Barth
Replies hidden
Some ODBC drivers can't tell us how long the underlying column is using SQLDescribe, particularly in situations where a stored procedure that returns a result set is used as opposed to a straight SQL statement. When we allocate the buffer to hold the return value, we use the size of the column in the remote database, which we do know. I agree it would nice, but I'm concerned about the possibility of buffer overflows and possible crashes if we start "guessing" at the size of buffer needed to hold the return value. This can be easily worked around by either fixing the size of the column in the consolidated (or remote) database or changing the download_cursor and/or download_delete_cursors to truncate the result to the size of the column in the remote database.
(04 Sep '14, 08:57)
Reg Domaratzki
1
OK, I have now understood that the ODBC driver will raise a warning for inappropriate values but cannot return the problematic values simply because they would have to be stored in the too-small fetch buffers. That's reasonable:) (I'd thought the value might be contained in the text of the warning message but even if so, it might be tricky (and very system-specific) to extract it from there, and as such no useful enhancement.)
(04 Sep '14, 09:13)
Volker Barth
|
FWIW the MobiLink server tends to use the remote database as the authoritative source for all things schema... foreign key relations for sure, possibly data types as well... so I'm not surprised that it used VARCHAR(8) to do the display.
The MobiLink server works with all brands of consolidated databases so I will bet it doesn't pay any attention to the schema, it just takes the SELECT result sets and tries to ram them into the remote... it has always been up to you to ensure compatibility of the data streams up and down.
...having said that, what you are asking for sounds reasonable as an enhancement request.