did debugging with SP3 ever get fixed for Visual Studio.NET?

When I installed SP3 on SQL 2000, I lost the ability to debug stored procedures
from Visual Studio - single stepping into the stored procedure.
I spent a day trying to fix it maybe 8 months ago - and gave up.
Are there any tech notes that actually work to restore the ability to debug when
SQL Server is on the same machine as Visual Studio?
If not, can I fix the problem by un-installing SQL Server and then installing
the SP2 version? I'm unclear if the database files would have any problems with
this - or have any problems when moving SP2 databases to my SP3 production
boxes?
--
Thanks in advance, Les CaudleWe can get it to single step through the procedure, but not set a breakpoint.
Was it ever possible to breakpoint? I note the documentation states it will
not "Break", but we took that to mean one could not break the execution and
re-start.
Cheers
Happy Harry
"Les Caudle" wrote:
> When I installed SP3 on SQL 2000, I lost the ability to debug stored procedures
> from Visual Studio - single stepping into the stored procedure.
> I spent a day trying to fix it maybe 8 months ago - and gave up.
> Are there any tech notes that actually work to restore the ability to debug when
> SQL Server is on the same machine as Visual Studio?
> If not, can I fix the problem by un-installing SQL Server and then installing
> the SP2 version? I'm unclear if the database files would have any problems with
> this - or have any problems when moving SP2 databases to my SP3 production
> boxes?
> --
> Thanks in advance, Les Caudle
>

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed code http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);

Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed code http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);

Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed code http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);

Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.