有位很优秀的业务顾问，有时候出现问题也不想麻烦我们开发，而是自己先debug看看。
那天调用打印的时候dump了，这个让一位业务顾问debug确实太难为人家了。
然后一起聊了下我debug的步骤。这里也分享下，可能有什么不对的也欢迎指正。
针对资深ABAP来说下面的可以直接略过了哈。
1）ST22
2）ABAP EDITOR
3）光标自动定位到dump的位置，打断点
然后执行下看看，
这个时候，发现，供应商是空，（然后里面没控制好，如果供应商是空会引起dump）
4）然后看看哪儿赋值的。（当然也可以debug进来后设置观察点，这里先看看代码逻辑的好）
后来发现这里赋值的
debug的时候发现物料号是空。然后再看物料号为啥是空。
发现是这里取的物料信息
标准函数了，可以F5进去看看。但是一点儿点儿debug也挺麻烦的。
对于开发可以这么去一点儿点儿debug。也没啥问题，看看哪儿取值没取到，再分析原因。
另外，如果这个打印是个例的话，那可以考虑直接从数据下手。
对比下正常不报错的和一个dump的数据，几个关键表或者前台去看看两条数据有啥不一样。
有时候比一点儿点儿debug 标准代码更轻松一些。
回到刚才这个问题。因为在标准的取数之前，有一条sql语句
Select Single，而且用的不是主键。
所以我当时第一反应是这个sql会不会取的不对。
然后debug的时候根据这个where条件，去DB表里取了，发现真的是两条数据。
然后我debug把取到的值换成另一个，就顺利通过了。
那问题就出在这个SQL上了。
当然这个是个巧合，如有雷同纯属巧合，而且为啥觉得那句sql有问题，其实就是当时的一个直觉吧。
具体其他debug常用的内容稍后的几篇文章里再专门的写。这里就先不提了。
最后说下，刚dump的时候，可以直接点debug进去，会定位到dump的位置，然后可以看到各个参数的值。然后直接打断点点保存再执行也行。
