|
|
Posted by serge on 01/27/06 05:51
> Unsafe? Yes, a little, although that was not really what I meant with
> red tape. What I mean is simply that there are so many things have to
> be aligned for it to work, that I don't find it worth the hassle.
>
> Some time back, we found that debugging did not work when you had Windows
> XP SP2 installed. I did some investigation, and found that hotfix
> 8.00.944 addressed this problem. (This hotfix is included in SP4.) I
> installed hotfix on client and server. I also had to open port 135 in
> Windows firewall. Now, port 135 is not any port: this is RPC, and a
> prime attack surfaces for viruses. So opening port 135 is a little unsafe,
> so there is all reason to only open it for the SQL Servers you want to
> debug. (If is possible to open a port only for a certain IP address in
> Windows firewall.) Eventually I got it working.
>
> Then some months later, I felt like debugging again, but now I was out
> of luck again. I did some inquires, and apparently our Windows admin had
> decided to cut the number of permissions for the SQL Server service
> account. I don't know exactly what permissions that are required, but
> as it writes back to the client, it needs more than plain-user rights.
>
> At this point, I just gave it up. These are not the only thing that
> can stop debugging from working. And after all, what you can dig out
> from the debugger can easily be achieved in other ways. Of course,
> code that uses iterative approaches can be painful to debug that
> way. But good SQL should not have much such code anyway. :-)
>
> And, oh, there is one more possible issue with the debugger. Single-
> stepping through a transaction is not that friendly if other users
> needs to access the data.
Thanks for the detailed explanation. Some interesting information
that I'll keep in mind.
Navigation:
[Reply to this message]
|