-
Notifications
You must be signed in to change notification settings - Fork 128
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
Bug: Output parameters of type varchar gives Size exception #836
Comments
Confirmed. I'm seeing the same error message with a single output param of type string/nvarchar(6). |
Thanks gents. Apology for the late reply, been on a long vacation 😄 . I have this verified and it is confirmed as well. This will be a part of the next release. There is alternative anyway, see below. var commandText = @"DECLARE @returnValue NVARCHAR(MAX);
EXEC sp_whatever @returnValue OUT;
SELECT @returnValue;";
var result = connection.ExecuteScalar<string>(commandText); |
The fixes for this issue has been delivered in our main line. It will be available to the next version of the library > RepoDB (v1.12.8-beta4). |
With 1.12.8-beta5 I'm still seeing this issue. I hope it's something I'm doing wrong.
|
This issue should be fixed there and what you are doing is correct. Can you try see if you can get the value on the |
This one is working on the latest beta version of SQL Server (v1.1.4 -beta1). SP:
C#: namespace RepoDbDirectionalQueryField
{
class Program
{
static void Main(string[] args)
{
Initialize();
TestDirectionalQueryField();
}
static void Initialize() =>
SqlServerBootstrap.Initialize();
static void TestDirectionalQueryField()
{
using (var connection = new SqlConnection("Server=.;Database=TestDB;Integrated Security=SSPI;"))
{
// Setup
var outputInt = new DirectionalQueryField("OutputInt", typeof(int), ParameterDirection.Output);
var outputText = new DirectionalQueryField("OutputText", typeof(string), 256, ParameterDirection.Output);
var param = new QueryGroup(new[]
{
outputInt,
outputText
});
// Act
connection.ExecuteNonQuery("sp_TestOutput",
param,
CommandType.StoredProcedure);
// Assert
var intValue = outputInt.GetValue<int>();
var textValue = outputText.GetValue<string>();
}
}
}
} |
In your case, you need to pass your variable |
Works perfectly. Thank you!!! |
Bug Description
Trying to call a stored procedure which has an output parameter of type varchar (sproc attached)
p_BreakglassRequest_Update.txt
Returning int or datetime output parameters seem to work fine, but varchar gives the exception below.
Exception Message:
Schema and Model:
Please share to us the schema of the table (not actual) that could help us replicate the issue if necessary.
And also the model that corresponds the schema.
Library Version:
RepoDb v1.12.7 and RepoDb.SqlServer v1.1.3
Original Code Attempt:
In my own repository class (not inheriting from RepoDb repositories) my code looked like this:
Note that I found a second issue (mentioned on Gitter) to do with the above code in trying to pass that RowVersion property to the sproc. If you comment out the "lastUpdateUserField, LastUpdateDateTimeField" parameters and also comment out the related code in the sproc, I found I could not get the sproc to be invoked, with it complaining about a non matching number of parameters. If I also commented out the RowVersion QueryField above (and corresponding lines in the sproc) then the sproc works fine.
My workaround for all of this currently was to eliminate the output parameters completely from the sproc, requiring an additional db call in the situation where there is a concurrency issue (not a major deal given the likelihood of it happening but not ideal nonetheless). In making that change I was then able to eliminate using "QueryField" arguments to the sproc call, and instead use the code below, which incidentally solved my issue with the Timestamp parameter property to the sproc. So I "think" there is an issue with passing a QueryField parameter to a Timestamp property in the sproc given this now works for me, but I understand if you are sceptical...
The text was updated successfully, but these errors were encountered: