What were the MS programmers smoking when they coded the System.Data.SQLClient and System.Data.Oledb wrappers? My beef is that under VB6 I made extensive use of parameterized stored procedures, with a couple of functions that handled the creating the connection and command object I had reduced the amount of code to:

Set Cm = GetCm("sp_MyStoredProc")
Cm.Execute

For a recordset it took a little more effort:

Set Cm = GetCm("sp_MyStoredProc")
Rs.Open(Cm)

For a parameterised query:

Set Cm = GetCm("sp_MyStoredProc")
SetCommandParameter Cm, "@MyParam", "Test"
Cm.Execute

With VB.net this has increased greatly as now I have to specify the Direction of the paramter and the size or get a runtime error!! Surely any observer can see this is a step backwards. If a stored procedure's parameter is altered so that the application now sets the wrong parameter direction and errors this is going to cause pain. If the reason this has been introduced is to speed things up then where's the option to turn it off and do it the old way?

If MS are trying to encourage VB6 old timers like myself to adopt their fancy new .Net then they should be trying to make my life easier not cause me to rip what little hair I have left out!