如何在 Management Studio 中调试长脚本?
我有一个很长的 T-sql 脚本,它是一个批次,
DECLARE variables
select into temptable...
cursor...
insert...
update..
就像我运行脚本一样,
(1 row(s) affected)
(5 row(s) affected)
[...]
ERROR
(2 row(s) affected)
etc...
我想逐步运行脚本来确定哪个命令给出错误,是否可以在管理中Studio 不使用 Visual Studio?
你还能建议我哪些其他技巧?我无法一次运行一段代码,因为在这种情况下我会丢失临时变量。
注意:当然最好不要以这种方式编写脚本,但我发现了这个,我想解决这个问题。
I have a very long T-sql script, it is a single batch, something like
DECLARE variables
select into temptable...
cursor...
insert...
update..
as I run the script I have
(1 row(s) affected)
(5 row(s) affected)
[...]
ERROR
(2 row(s) affected)
etc...
I would like to run step by step the script to identify which is the command that gives error, is it possible in Management Studio without using Visual Studio?
Which other trick can you suggest me? I cannot run a block of code at a time because int hat case I will lose temp variables.
Note: Of course it is better not to write scripts in this way, but I found this and I would like to fix the problem.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在 Sql Server Management Studio 2008 中,您可以采用与 Visual Studio 非常相似的方式进行调试。只需在要调试的行上设置一个断点,然后单击调试按钮 (alt-F5)。这将从第一行开始调试。再次单击调试(播放)按钮,它将运行到您设置断点的代码行。希望这有帮助。
In Sql Server Management Studio 2008 you can debug in a very similar manner to Visual Studio. Just set a break point on the line you want to debug and then click the debug button (alt-F5). This will start debugging from the first line. click the debug (play) button again and it will run to the line of code where you set your break point. Hope this helps.
您运行的是哪个版本的 SQL Server?
根据错误的严重程度,您可以尝试捕获错误的另一个巧妙技巧是将所有可疑的内容包装在 TRY / CATCH 块中。
首先创建一个像这样的表...
然后将代码放入 try / catch 块中。
这将捕获严重级别高于 16 的任何错误,并将它们插入到第一步中创建的表中。
需要注意的是,try / catch 块不会捕获低级错误。
我已经多次看到源表或目标表中的数据与预期不同,即奇怪的字符、文本而不是整数等。如果您仍然无法破解它,请针对数据库运行 sql server profiler 跟踪当您运行该过程时。
应该不需要很长时间就能发现问题。我不会介绍如何使用 SQL Server Profiler,因为您只需要快速进行网络搜索即可找到数百个详细指南。
Which version of SQL server are you running?
Depending on the severity of the error, another nifty trick you could try to catch the errors would be to wrap everything that is suspect in TRY / CATCH blocks.
Firstly create a table like so...
Then put your code in a try / catch block.
This will catch any errors above a severity level of 16 and insert them into the table created in the first step.
Caveat of this is that try / catch blocks do not catch low level errors.
I've seen it a few times that data in a source or destination table is different to what is expected, i.e. strange characters, text instead of integers etc. If you still can't crack it run a sql server profiler trace against the databse while you run the procedure.
It shouldn't take long to find the problem. I won't go into how to use SQL server profiler as you only need to do a quick web search to find hundreds of detailed guides.