Question
I work with Sybase 12 and dapper.net. Everything was ok, until I made Sybase update 3817. After this update, I began to get such exception: " System.NullReferenceException:"
trace:
iAnywhere.Data.SQLAnywhere.SAConnection.CalledByEntityFramework() +263
iAnywhere.Data.SQLAnywhere.SAConnection.get_ConnectionString() +538
Dapper.Identity..ctor(String sql, Nullable`1 commandType, IDbConnection connection, Type type, Type parametersType, Type[] otherTypes) +73
Dapper.<QueryInternal>d__13`1.MoveNext() +545
System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) +381
System.Linq.Enumerable.ToList(IEnumerable`1 source) +58
Dapper.SqlMapper.Query(IDbConnection cnn, String sql, Object param, IDbTransaction transaction, Boolean buffered, Nullable`1 commandTimeout, Nullable`1 commandType) +218
Dapper.SqlMapper.Query(IDbConnection cnn, String sql, Object param, IDbTransaction transaction, Boolean buffered, Nullable`1 commandTimeout, Nullable`1 commandType) +88
When I looked into the connection my variablу I saw, that connection string has exception:
'MDbConnection.ConnectionString' threw an exception of type 'System.NullReferenceException'.
I can't understand what happens in this update of sybase. All next updates of version 12 and the newest - 16 have the same trouble with dapper! But if I use ADO.Net - everything works fine!
Expert Answer
That is interesting; it looks like it relates to:
internal Identity(string sql, CommandType? commandType, IDbConnection connection, Type type, Type parametersType, Type[] otherTypes)
: this(sql, commandType, connection.ConnectionString, type, parametersType, otherTypes, 0)
{ }
So it is the simple act of querying the .ConnectionString that is failing. You say:
But if I use ADO.Net - everything works fine!
I imagine that is because when using ADO.NET you haven't had any reason to look at the .ConnectionString once a connection is open. Probably the first thing to do (can you check this?) is to see whether .ConnectionString does throw an error, i.e.
using(var conn = new WhateverConnection(connectionString)) {
conn.Open();
// maybe execute a command, just for fun
Console.WriteLine(conn.ConnectionString);
}
of course if might be something else in the code that is somehow making it incorrectly think it relates to Entity Framework, as per:
iAnywhere.Data.SQLAnywhere.SAConnection.CalledByEntityFramework() +263
However! Ultimately, it looks like the "problem" here is: a bug in the SAConnection implementation. Frankly I think this is something you need to log with sybase.
Popular Answer
I decompiled the assembly, showing the following code:
public override string ConnectionString
{
get
{
SATrace.PropertyCall("", this._objectId);
if (this._connStr == null)
{
return "";
}
if (SAConnectionOptions.GetAdoDotNetTesting(this._connOpts))
{
//.....
}
if (SAConnectionOptions.GetPersistSecurityInfo(this._connOpts) || base.DesignMode || SAConnection.s_isHostedByVisualStudio)
{
return this._connStr;
}
if (this.CalledByEntityFramework()) //It goes wrong here
{
return this._connStr;
}
string result;
string text2;
string text3;
SAConnection.RemoveKeyValuesFromString(this._connStr, SAConnectionOptions.s_passwordKeys, false, out result, out text2, out text3);
return result;
}
set
{
///...
}
}
So I added the following to our connection string: ;Persist Security Info=True
This will allow the code to go in the 3th if statement, instead of the 4 which is causing the null reference.