点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)嗨, 我们正在做一个升级+ U...
点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)嗨, 我们正在做一个升级+ U...
加入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。
Hi Glenn,
不确定,但是我认为这与与NUMC与CHAR字段相比时lv_var的解释方向有关。
在第一种情况下,似乎从右到左比较了3个数字,而忽略了非NUM(和第4个)字符。 这样,它给您带来了成功。 并不是很干净,但是仍然很受欢迎。
在第二种情况下,从左到右比较CHAR字段; 当然,这会让您怀念。
希望如此。 如果有人知道的更好,请分享!
迈克
一周热门 更多>