cancel
Showing results for 
Search instead for 
Did you mean: 

R3ta: ERROR: WHERE clause for object ACCTCR longer than 1024

Former Member
0 Kudos

When trying to split huge tables using R3ta I get an error message during the export:

/usr/sap/P01/SYS/exe/run/R3load -e ACCTCR-2.cmd -datacodepage 4103 -l ACCTCR-2.log -loadprocedure fast 

(DB) INFO: connected to DB
(DB) INFO: Read hintfile: /edvinst/sap/P01_MSS_28072010/ABAP/DATA/ACCTCR-2.WHR
(GSI) INFO: dbname   = "P01                                                                                "
(GSI) INFO: vname    = "ADABAS D                        "
(GSI) INFO: hostname = "XXXXXXXXX "
(GSI) INFO: sysname  = "Linux"
(GSI) INFO: nodename = "XXXXXXXXX"
(GSI) INFO: release  = "2.6.16.54-0.2.5-smp"
(GSI) INFO: version  = "#1 SMP Mon Jan 21 13:29:51 UTC 2008"
(GSI) INFO: machine  = "x86_64"
(GSI) INFO: instno   = "00000000000"
(TSK) ERROR: WHERE clause for object ACCTCR longer than 1024
(DB) INFO: disconnected from DB

The Where-clause, that was generated using R3ta looks like

tab: ACCTCR
WHERE 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF > 'MKPF 49009' AND AWREF < 'MKPF 49036') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49009' AND AWORG > '4900951771') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49009' AND AWORG = '4900951771' AND POSNR > '2004') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49009' AND AWORG = '4900951771' AND POSNR = '2004' AND CURTP > '00') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49009' AND AWORG = '4900951771' AND POSNR = '2004' AND CURTP = '00' AND WAERS >= '10EUR') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49036' AND AWORG < '4903634514') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49036' AND AWORG = '4903634514' AND POSNR < '2006') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49036' AND AWORG = '4903634514' AND POSNR = '2006' AND CURTP < '00') OR 
( MANDT = '100' AND AWTYP = '100MK' AND AWREF = 'MKPF 49036' AND AWORG = '4903634514' AND POSNR = '2006' AND CURTP = '00' AND WAERS < '30EUR')

To me it seems that this error message is coming from R3load and not from the database, right? If no, is there any database parameter that can be changed to allow a where clause > 1024 characters?

An OSS call (627945/2010) was also created.

Markus

Accepted Solutions (0)

Answers (1)

Answers (1)

boobboo
Contributor
0 Kudos

Markus,

Did you ever get an answer on this as I have the exact same problem and have not been able to find a resolution to it.

I have also raised a message regarding it.

Thanks

Chris

markus_doehr2
Active Contributor
0 Kudos

Hi Chris,

yes, I got an answer - and a patched R3load which accepts WHERE clauses up to 4096 chars. But now I have a likewise problem with other tables:

/usr/sap/P01/SYS/exe/run/R3load: sccsid @(#) $Id: //bas/701_REL/src/R3ld/R3load/R3ldmain.c#8 $ SAP
/usr/sap/P01/SYS/exe/run/R3load: version R7.01/V1.4 [UNICODE]
Compiled Aug  9 2010 09:41:03
/usr/sap/P01/SYS/exe/run/R3load -e VAPMA-2.cmd -datacodepage 4103 -l VAPMA-2.log -loadprocedure FAST -mer
ge_bck -nolog

(DB) INFO: connected to DB
(DB) INFO: Read hintfile: /edvinst/sap/P01_MSS_12082010/ABAP/DATA/VAPMA-2.WHR
(GSI) INFO: dbname   = "P01
                                               "
(GSI) INFO: vname    = "ADABAS D                        "
(GSI) INFO: hostname = "aubir3p1                                                        "
(GSI) INFO: sysname  = "Linux"
(GSI) INFO: nodename = "aubir3p1"
(GSI) INFO: release  = "2.6.16.54-0.2.5-smp"
(GSI) INFO: version  = "#1 SMP Mon Jan 21 13:29:51 UTC 2008"
(GSI) INFO: machine  = "x86_64"
(GSI) INFO: instno   = "0020080714"
(TSK) ERROR: WHERE clause for object VAPMA longer than 4096
(DB) INFO: disconnected from DB

So the problem is not yet solved. The patch for the the 1024 limit is not yet in the mainline patches and I'm waiting for an answer now.

Markus

boobboo
Contributor
0 Kudos

Markus,

Thanks for the info, I also have a query out with SAP regarding this, sounds like we're probably trying to do too much in the WHR statements

Are you building your WHR clauses based upon the primary keys for the split tables?

Also have you had any issues in doing a DistMon based parallel Export/Import, my automatic processes do not seem to be performing the table imports.

Thanks

Chris

markus_doehr2
Active Contributor
0 Kudos

> Thanks for the info, I also have a query out with SAP regarding this, sounds like we're probably trying to do too much in the WHR statements

MaxDB supports statements of 128 kb of length, so a 4096 character WHR statement shouldn't be an issue.

> Are you building your WHR clauses based upon the primary keys for the split tables?

The newest R3ta doesn't use R3ta_hints.txt any more but finds out the field by itself (on MaxDB). On our test runs R3ta core dumped when R3ta_hints.txt was used so we had to rename it.

> Also have you had any issues in doing a DistMon based parallel Export/Import, my automatic processes do not seem to be performing the table imports.

I'm not using distmon, the export machine is rather big (16 CPUs and 128 GB memory) so I run that all locally on the database server itself.

Markus