[Message Deleted]
-
[Message Deleted]
-
[Message Deleted]
-
Could you clarify these: - what is the type of cmd - which class is giving the exception - what method are you using when exception is given
-
You scared him out to delete his post! :laugh:
All generalizations are wrong, including this one! (\ /) (O.o) (><)
-
Could you clarify these: - what is the type of cmd - which class is giving the exception - what method are you using when exception is given
I figured out my own problem just after posting the message. It was a subtle syntactical error. Nonetheless, I have spent many days trying to debug datatype errors, in which using cmd.Parameters.AddWithValue(...) couldn't seem to get the type right. Finally I began adding the parameters first, with the type specified using cmd.Parameters.Add(..., type) and then adding the value to the parameter. So far this has eliminated the frustrations of my commands not working. However, the jury is still out for me as to whether using parameters is THAT much more convenient or less work that concatenating values into a string. I have a pretty good system worked out where I separate each concatenated value on a separate line my code (for readability) and use a quote(arg) function and formatDate(arg) function for convenience. Public Function quote(arg as String) as String Return chr(34) + arg + chr(34) End Function You get the idea. I find it simpler to debug a query in which I can see all the values by simply printing the string to the debug window, rather than iterating through the parameters collection manually in the immediate window.
-
I figured out my own problem just after posting the message. It was a subtle syntactical error. Nonetheless, I have spent many days trying to debug datatype errors, in which using cmd.Parameters.AddWithValue(...) couldn't seem to get the type right. Finally I began adding the parameters first, with the type specified using cmd.Parameters.Add(..., type) and then adding the value to the parameter. So far this has eliminated the frustrations of my commands not working. However, the jury is still out for me as to whether using parameters is THAT much more convenient or less work that concatenating values into a string. I have a pretty good system worked out where I separate each concatenated value on a separate line my code (for readability) and use a quote(arg) function and formatDate(arg) function for convenience. Public Function quote(arg as String) as String Return chr(34) + arg + chr(34) End Function You get the idea. I find it simpler to debug a query in which I can see all the values by simply printing the string to the debug window, rather than iterating through the parameters collection manually in the immediate window.
Good to hear you got it solved. I see your point, but I believe that parameters benefit you in many ways so I encourage you to use them. One idea that may come handy: Derive your own class from OleDbCommand and use that for database operations. If you need to see the statement and the values for parameters, create a helper method in derived class (of course you can separate this to a helper class). In that method list all the info you need to the output window. Something like:
public void WhatsInside() {
Debug.WriteLine(this.CommandText);
foreach (OleDbParameter param in this.Parameters) {
Debug.WriteLine(param.DbType + param.value + ...);
}
other possible info...
}Added: This method can be called from immediate window while debugging so calls to it doesn't have to exist in code. Also this should be included only in debug builds. Mika
modified on Wednesday, September 10, 2008 4:41 PM