AsTableValuedParameter vs IsAnsi
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 18.4k
- Forks
- 3.7k
- Avg merge
- 5h 8m
- Merged PRs (30d)
- 1
Description
Hello, lovely people of Dapper!
Been meaning to ask this for a while, apologies if there is a simple fix or if this is related to #1201.
It appears that values passed through a AsTableValuedParameter
DbString.IsAnsiDefault = true;
DynamicParameters spParams = new DynamicParameters(new { inputs = ut.AsTableValuedParameter("tp_TableType") });
conn.Execute("DBNAME.sch.sp_StoredProcedureName", spParams, commandType: CommandType.StoredProcedure);
Doesn't appear to respect the IsAnsiDefault.
Because SQL profiler / extended events show the variables arriving as arriving as nvarchar/unicode instead of ansi varchar.
Which causes a bunch of needless inefficiencies with casting, table scans, and indexes.
Is that expected behavior? Am I using something incorrectly? Worth looking at?
Thanks in advance for reading and for such a great tool!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the AsTableValuedParameter entry point and how DbString.IsAnsiDefault is applied when the stored procedure is executed. Reproduce the nvarchar versus varchar behavior described with SQL profiler or extended events, then establish the expected parameter type and cover the confirmed behavior with a regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, sql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100