I don't understand your example, you are passing the message from the xeception into the constructor for a DataSet?
 
If you want to know the real error I would remove the try catch entirely. Its generally not recommended to catch the most generic error anyway.
 
Joe

"David P. Donahue" <[EMAIL PROTECTED]> wrote:
> When I converted my project from ByteFx to the newer connector I had to
> change all the parameter code from @Param to ?Param
> Also any param declared as int I had to change to int32
>
> If you get an error in your sql syntax it likely won't bring back a
> datatable thus the error you see masks the real error, not sure if thats
> the problem but hope it helps.

To test this, I wrote a couple web service functions which use
manually-written SELECT statements, so the syntax shouldn't be a
problem. But I still get either this same error or "Thread was being
aborted."

I'm concerned about how it may be masking a "real error" though. My
error trapping for the function is as follows (sorry for any wrapping):

try{
mySqlConnection = new MySqlConnection(Global.strongConnection);
mySqlDataAdapter = ne w MySqlDataAdapter("SELECT * FROM FAQ",
mySqlConnection);
dataSetSQL = new DataSet();
mySqlDataAdapter.Fill(dataSetSQL);
return dataSetSQL;
}
catch (Exception e){
return new DataSet(e.Message);
}

Would this be enough to catch any such errors? Or do I need to change
that at all?


Regards,
David P. Donahue
[EMAIL PROTECTED]
http://www.cyber0ne.com
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list


joe_audette [at] yahoo dotcom
http://www.joeaudette.com
http://www.mojoportal.com
_______________________________________________
Mono-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to