READ语句比较CHAR和NUMC字段

2020-08-30 21:45发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


嗨,

我们正在做一个升级+ Unicode转换项目,在测试Z程序期间,我们注意到差异是由于SAP标准域(KOTABNR)将数据类型从NUMC更改为CHAR。 字段长度为3个字符。

该元素在Z表中用作字段COND_TAB。 作为内部表读入程序的Z表,其内部结构与Z表相同。 由于某种原因,该程序的开发人员已在该内部表的READ语句中使用的程序中定义了CHAR4变量。

因此,内部表具有一个定义为NUMC3的字段,其中包含值304。我们正在执行READ语句,其操作数为'A304'。 所以基本上是这样的。

使用键COND_TAB ='A304'将表Zxxxx读入wa。

在我们尚未升级的生产系统(COND_TAB是NUMC3字段)中,此READ语句的subrc = 0。

在我们升级的测试系统中,在SAP更改了KOTABNR域之后,字段COND_TAB现在是CHAR3字段。

相同的READ语句现在导致subrc = 4。

因此,使用CHAR4操作数(值'A304')执行READ语句时,将其与值'304'的NUMC3字段匹配时会命中,而对于值相同的'304'的CHAR3字段则不会匹配。

我在升级后的系统中做了一个小测试(下面的程序),看这是否是由于升级本身引起的,但发现并非如此。 即使在升级的740系统上测试了两个版本,该系统在CHAR/NUMC问题上的行为也完全相同。

有人可以向我解释这种行为背后的原因吗? 当304在NUMC3字段中而不在CHAR3字段中时,为什么A304等于304?

最诚挚的问候,

格伦

报告zxxx。

 数据:lv_var TYPE char4。

 lv_var ='A304'。

 **情况1-使用CHAR4运算符读取NUMC3表字段

 类型:开始于ty_test1,
          field1 TYPE char4,
          field2 TYPE numc3,
        ty_test1结束。

 数据:ty_test1的lt_table1类型表,
      wa1类型ty_test1。
 字段符号:类型ty_test1。

 wa1-field1 ='XXXX'。
 wa1-field2 ='304'。
 将wa1附加到lt_table1。

 读取表lt_table1分配
   WITH KEY field2 = lv_var。

 如果sy-subrc EQ 0。
   写:/1'分配了字段符号1'。
 其他。
   写:/1'未分配字段符号1'。
 万一。

 **情况2-使用CHAR4运算符读取CHAR3表字段

 类型:开始于ty_test2,
          field1 TYPE char4,
          field2 TYPE CHAR3,
        ty_test2结束。

 数据:ty_test2的lt_table2 TYPE TABLE,
       wa2 TYPE ty_test2。

 字段符号:类型ty_test2。

 wa2-field1 ='XXXX'。
 wa2-field2 ='304'。
 将wa2附加到lt_table2。

 读取表lt_table2分配
   WITH KEY field2 = lv_var。

 如果sy-subrc EQ 0。
   写:/1'分配了字段符号2'。
 其他。
   写:/1'未分配字段符号2'。
 ENDIF。

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


嗨,

我们正在做一个升级+ Unicode转换项目,在测试Z程序期间,我们注意到差异是由于SAP标准域(KOTABNR)将数据类型从NUMC更改为CHAR。 字段长度为3个字符。

该元素在Z表中用作字段COND_TAB。 作为内部表读入程序的Z表,其内部结构与Z表相同。 由于某种原因,该程序的开发人员已在该内部表的READ语句中使用的程序中定义了CHAR4变量。

因此,内部表具有一个定义为NUMC3的字段,其中包含值304。我们正在执行READ语句,其操作数为'A304'。 所以基本上是这样的。

使用键COND_TAB ='A304'将表Zxxxx读入wa。

在我们尚未升级的生产系统(COND_TAB是NUMC3字段)中,此READ语句的subrc = 0。

在我们升级的测试系统中,在SAP更改了KOTABNR域之后,字段COND_TAB现在是CHAR3字段。

相同的READ语句现在导致subrc = 4。

因此,使用CHAR4操作数(值'A304')执行READ语句时,将其与值'304'的NUMC3字段匹配时会命中,而对于值相同的'304'的CHAR3字段则不会匹配。

我在升级后的系统中做了一个小测试(下面的程序),看这是否是由于升级本身引起的,但发现并非如此。 即使在升级的740系统上测试了两个版本,该系统在CHAR/NUMC问题上的行为也完全相同。

有人可以向我解释这种行为背后的原因吗? 当304在NUMC3字段中而不在CHAR3字段中时,为什么A304等于304?

最诚挚的问候,

格伦

报告zxxx。

 数据:lv_var TYPE char4。

 lv_var ='A304'。

 **情况1-使用CHAR4运算符读取NUMC3表字段

 类型:开始于ty_test1,
          field1 TYPE char4,
          field2 TYPE numc3,
        ty_test1结束。

 数据:ty_test1的lt_table1类型表,
      wa1类型ty_test1。
 字段符号:类型ty_test1。

 wa1-field1 ='XXXX'。
 wa1-field2 ='304'。
 将wa1附加到lt_table1。

 读取表lt_table1分配
   WITH KEY field2 = lv_var。

 如果sy-subrc EQ 0。
   写:/1'分配了字段符号1'。
 其他。
   写:/1'未分配字段符号1'。
 万一。

 **情况2-使用CHAR4运算符读取CHAR3表字段

 类型:开始于ty_test2,
          field1 TYPE char4,
          field2 TYPE CHAR3,
        ty_test2结束。

 数据:ty_test2的lt_table2 TYPE TABLE,
       wa2 TYPE ty_test2。

 字段符号:类型ty_test2。

 wa2-field1 ='XXXX'。
 wa2-field2 ='304'。
 将wa2附加到lt_table2。

 读取表lt_table2分配
   WITH KEY field2 = lv_var。

 如果sy-subrc EQ 0。
   写:/1'分配了字段符号2'。
 其他。
   写:/1'未分配字段符号2'。
 ENDIF。
付费偷看设置
发送
3条回答
骆驼绵羊
1楼 · 2020-08-30 22:06.采纳回答

ABAP文档中对此进行了解释:

读取表-free_key :" 如有必要,在比较之前将操作数的内容转换为组件的数据类型"

转换 CHAR 4(" A304")到NUMC 3(" 304")的解释如下:

基本数据对象的转换规则-▶源字段类型c-▶类似于字符的目标字段-▶N :" 源字段中的字符 代表数字的数字将右对齐传递到目标字段,其他字符将被忽略。如果目标字段长于源字段中的位数,则在左侧用字符" 0"填充。 字段较短,则在左侧剪掉字符。

蓋茨
2楼-- · 2020-08-30 22:03

Hi Glenn,

不确定,但是我认为这与与NUMC与CHAR字段相比时lv_var的解释方向有关。

在第一种情况下,似乎从右到左比较了3个数字,而忽略了非NUM(和第4个)字符。 这样,它给您带来了成功。 并不是很干净,但是仍然很受欢迎。

在第二种情况下,从左到右比较CHAR字段; 当然,这会让您怀念。

希望如此。 如果有人知道的更好,请分享!
迈克

哎,真难
3楼-- · 2020-08-30 22:23

感谢您的回答。

/格伦

一周热门 更多>