Basically I'm just guessing here based on my experience with SQL
Server. If you are using a datareader, then you're just getting back a
result set. If the result set is empty, then there's no error
involved, it's just an empty result set. If the stored procedure
doesn't return a result set, errors can be returned by RAISERROR
statements in the stored procedure code, which you would see with
executenonquery. Usually the stored procedure writer returns error
information because, for the most part, SQLS doesn't. In other words,
your stored procedure doesn't halt on an error line, SQLS just resets
the error code to 0 and executes the next statement. Very few things
cause SQLS to halt entirely. So you need to look at your stored
procedure code to analyze where things are breaking down. You can't
trap errors that don't get passed to your calling code.
-- Mary
MCW Technologies
http://www.mcwtech.com
On Tue, 07 Oct 2003 11:17:48 -0700, Mansoor Shahi <(E-Mail Removed)>
wrote:
>Hi Mary,
>
>it is a big and complex stored procedure, that i have not written it. in
>this sp there is a transaction and on that there is some update command
>and after committing the transaction there is a select statement that
>select some fields from some tables. i can send it,if u want, but i
>think this is not helpful.
>
>Okey, return to my question, as i mentioned ago if i execute the sp by
>cm.EXECUTENONQUERY (cm is a SQLCOMMAND object) i get the error but if i
>replace EXECUTENONQUERY with EXECUTEREADER and run the project i never
>get the error.
>
>
>regards
>
>
>
>*** Sent via Developersdex http://www.developersdex.com ***
>Don't just participate in USENET...get rewarded for it!