Data Types And Convenience Methods are Overrated
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
AspDotNetDev wrote:
SqlDbType.Int
Soooo many practitioners think that's necessary. :sigh:
AspDotNetDev wrote:
AddWithValue
I never use that; it's not defined by an Interface I use. I use IDbCommand.CreateParameter and IDataParameterCollection.Add.
AspDotNetDev wrote:
is optional
That may be true with the database system you use; it may not be true with all the database systems I use.
-
AspDotNetDev wrote:
SqlDbType.Int
Soooo many practitioners think that's necessary. :sigh:
AspDotNetDev wrote:
AddWithValue
I never use that; it's not defined by an Interface I use. I use IDbCommand.CreateParameter and IDataParameterCollection.Add.
AspDotNetDev wrote:
is optional
That may be true with the database system you use; it may not be true with all the database systems I use.
I also prefer to see it, even if optional because it makes it more obvious that it is a required parameter.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
AddWithValue is the best thing since sliced bread (except for bacon)... Makes everything a hell of a lot easier. :thumbsup:
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932 -
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
AddWithValue can cause problems where conversions may not be as expected: better to use Add and be explicit about what you are doing. And what harm the @? Just because something is optional doesn't mean you shouldn't use it - verbosity is king - it promotes clarity.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
AddWithValue can cause problems where conversions may not be as expected: better to use Add and be explicit about what you are doing. And what harm the @? Just because something is optional doesn't mean you shouldn't use it - verbosity is king - it promotes clarity.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Notice anything else about why the code is strange?
-
Notice anything else about why the code is strange?
Yes indeed, but I didn't think that was your point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
AspDotNetDev wrote:
SqlDbType.Int
Soooo many practitioners think that's necessary. :sigh:
AspDotNetDev wrote:
AddWithValue
I never use that; it's not defined by an Interface I use. I use IDbCommand.CreateParameter and IDataParameterCollection.Add.
AspDotNetDev wrote:
is optional
That may be true with the database system you use; it may not be true with all the database systems I use.
PIEBALDconsult wrote:
Soooo many practitioners think that's necessary
I find nothing wrong with specifying that. The thing I find funny is the specification that it's an int, and then on the next line passing in a string, which was actually an int to start with (rather than casting to an int).
PIEBALDconsult wrote:
I never use that
The first thing I did was convert it to LINQ. Now the call looks a bit like
context.SomeStoredProcedure(someInt). In my next project, that's basically still how I'll do it, only I'll be abstracting away the data source and using Ninject, so where it's actually used it'll look more likedataStore.DoSomething(someInt).PIEBALDconsult wrote:
That may be true with the database system you use; it may not be true with all the database systems I use
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
-
Yes indeed, but I didn't think that was your point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
My only point is to make fun of as many things as is possible in that code snippet. However, the only real thing wrong with it is converting an integer to a string and then using that string as the value of a parameter that was just explicitly specified to be an integer.
-
My only point is to make fun of as many things as is possible in that code snippet. However, the only real thing wrong with it is converting an integer to a string and then using that string as the value of a parameter that was just explicitly specified to be an integer.
Indeed - but you missed the smiley! I took you seriously! I wouldn't do it in that way (even with correct typing), in any case - too clumsy and not reusable. :)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
PIEBALDconsult wrote:
Soooo many practitioners think that's necessary
I find nothing wrong with specifying that. The thing I find funny is the specification that it's an int, and then on the next line passing in a string, which was actually an int to start with (rather than casting to an int).
PIEBALDconsult wrote:
I never use that
The first thing I did was convert it to LINQ. Now the call looks a bit like
context.SomeStoredProcedure(someInt). In my next project, that's basically still how I'll do it, only I'll be abstracting away the data source and using Ninject, so where it's actually used it'll look more likedataStore.DoSomething(someInt).PIEBALDconsult wrote:
That may be true with the database system you use; it may not be true with all the database systems I use
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
AspDotNetDev wrote:
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
That's an interesting point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
AspDotNetDev wrote:
"@" is optional when specifying parameters.
Actually I believe the "@" symbol only became optional in .Net Framework 2.0 and above, before that it was a requirement. Please don't take my word for that, but its coming from a rusty memory of my own personal experience.
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
Well, in the codebase I handle I'm enforcing a standard of explicitly stating the parameter type when using ADO.net. Granted, we're autogenerating the DAL using an internal tool, but it helps in a lot of situations. Example: when using a string field, if you specify the length, ADO.net will truncate the parameter to the expected maximum length. Otherwise it gets passed to the underlying db and the query will error out. For us, the former behaviour is preferred. YMMV :)
Luca The Price of Freedom is Eternal Vigilance. -- Wing Commander IV En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. (But the best thing God has created, is a New Day.) -- Sigur Ròs - Viðrar vel til loftárása
-
PIEBALDconsult wrote:
Soooo many practitioners think that's necessary
I find nothing wrong with specifying that. The thing I find funny is the specification that it's an int, and then on the next line passing in a string, which was actually an int to start with (rather than casting to an int).
PIEBALDconsult wrote:
I never use that
The first thing I did was convert it to LINQ. Now the call looks a bit like
context.SomeStoredProcedure(someInt). In my next project, that's basically still how I'll do it, only I'll be abstracting away the data source and using Ninject, so where it's actually used it'll look more likedataStore.DoSomething(someInt).PIEBALDconsult wrote:
That may be true with the database system you use; it may not be true with all the database systems I use
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
I don't think there's a real way to achieve portability on that, it strongly depends on the connector used. ODBC for example uses a positional syntax for parameters, ignores parameter names and uses the '?' char as a parameter placeholder. MS-Access, same thing. The MySQL provider IIRC can be configured both ways, but by default requires the '@' char (or maybe the reverse, it has been a few years since I last used it).
Luca The Price of Freedom is Eternal Vigilance. -- Wing Commander IV En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. (But the best thing God has created, is a New Day.) -- Sigur Ròs - Viðrar vel til loftárása
-
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. :doh:
I believe this line:
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()
Should be this:
cmd.Parameters("@SomeID").Value = Int32.Parse(Session("SomeID").ToString())
;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
AddWithValue is the best thing since sliced bread (except for bacon)... Makes everything a hell of a lot easier. :thumbsup:
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932 -
AddWithValue is the best thing since sliced bread (except for bacon)... Makes everything a hell of a lot easier. :thumbsup:
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932Easier isn't always better.
