hie people, could anyone tell me what's wrong with following code:
Dim cmd As New SqlCommand("SELECT * FROM Security_Ques WHERE Username = " + txtUsername.Text + " and Ques_Index = " + cmbSecurity_Ques.SelectedIndex + " and Answer = " + txtSecurity_Answer.Text + "", con)
because it is raising an exception like this:
Conversion from string "SELECT * FROM Security_Ques WHER" to type 'Double' is not valid.
Thanks.
The only real problem I see in that line is your query isn't correct. You still need to add single quotes in the query to make string values SQL strings. It helps to copy the string verbatim into Management Studio (or whatever database utility you use), replace the VB.NETisms and run it to verify your SQL syntax. For example, your query would look like this with some dummy data:
SELECT * FROM Security_Ques WHERE Username = someuser and Ques_Index = 0 and Answer = blahblahblah
Looking at it this way, it's obviously incorrect because your strings aren't quoted.
@deceptikon: I already corrected that string as it came to my notice but still there exist a problem.
Dim cmd As New SqlCommand("SELECT * FROM Security_Ques WHERE Username ='" + txtUsername.Text + "' and Ques_Index = " + cmbSecurity_Ques.SelectedIndex + " and Answer ='" + txtSecurity_Answer.Text + "'", con)
Even with this code which is corrected with inserting quotes at required points ( take please in correcting those). But still i get above mentioned exception.
Post more code.
I believe you are getting the error due to your use of "+" for string concatonation. Since you have a numerical value (cmbSecurity_Ques.SelectedIndex) in your code, the compiler is treating all of it as a mathematical equation.
Switch to using "&" and change:
cmbSecurity_Ques.SelectedIndex
to:
cmbSecurity_Ques.SelectedIndex.ToString
Ah, that's true. I'm always mixing up C# and VB.NET in my head (usually by including C#isms in VB.NET and getting frustrated when it fails). ;)
deceptikon,
Warning - I'm on my soapbox again
It is not your fault that MS has always tried to make VB.Net compile whatever garbage it is thrown.
"Option Strict" should never have been an option at all, all they needed to do was provide an code attribute syntax to allow late binding for when it is absolutely necessary.
I really hate their Anonymous Type for LINQ "BS" as well with telling people that have to use it for LINQ with "Option Infer ON". That's another option that I loath as I believe in being very explicit when it comes to coding. I really get a kick out of the many VB examples in the documentation that do not hold the company line and show strongly typed LINQ.
Option Explicit On ' declare your variable types
Option Strict On ' no implicit type conversion
Option Infer Off ' inference is just an (hopefully) educated guess as to one's intent.
OK, I'm back on my meds. ;)
Have a nice day.
@TnTinMN: Kudos, you solved my problem.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.