-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bulk insert doesn't handle (N)VARCHAR(MAX) columns #192
Comments
That's weird, looks like the column is send using varchar(max), but looks like the server does not like the row format (which seems correct to me, is exactly what the server usually expects). The bulk insert (rejected) is: Beside the DONE token (on select but not on bulk) they are exactly the same (ignoring 8 byte header) |
This is weird. I basically try the MS utilities to see the difference. Apparently instead of sending the size at the beginning they send unknown (-2 basically) and works. Both segmentations of data should work from the protocol specification but looks the server don't like a proper length. I replaced the size with -2 in our code and works! Can you try this patch (which works for me) ?
if this works even for you I would say is a server bug... or at least a documentation one |
Yes, that also works for me. I would tend to agree that this seems like an issue with the documentation not matching the actual behavior. From the TDS spec (page 32 of v20171201):
This appears to be what the current (non-functioning) code is doing: sending the total length, then a single PLP_CHUNK with the data (and a PLP_TERMINATOR after). However, simply removing the |
Tried to remove the line you suggested, does not work all the time and imported data are not what they are expected to be. So I can confirm, this is a database server bug. Nothing to worry, operation will fails if the client (FreeTDS in this case) is not implementing some workaround like sending unknown length (the -2). Microsoft client already implements the client in that way. |
More detail can be extracted from the log, but the gist is:
VARCHAR(MAX)
columnHere's the TDSDUMP (I omitted much of the login stuff since it seems unrelated):
The text was updated successfully, but these errors were encountered: