Sorted table filled but not in key sequence

[Former Member]

Hello Experts,

I have an issue with Sorted Table. The table is filled but not in the key order!!!!! Is filled like a simple append.

In my program i did the following:

I declare a type, a sorted table and i fill it with insert into.

TYPES: BEGIN OF ty_doc.

TYPES:

bukrs_d TYPE bukrs,

blart TYPE blart,

budat TYPE budat,

bldat TYPE bldat,

monat TYPE monat,

waers TYPE waers,

kursf TYPE kursf,

xblnr TYPE xblnr1,

bktxt TYPE bktxt,

xblnr_s TYPE xblnr1.

TYPES: postes LIKE bseg OCCURS 0.

TYPES: END OF ty_doc.

Data: t_doc TYPE SORTED TABLE OF ty_doc WITH NON-UNIQUE KEY

bukrs_d, blart, budat, bldat, monat, waers, kursf, xblnr,

bktxt.

I changed the data type of budat, blart, monat, waers and kursf to CHAR even so doesn't work.

Do you have any idea about this problem? Why the table is not filled in the key sequence since i declared it sorted?

Thank you in advance !!

[Former Member]

Hi

Where and how do u fill the table?

Max

[Former Member]

can you show us the data in your internal table at least..

[Former Member]

First, Thank you for your answers.

I fill my data in a Loop of an other table where I extract data.

Loop at T_FILE

CASE l_line(1).

WHEN c_1.

IF sy-tabix > 2.

INSERT wa_doc INTO TABLE pt_doc.

ENDIF.

when c_2.

...

...

ENDCASE.

AT LAST.

INSERT wa_doc INTO TABLE pt_doc.

ENDAT.

Endloop.

In the table T_file i have 3 lines like that:

OD 28102009(Date in Batch Input Format) ORACLE1

OD 28102009 ORACLE2

OD 29102009 ORACLE3

OD 28102009 ORACLE4

WIth sorted table, in the table t_doc i have:

OD 28102009 ORACLE4

OD 29102009 ORACLE3

OD 28102009 ORACLE2

OD 28102009(Date in Batch Input Format) ORACLE1

When i declare a table like a standard and i do sort, i have the result excepted

OD 28102009(Date in Batch Input Format) ORACLE1

OD 28102009 ORACLE2

OD 28102009 ORACLE4

OD 29102009 ORACLE3

So, what do you think? Thank you

[Former Member]

L_line is filled like that :

LOOP AT t_file INTO l_line.

[ThomasZloch]

I can't see the relation of the table contents you quoted to the non-unique key you have declared for the table.

You should list the table contents for the entire non-unique key, only then an analysis is possible.

Thomas

[Former Member]

Ok, it was just a simplified example (with just 3 fields) but what happends and the result are the same.

In real case, i have the T_FILE table (T_FILE i filled by READ DATASET from an incoming file in RFBIBL00 format)

1FB01 28102009ODFT202810200910EUR / / / ORACLE01 / CLAIM DECLARATION

2BBSEG 40/ // 2000,00 / / / / // /.........................

1FB01 28102009ODFT202810200910EUR / / / ORACLE02 / CLAIM

2BBSEG .................................

1FB01 29102009ODFT202910200910EUR / / / ORACLE03 / CLAIM DECLARATION

2BBSEG .................................

1FB01 28102009ODFT202810200910EUR / / / ORACLE04 / CLAIM DECLARATION

2BBSEG .................................

In my loop at T_FILE, i extract from lines 1FB01: fields: BLDAT, BUDAT, BLART, BUKRS, MONAT, WAERS, KURSF, XBLNR and BKTXT.

The table T_DOC is filled like that: Each line, fields (bukrs_d, blart, budat, etc) are filled by data extracted from lines 1FB01 and xblnrs_s i filled it after by an other functional rule. postes are filled by lines 2BBSEG. Table is filled correctly but not in the correct sequence.

The busines rule is that i must agregate documents that have the same first fields (without xblnr_s). Du a huge number of lines, for performance, i declared a sorted table (and not a standard table with sort after)

So, my t_doc is filled like that: (like an append)

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE04 | CLAIM DECLARATION

FT20 |OD |29102009|29102009|10 |EUR |0.00000 <ORACLE03 | CLAIM DECLARATION

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE02 | CLAIM

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE01 | CLAIM DECLARATION

My excpected result is like that

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE01 | CLAIM DECLARATION

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE02 | CLAIM

FT20 |OD |28102009|28102009|10 |EUR |0.00000 <ORACLE04 | CLAIM DECLARATION

FT20 |OD |29102009|29102009|10 |EUR |0.00000 <ORACLE03 | CLAIM DECLARATION

And its the result that i have with a standard table and a sort table syntaxe but not with the SORTED TABLE.

Just for history of no unique key, i have two check box in the selection screen to take into account XBLNR and BKTXT or not so if these checkbox are not marked, these field are empty (not extracted)

Thank you in advance.

Edited by: SALHI Amal on Oct 29, 2009 10:38 AM

[ThomasZloch]

From information given, I can't really figure out why the insert into the sorted table does not result in table entries sorted by the table key. However I doubt that a one time sort of a standard table takes much more time than many inserts into a sorted table...did you compare both options?

If it gives the desired result, why not switch to a standard table and a final sort statement?

Thomas

[matt]

It would be interesting to write a test program and see if we get the same results. I can't do it at the moment as I'm in a hands on session at Teched in Vienna....

If it can be duplicated, then I'd propose that it gets escalalted to SAP.

matt

[Former Member]

I wrote a program that tested this and the results weren't what I expected. Not sure of the reason, but it might be helpful to remove the deep structure and try again.

Rob

[Former Member]

Thank you for you all.

