Problem when calling a method from an include program

[luis_rod]

Hi all,

I have a problem with a method call that has me, to say the least, perplexed.

The method is very simple. It receives a single parameter (table name) and returns a date:

  METHOD ultima_fecha_pbi.
    "--------------------------------------------------------------------*
    "  CLASS-METHODS GET_ULTIMA_FECHA_PBI
    "  IMPORTING
    "     !TABLA TYPE ANY
    "     returning
    "     VALUE(ULTIMA_FECHA) TYPE LASDA .
    "--------------------------------------------------------------------*
    SELECT SINGLE ultima_fecha FROM zlog_tablas_pbi
      WHERE tabla = @tabla  "<------ Table name
      INTO @ultima_fecha.   "<------ Date
  ENDMETHOD.

When called from a simple test program (no includes), the method works perfectly, i.e., returns the data as expected.

CONSTANTS c_tabla_sap TYPE string VALUE 'ZLISFACT'.  "<-- Table name
DATA g_ultima_fecha   TYPE dats.                     "<-- date

PERFORM buscar_ultima_fecha USING    c_tabla_sap
                            CHANGING g_ultima_fecha.
"-------------------------------------------------------------------
FORM buscar_ultima_fecha USING    nombre_tabla   TYPE any
                         CHANGING p_ultima_fecha TYPE dats.
  p_ultima_fecha = zcl_pbi=>ultima_fecha_pbi( tabla = nombre_tabla ).
ENDFORM.

If I check the data just after the SELECT (using debug) I get:

  TABLA = ZLISFACT (Table name - Data type CString{8})
  HEX = 5A004C00490053004600410043005400

So far, so good but, if I call exactly the same method with the same parameters (and using exactly the same FORM) from a report program with includes, the SELECT returns SY-SUBRC 4, even though the data (seen using debug) appears to be the same:

TABLA =  ZLISFACT
HEX = 5A004C00490053004600410043005400

Any ideas?

TIA,

Luis

[Sandra_Rossi]

Make sure that you call the method from the same client and same system. Ask a fellow developer to look at it, it's obviously something you didn't pay attention to (classic issue which happens to everybody).

Also, you're talking about SY-SUBRC instead of looking at ULTIMA_FECHA, so maybe you're looking at SY-SUBRC after the method call in your test program (but not in your program with includes), which is always reset to 0 "when executing ENDMETHOD" (see the ABAP documentation concerning method calls).

[luis_rod]

Sandra:

Thanks for your post. I’m quite sure that I’m using the same client (have my clients coded by color, BTW).

About using a fellow developer have a look at the problem, will try to do so. Unfortunately, I haven’t been able to get them to use those new constructs (Methods) 🙂 .

I checked both, SY_SUBRC and the data value stepping thru the method (debug). What I don’t get is why when calling the method from the program with includes (which, unfortunately was written by another developer, in order to muddle the things a little bit more) I get different results.

BTW, I added a comment to your recent post about using AI to document a program. If you have the time check it out.

Thanks again.

[Sandra_Rossi]

For sure, it's not related to includes if just this one SELECT statement is concerned, so please forget it (except if you have posted a code different from the actual one). The last possibility is that there's a "DELETE FROM zlisfact" or "UPDATE zlisfact" (changing TABLA) during the report execution (easy to check with the SQL trace).

[raymond_giuseppi]

IMHO your method should return an exception or a returned error field when the select is not successful. 'sy-subrc' is not the correct solution there (Evaluate system fields in the correct place) 

[luis_rod]

Raymond: The SY-SUBRC referenced to was checked when debugging the method. If the record is not found, the method returns the INITIAL value for the date (intended value).

[raymond_giuseppi]

By raising an exception if no record found, you could easily distinguish between cases where the record does not exist and those where the extracted zone is initial.

[luis_rod]

Raymond,

Thank you for your post.

I agree that, in most instances, raising an exception is the best approach.

However, in this particular method, returning either an initial value or a date related to the indicated table name is the most appropriate result. This method returns a “last processed” date. The idea is to use it in a code roughly similar to this (pseudo code):

last_date = zcl_pbi=>ultima_fecha_pbi( tabla = 'TABLE_TO_BE_PROCESSED' ).

SELECT * FROM TABLE_TO_BE_PROCESSED 
  WHERE table_date >= @last_date
  INTO CORRESPONDING FIELDS OF TABLE(itab).
  " DO WHAT YOU NEED....
  " END OF TABLE PROCESS
  zcl_pbi=>update_last_date( date = last_date table = 'TABLE_TO_BE_PROCESSED' ).

Best Regards,

Luis

[luis_rod · Accepted solution]

All,

Ok. For reasons unknown, this table had two (02) key fields: The table name (tabla TYPE TABLENAME_TEXT) and a TIMESTAMP field. BUT, it just happens that the TIMESTAMP field was written / updated ALWAYS as blank (please, don’t ask), so the SELECT was made using only the table name in the WHERE clause.

So, after a little digging around and seeing that no one else was using this table, it was decided to remove this column and adjust the table with SE14. Problem solved!! The record appeared “magically”…

I’m going to file this between “Twilight Zone” and The Journal of Irreproducible Results and consider the problem closed (juggling a lot of programs right now, so I can’t invest more time on this thing).

Thanks to all of you for your comments and help. Really appreciated.

[Sandra_Rossi · Accepted solution]

"Magic" is when one doesn't understand what's going on. Alas, now we can't know what the real cause was 😞

[luis_rod · Accepted solution]

Sandra:

I would have loved to know the cause of this problem. I tried different approaches, including performing a `SELECT * FROM PROBLEM_TABLE INTO @DATA(itab)` just before the method’s `SELECT`, but the desired record did not appear.

The use of SE14 was unrelated to the issue. Unfortunately, work pressures prevent me from spending more time solving this mystery.

Best Regards,

Luis

[MBartsch71]

I guess you have here a problem with mutable variables.

When I look at the code it is very inconsistent with the use of global variables, static methods and performs.

Why you don't try to clean code this.

Maybe it will also help, if we see a bit more from the code, especially the second call, where you get the differing results.