> I think if you add an implicit conversion to SqlString, it > should > work, but I haven't tested this. The MetaType retrieval routine then > will > produce the proper type, instead of the wrong type. Internally it > appears to > work with Sql* types, instead of native .NET types. I'm not sure > though, > please take a peek with reflector in > SqlClient.SqlCommand.BuildParamList.
Unfortunately, the conversion op to SqlString doesn't do the trick. It looks like you end up in SqlParameter.GetMetaTypeOnly, which will only deal with char or char[] types. From there it's into MetaType.GetMetaTypeFromValue, which seems to require that you're an *actual* Sql* type: if (value.GetType() == typeof(SqlString)) > Strictly, this is a Udt case for the parameter, I think. So it > doesn't > know if you want to threat it as a Udt, or that you want to threat the > object > as a value of a different type. The thing is that it can't know to > which type > to cast unless it casts and tests. It does look like UDT is the only option for extending this - but that still requires you to set the UdtTypeName property on the SqlParameter (not to mention the assembly loading into Sql, and Sql 2005), so it doesn't solve my scenario. Not to second guess (too much) the ADO.NET team, but it seems like the whole coercing values bit isn't following decent OOP guidelines. Switching on the type of a value, without a fallback mechanism relying on an interface (or an attribute, or a conversion op) has a bit of a smell to me. --MB =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
