AND condition fails for is initial

[former_member601402]

Hi SAP experts,

My question seems weird but this is really happening, this is the first time i encountered an issue like this.

I have a condition for e.g:

IF lw_workarea-lv_field IS INITIAL AND
    lw_workarea-lv_field_2 IS INITIAL.

The value of the workarea and their corresponding fields are:

Variable	Value	Data Type
lw_workarea-lv_field	Z0001/Z0002/	C(8192)
lw_workarea-lv_field_2		C(100)

When this is the case, system goes inside the if statement even if it should not because

lw_workarea-lv_field has value and therefore not initial.

Could this be caused by something? For e.g version? service pack? or data type?

Thanks and warmest regards,

Ryann

[matt]

It is extremely unlikely that the problem lies with versions or service pack. If AND stops working, the whole system is screwed! SAP might notice that before releasing into the wild.

So the problem must be in your code.

What is the type of lv_field and lv_field_2? Have you run in debug and verified that they do actually contain a value? Is the program active? Have you ensured that you've restarted completely your test transaction (otherwise you could be running old code, but seeing the new)?

Horrible names for variables, by the way. I hope they're just samples and not in real code!

[former_member601402]

Hi Matthew,

Both are character types with different length 8192 and 100. However,

Debugged and verified also by using go to statement, and tried to change the value as well. The only thing we haven't tried is the restart. I will try it again after the restart.

Apologies about the variable names, these are just samples.

Thanks,

Ryann

[matt]

What happens if you use EQ SPACE instead of IS INITIAL?

[former_member601402]

Hi Matthew,

I am limited only to the exact code. Since we are investigating only how is this happening.

However, i tried to create a test program and also i tried using space like lv_field EQ ''or lv_field EQ ' ' and it's behaving like INITIAL.

Thanks for the input Matt, at least we are able to test.

Warmest regards,
Ryann

[Former Member]

LV_FIELD seems long to me. Are you sure that there really is a value there?

Rob

[Former Member]

And are you sure that lv_field_2 is actually empty. It's also rather long, so you have to scroll to the right or look at portions of the field.

Rob

[former_member186746]

Hi,

Check in debugging if lw_workarea-lv_field actually has a value.

I'm guesing that you retrieve data from a 8192 character field and put that in a shorter field in such a way that the shorter field becomes empty.

Kind regards, Rob Dielemans

[former_member601402]

Hi Rob,

lw_workarea-lv_field has a value this is confirmed because we even tried to change the values. While leaving the lw_workarea-lv_field_2 empty.

Thanks,

Ryann

[Former Member]

I tried the code you posted, and it worked perfectly, so the problem is either elsewhere or, like I said LV_FIELD_2 is not empty. Try writing it to the report.

Rob

[anjaneya_bhardwaj2]

Just to make sure you may use a clear statement in initialization section of the Program to make sure none of the variables have any residual value from previous processing.

Anjan

[former_member601402]

Hi guys,

What if this is the last line of a report? Would that matter?

For e.g.

IF lw_workarea-lv_field IS INITIAL AND

    lw_workarea-lv_field_2 IS INITIAL.

  EXIT

ENDIF

the last line of code is ENDIF and therefore it will return back to the program who calls it. Yet the debugging arrow points to the EXIT instead of ENDIF. Would that matter? Because i notice that the arrow is going towards left with u turn arrow around it. Like this:

Thanks,

Ryann

[matt]

METHOD...

...

IF blah.

  EXIT.

ENDIF.

ENDMETHOD.

is obviously identical to

METHOD...

...

ENDMETHOD.

Creating a program like your fragment doesn't reveal any issues, so there must be some information lacking for the resolution of your problem.

DATA: BEGIN OF lw_workarea,

    lv_field TYPE c LENGTH 8192,

    lv_field_2 TYPE c LENGTH 100,

   END OF lw_workarea.

PERFORM test.

WRITE 'done'.

FORM test.

   lw_workarea-lv_field = 'Z0001/Z0002'.

   IF lw_workarea-lv_field IS INITIAL AND

     lw_workarea-lv_field_2 IS INITIAL.

     EXIT.

   ENDIF.

ENDFORM.    

However, it looks to me that it is as I said at the start: the code the debugger is displaying isn't the code it is running. Therefore either the code isn't active, or the latest version hasn't been loaded. We need more information about the context of the code and how you are running it.

[former_member601402]

Hi Matthew,

However, we've already tried regenerating the indexes and regenerate object. Unfortunately still the issue is happening. but there are some commented codes underneath probably will test it first.

The scope is the same with the 2nd example you provided. The context of the code is being called from a main report program which is in 2nd include.

INCLUDE ZTEST_INCLUDE1

INCLUDE ZTEST_INCLUDE2   <-- this is where the code is placed, inside this code follows the ABAP Events starting from INITIALIZATION. However the concerned code is on the lowest point of the START-OF-SELECTION.

Regards,

Ryann

[matt]

In SE38, have you established that every include is active, and that the programs containing the includes are active?

Forgetting the includes, what is the surrounding code (i.e. if you'd done it as one object not as with includes). To help further, I need to know exactly the code that is failing, I need to know the precise context. I'm not asking for a complete program listing but something that shows the structure. So far the information you have provided is insufficient.For example, it's only now that you've mentioned it's part of a report with a START-OF-SELECTION vent.