can you provide more connection parameters

[cfw]

can you provide more connection parameters? like sendStringParametersAsUnicode

[shueybubbles]

Can you elaborate with a more detailed list? for example, what would sendStringParametersAsUnicode mean and how would the behavior with it set to true or false differ from how the driver currently behaves?

[cfw]

Lets say we have a table T1( C1 varchar(50), C2 varchar(40)....)

execute query with varchar column query parameter in where clause. where("[C1] = ?","4000")

The parameter "P4000" in the above query is passed as nvarchar(4000)

When I check the query from database:
@p0 nvarchar(4000) select ... from T1 where C1 = @p0

This is effecting the query plan. As the execution plan is doing a convert_implicit(C1) in the where clause. This is meaningless transformation

Is there a way to pass the parameter as varchar instead of nvarchar so that query engine does not do the the implicit conversion and picks up the right index?

in java driver, we found a driver parameter sendStringParametersAsUnicode. Setting this to false helps the params data type to be varchar(4000). i refer official doc https://docs.microsoft.com/en-us/sql/connect/jdbc/reference/setsendstringparametersasunicode-method-sqlserverdatasource?view=sql-server-ver16

• go-mssqldb v0.10.0
• Go:1.18.5
• Database:SQLServer 2012
• OS:Mac Os

[shueybubbles]

@cfw I'd welcome your input on #46

[moizm89]

@shueybubbles @cfw Since Microsoft officially maintains Golang and Java libraries now. Can we please expect this issue to be prioritized for parity in the features?
The current way to handle nvarchar to varchar conversion in Golang code is tedious and requires each string variable to be type casted to mssql.VarChar before sending in the query.

[shueybubbles]

@moizm89 I'd love to get more community feedback on solving this problem at #46
I don't think the solution is as simple as a binary "use unicode for strings" switch on the connection. Java/.Net/ODBC all have advanced parameter management that go-mssqldb simply lacks. The app writer in those languages can readily specify that the parameter type is a varchar type instead of an nvarchar type, and their non-unicode strings can be converted to an ANSI code page.
In the sql/driver model provided for Go apps, all we know is a given parameter is a string whose encoding is UTF8. Converting that UTF8 string to UTF16 is the safest way to send it to the server without data loss.
What should the programming model look like so Go app developers can properly mix varchar and nvarchar parameters on the same connection and assure encoding to the code page to match the database collation?