Is there a major difference between these two to the programming world?
I don't mean to ask rediculous questions but I used SqlHelper frequently in EntLib2005. I'm moving directly into EntLib3.1 and there are several differences I'm not used to that I'm trying to wrap my brain around. If I create a database bypassing configuration
SqlDatabase SqlDb = new SqlDatabase(ConfigurationManager.ConnectionStrings"XXXX".ToString());
and I call ExecuteNonQury on SqlDb, why am I not allowed to use a SqlCommand object with a SqlDatabase object? I used this object often because I would define all parameter info (size, direction, type) explicity. However, the DbCommand object is limited in
types for example and it just seems like I'm stepping back a little having to use the DbCommand object with EntLib. I'm not a serious enough coder to know (or know how to know) if DbType.String is just as good performer as SqlDbType.VarChar if my backend is
Is it possible to use the SqlCommand object when calling public EntLib methods that require a database command object as an argument?
Thanks & Peace Out...Reed
One of the main goals of the data access block since EntLib 2005 is to enable "database agnostic" code to be written, just like ADO.NET 2.0; you can read about this at
http://msdn2.microsoft.com/en-us/library/ms971499.aspx. The consequence of this is that the APIs only deal with the
"base" objects, so the vendor specific details are not directly exposed.
However, since an SqlCommand is really a DbCommand, you should be able to configure your command manually and use it as a parameter int eh ExecuteNonQuery method. Of course this would only work for SqlDatabases.
About DbType.String vs. SqlDbType.VarChar, you should ask in the ADO.NET forum at