Thomas, i didn't compare both options !! Just as i know.

Rob, can you explain me what program you have tested? and what is the result?

What deep structure i must remove?

[SuhaSaha]

Hello,

In the TYPES declaration remove/comment :

TYPES: postes LIKE bseg OCCURS 0.

BR,

Suhas

[Former Member]

Thank you Suhas.

But, is the structure that i want. One Field as a table !!

Each account document has many items !!

So, i understand you doubt that the error is from this complicated structure?

But the sorted is done by the key. In my case the key is the flats fields.

Edited by: SALHI Amal on Oct 29, 2009 6:23 PM

[Former Member]

Yes - but let's see if that's the source of the problem. As a test, try removing it and populating the rest of the structure and table as usual. If it comes in the same random sequence, you know that is not the source. If it comes in the correct sequence, you know where to look.

Rob

[SuhaSaha]

Hello Rob,

My gut feeling tells that the Deep Structure must be the cause.

Lets have the results & then we can speculate ...

BR,

Suhas

[Former Member]

unfortunately, the result is the same

[former_member609379]

Helllo...this is the first time I post here...I am hoping it is not a useless post

I could not reproduce your issue, I created a quick test program and verified that the deep structure is not the problem. Can it be a data issue?

My code is as follow (the data I am pulling from VBSEGK does not correspond to the data I am pulling from BKPF, I know, I just wanted to populate the MYBSEG field.)

types: begin of ty_bkpf,
         bukrs like bkpf-bukrs,
         belnr like bkpf-belnr,
         blart like bkpf-blart,
         budat like bkpf-budat,
         bldat like bkpf-bldat,
         monat like bkpf-monat,
         waers like bkpf-waers,
         kursf like bkpf-kursf,
         xblnr like bkpf-xblnr,
         bktxt like bkpf-bktxt,
         xblnr_alt like bkpf-xblnr_alt,
         mybseg like vbsegk occurs 0,
       end of ty_bkpf.

data: lit_bkpf type sorted table of ty_bkpf with non-unique key
               bukrs belnr blart bldat monat waers kursf xblnr bktxt,
      l_bkpf like line of lit_bkpf.

start-of-selection.

  select bukrs
         belnr
         blart
         budat
         bldat
         monat
         waers
         kursf
         xblnr
         bktxt
         xblnr_alt
    into corresponding fields of l_bkpf
    up to 100 rows
    from bkpf
    where gjahr eq '2010' and
          xblnr_alt ne space.

    select *
      into table l_bkpf-mybseg
      from vbsegk
      where belnr eq l_bkpf-belnr.

    insert l_bkpf into table lit_bkpf.
  endselect.

[Former Member]

Moderator message - Welcome to SCN.

Not at all useless - but please use the code tags when posting code ( the button with the "<" ">" above the window where you post your reply.

Rob

[Clemenss]

Hi hpalma1,

please learn how to post code - this is really not readable.

You declared lit_bkpf table but you select * into table l_bkpf-mybseg. What is table l_bkpf-mybseg?

This is not your code, is it?

Regards,

Clemens

[former_member609379]

Hi Clemens,

My post is not intended to open a can of worms, it is intended to help. It IS my code, not sure what makes you think otherwise.

I have already been told that I should post source code in a different way (Thanks Rob!) and I will do next time I post.

Please do not allow my post to distract your attention to the initial and really important question. Ignore my post if it does not help you.

Thanks,

Hugo.

[matt]

I've edited the code so that it is more readable now. You just surround any ABAP fragments with

matt

[Former Member]

I think the problem is how you have defined the table key.

Your message lists your code for this as:

Data: t_doc TYPE SORTED TABLE OF ty_doc WITH NON-UNIQUE KEY
bukrs_d, blart, budat, bldat, monat, waers, kursf, xblnr,
bktxt.

try removing the commas:

DATA t_doc TYPE SORTED TABLE OF ty_doc WITH NON-UNIQUE KEY
         bukrs_d blart budat bldat monat
         waers kursf xblnr bktxt.

You are actually defining a key of only bukrs_d, then the rest listed are defined as single character fields because of the colon after the word Data.

Andrew

[matt]

Andrew - you're a genius. I can't believe I didn't spot that.

Of course:

Data: t_doc TYPE SORTED TABLE OF ty_doc WITH NON-UNIQUE KEY
bukrs_d, blart, budat, bldat, monat, waers, kursf, xblnr,
bktxt.

is exactly equivalent to:

data t_doc TYPE SORTED TABLE OF ty_doc WITH NON-UNIQUE KEY bukrs_d.
data blart.
data budat.

etc.

[SuhaSaha]

Hello Matt,

I have been analysing the same for over an hour.

I have gone mad asking why the hell this is happening ?

Good Work Andrew, 10 p*ints to you from me ...

BR,

Suhas

[Former Member]

Gowrsh - I feel like such an idiom!

But now that I think of it, I recall a similar problem quite a while ago. Someone posted a question siomething like:

> The following statement has been running for hours. What should I do?

 UPDATE (some large, important, standard SAP table)
   SET (some fields)
   WHERE: (some condition),
            (some other condition),
            (another condition).

The first condition was enough to update every record in the table. As I recall, it was cancelled and rolled back.

Rob

[matt]

I knew a very experienced programmer who was caught with that specific bit of syntax. Because the example you give there is the example that used to be in the ABAP Help!

Thankfully it's gone now.

matt

[Former Member]

Thank you for all of you. I'm agree with Matt, you're a genius Andrew (I owe you a coffee:)).

I'm so stupid, I didn't notice that at all!

10 points !!

Edited by: SALHI Amal on Oct 30, 2009 4:09 PM

[former_member609379]

Wow, Andrew, very good catch! I did not notice that either