我已经使用SQL几年了，主要是MySQL / PhpMyAdmin，最近还有Oracle / iSqlPlus和PL / SQL。我已用PHP，Java，ActionScript等编程。我意识到SQL不像其他语言那样是命令式编程语言 - 但为什么错误消息在SQL中看起来不太具体？在其他环境中，我直接指出了问题的根源。更常见的情况是，MySQL给了我错误，如“错误AROUND where u.id = ...”并打印整个查询。对于存储过程来说，这更加困难，因为调试可能是一场彻头彻尾的噩梦。
我错过了一个神奇的工具/语言/插件/设置，可以提供更好的错误报告，还是我们坚持这个？我想要一个调试器或语言，它在设置断点和踩代码时给了我与Eclipse相同的控制权。这可能吗？
答案 0 :(得分：7)
我认为答案在于SQL是一种基于集合的语言，附带了一些程序性的东西。由于设计师正在考虑基于集合的术语，他们并不认为其他语言的普通调试类型很重要。但是，我认为其中一些正在改变。您可以在SQL Server 2008中设置断点。我没有真正使用它，因为您必须拥有SQL Server 2008数据库才能工作，而我们的大多数仍然是SQL Server 2000.但它可用，它确实允许您单步执行的东西。当select语句长度为150行时，你仍然会遇到问题，并且它知道语法不正确但它无法准确指出所有命令的确切位置。
就个人而言，当我编写一个长程序SP时，我构建了一个测试模式，其中包括向我展示我所做事情的结果，在我感兴趣的特定点上的关键变量的值，以及让我的打印标记知道已经完成了哪些步骤，然后在完成后将整个过程推回去。这样我可以看到如果它运行真实会发生什么，但如果我弄错了，就不会伤害数据库中的任何数据。我发现这非常有用。它可以大大增加你的proc的大小。我有一个我使用的模板，其中包含我需要设置的大部分结构，所以它并不需要我太长时间。特别是因为我从不添加插入物。更新或删除到proc而不先测试相关的选择，以确保我有我想要的记录。
答案 1 :(得分：4)
我认为解释是“常规”语言的个别语句比SQL小得多，因此单语句粒度指向其中的代码比SQL中的小得多。单个SQL语句的长度可以是一页或更多;在其他语言中，它通常是一行。
我认为这不会使调试器/ IDE无法更精确地识别错误，但我怀疑这会使其更难。
答案 2 :(得分：1)
我同意你的投诉。
构建一个好的日志框架并在你的sprocs中过度使用它对我来说是最好的。
在每个事务或重要逻辑之前和之后，我将sproc名称，步时间戳和rowcount（如果相关）写出到我的日志表中。我发现当我这样做时，我通常可以在几分钟内缩小问题点。
将一个调试参数添加到sproc（默认为“N”）并将其传递给它调用的任何其他sprocs，以便您可以轻松打开或关闭日志记录。
答案 3 :(得分：1)
对于断点和单步执行代码，您可以使用MS SQL Server执行此操作（在我看来，它在2005年以上比在2000年更容易）。
对于简单的情况，早期的开发调试，有时神秘的消息通常足以让错误得到解决 - 语法错误，不能用Y做X.如果我在一个艰难的sproc中，我会在sproc文本上恢复“printf debugging”，因为它快速而简单。在选择了您的数据库一段时间后，简单的问题就变成了旧问题，你只需要大步迈进。
然而，一旦代码发布，问题的复杂性就太高了。如果我可以重现它们，我认为自己很幸运。另外，我这里的开发人员想要调试器的地方就是DBA，他说：“你决定不把调试器放在那里。”
答案 4 :(得分：0)