共计 855 个字符,预计需要花费 3 分钟才能阅读完成。
我的常识星球里有敌人发问:
se09 开释申请号报错:ended with return code :===>8<=== 这个问题该如何解决?
这是 ABAP Transport Request 开释时的一个 Generic 谬误音讯。相熟 ABAP 编程的敌人都晓得,很多 ABAP 关键字执行后,通过零碎变量 sy-subrc
的值来判断是否执行胜利,0 代表胜利,4 或者 8 代表失败。
这个零碎变量在笔者这篇 ABAP 教程里有具体介绍:
ABAP 编程语言中的零碎字段(System Fields)
ABAP 传输申请的开释也不例外。ABAP Transport Request(ABAP 传输申请)是 SAP 零碎中用于将开发人员在开发零碎中创立和批改的 ABAP 对象(例如程序、表、视图、函数模块等)从一个零碎传输到另一个零碎的一种机制。
ABAP Transport Request 的次要作用是帮忙开发人员将他们在开发零碎中创立和批改的 ABAP 对象传输到测试零碎和生产零碎中,以便在这些零碎中进行测试和应用。传输申请容许开发人员将多个相干的 ABAP 对象打包到一个独自的申请中,并将这些对象一起传输到另一个零碎中。
当传输申请从 A 零碎传输到 B 零碎后,申请内蕴含的 ABAP 对象 (比方 ABAP 类,ABAP 数据字典元素,ABAP 报表等) 须要被激活才可能失常应用。如果激活过程中出错,就会遇到 ended with return code x
的谬误音讯,此时 x 是一个大于零的整数。
引起传输申请在 B 零碎激活出错后的最常见起因,就是传输申请的依赖关系没有正确保护好。
比方申请 A 和 B,A 申请里蕴含了一个 ABAP class a,其代码应用了一张数据库表 b,而 b 被蕴含在传输申请 B 内。在理论开发过程中,申请 A 和 B 很可能是不同的开发团队负责。
假如申请 A 先开释,到了指标零碎后激活就会出错,因为在指标零碎上,class a 依赖的数据库表 b 还不存在,因为申请 B 还没有开释到指标零碎上。
应用 ABAP 事务码 SCTS_LOG
,输出呈现谬误的申请号,即可查看具体出错起因:
点击这个黄色的 眼镜图标
即可查看到对应引起谬误的起因: