I’m trying to standardise some data access code with my colleagues. One of the aforementioned colleagues asserts that the EntLib Data Access Block trys to cache parameters on stored proc calls.
I’ve had a look in reflector and there is some evidence that it could be caching them. But I don’t think it does in the following situation.
public Dictionary<long, string> GetQueue(int maxItems) { var sq = new SqlDatabase(_connString.ConnectionString); var result = new Dictionary<long, string>(); using (var cmd = (SqlCommand)sq.GetStoredProcCommand('dbo.GetQueue')) { sq.AddInParameter(cmd, 'maxItems', DbType.Int32, maxItems); var reader = cmd.ExecuteReader(CommandBehavior.CloseConnection); while (reader.Read()) { long id = reader.GetInt64(reader.GetOrdinal('id')); string fileName = reader.GetString(reader.GetOrdinal('meta_data_filename')); result.Add(id, fileName); } } return result; }
Can anyone confirm or deny this?
I’m using EntLib 4.1
It definetly used to, I ripped the code out and threw in in my library.
it used
sp_helpand parsed the output to determine the data types.These days, I ripped the code out, .Net is much much better about adding parameters.
in your example of you keep reflectoring … you will find it being done down this path GetStoredProcCommand()
You will get a Command object back, already populated with parameters
The ent lib code is copyrighted, but the code is almost identical to this
http://code.google.com/p/dbdotnet/source/browse/trunk/ParameterCache.cs