Skip to content
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

Fix for truncation of strings with FreeTDS driver #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jbaxter0810
Copy link

Added a fix for FreeTDS. It was interpreting strings longer than 4000
characters as NVARCHAR(4000) instead of NVARCHAR(MAX). Updated so now it
interprets strings longer than 4000 characters as SQL_WLONGVARCHAR instead of SQL_WVARCHAR.

Added a fix for FreeTDS. It was interpreting stings longer than 4000
characters as NVARCHAR(4000) instead of NVARCHAR(MAX).  Update so now it
interprets strings longer than 4000 characters as SQL_WLONGVARCHAR
@wankdanker
Copy link
Owner

If memory serves correctly, I think there are some weird issues surrounding the usage of SQL_WLONGVARCHAR. I need to do some research.

@wankdanker
Copy link
Owner

Yeah, see #10. Need to figure out how to solve this problem for good.

@lee-houghton
Copy link

Yeah, it's a horrible problem. I don't know if there is a sane solution :(

@bzuillsmith
Copy link

I think this is going to require some kind of config property with specific code for each driver--ugly, but probably necessary because I doubt there are ways to accurately detect the behavior here. A couple ideas:

  • We could attempt to match part of the connection string to detect the driver being used. Then set a variable in the odbc connection that will determine which code path to take for string bindings.
  • We could create a config property on the connection that is effectively and Enum that sets the driver being used. Could be set to things like 'FreeTDS', 'MSAccess', etc. where the default would be the current functionality (thus preventing a major version change).

@wankdanker
Copy link
Owner

I agree, @bzuillsmith. Even if we can accurately detect what the proper type should be either from the driver or other magic, we'll have to have a property on the connection that can be passed to GetParametersFromArray.

We could also expose methods to manually set up the bindings (as @lee-houghton did in eos) where the user can manually set the data types, sizes, etc instead of trying to just magically do the right thing.

clach04 pushed a commit to clach04/node-odbc__DO_NOT_USE that referenced this pull request Dec 17, 2020
Adding support for Node.js Buffer class to send binary data
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants