I am working on my first project that uses OPENXML.
From VS 2003, I am executing a sp.
I am hitting problems with the sp and since this uses OPENXML, I could use
pointers debugging.
I did not see anything for the subject on msdn. Please help.
--
Many Thanks.
- Johnathan

Could you provide some information about the error you are getting, and
maybe a repro case of the stored proc that one could run via query analyzer?

Thanks
Michael

"Johnathan Seal" <JohnathanSeal (AT) discussions (DOT) microsoft.com> wrote

Thanks for responding Michael.
In a nut shell this is what I have done:
I created a stored procedure on SQL 2000 much like the MSDN article
prescribed.
The code then called the stored procedure - again, much like the MSDN
article prescribed.
When I ran the code, I got a non discript throw at the line the stored
procedure was called. I did turn on T-SQL debugging when the throw was
caught - but this did not help.
What I ended up doing was creating the stored procedure in code (via
StringBuilder) and calling it. This gave me the clues I needed to debug
further.

Comments: The work around I used gave the needed debug feedback but it is
not as 'clean' a solution.
If the work around is the best practice, can the MSDN article be changed?
The original question: is there a way to get the same level of debug
feedback when the call to the stored procedure fails as with the workaround?
Please note that the confusion partly stems from the fact that OPENXML is new
to me. Due to the way the stored procedure is written, debugging seems
ackward as it seems it must be called from 'other code' to debug.

I can offer the code example, but I just wanted to get to attemtp to get to
the point of the matter first. Please let me know if you still need the code?
FYI: the problem with the stored procedure was a PK violation.

Thanks, Johnathan

--
Many Thanks.
- Johnathan


"Michael Rys [MSFT]" wrote:

Hi Jonathan

If you got a PK violation, I doubt that the XML aspect had anything to do
with it. You could probably have gotten the same error behaviour, if you
would have read the data from a temporary table for example.

I am a bit confused re your debug feedback. SQL Server 2000 does not really
support T-SQL debugging (SQL 2005 will). So you will have to run your T-SQL
statement in the query analyzer for example to see where in the batch the
error occurs. Double-clicking on the error should take you to the line where
the error occurred.

Best regards
Michael

"Johnathan Seal" <JohnathanSeal (AT) discussions (DOT) microsoft.com> wrote