Не срабатывает поле WHERE в SELECT. Что за карамба?

lumer

Следующий код без WHERE корректно возвращает всю таблицу, а с WHERE: sy-subrc = 4, число записей ессно = 0. Просмотр содержимого таблицы показывает что поле uploaded пустое. Что за чудеса?

Код:

Code:

  SELECT *
    FROM ztable
    INTO CORRESPONDING FIELDS OF TABLE it_ztab
    WHERE
      UPLOADED NE 'X'.

Удав

Прекрасно все работает.

Code:

ZTABLE   
Test     
--------
MANDT    MANDT
VBELN    VBELN_VA
UPLOADED    CHAR1

Содержимое:
MANDT VBELN      UPLOADED 
098   1111111111          
098   2222222222          
098   3333333333 X        
098   4444444444          

программа
REPORT  z_get_ztable                            .

DATA: it_table TYPE STANDARD TABLE OF ztable WITH HEADER LINE.
END-OF-SELECTION.
  SELECT *
  INTO TABLE it_table
  FROM ztable
  WHERE uploaded NE 'X'.

  LOOP AT it_table.
    WRITE: / it_table-vbeln, '|', it_table-uploaded.
  ENDLOOP.

Результат
Test ztable           
                      
1111111111            
2222222222            
4444444444    
        

Как объявлена внутренняя таблица?

holocron

lumer написал:

Следующий код без WHERE корректно возвращает всю таблицу, а с WHERE: sy-subrc = 4, число записей ессно = 0. Просмотр содержимого таблицы показывает что поле uploaded пустое. Что за чудеса?

Код:

Code:

  SELECT *
    FROM ztable
    INTO CORRESPONDING FIELDS OF TABLE it_ztab
    WHERE
      UPLOADED NE 'X'.

иногда "глюки" имеют место, если это новое поле в таблице, т.е. оно добавлено после внесения в таблицу данных. Причем в определении поля в таблице не стоит галка "начальные значения". если ситуация не такая - увы..

Удав

holocorn написал(а):

новое поле в таблице, т.е. оно добавлено после внесения в таблицу данных.

А программа тогда скомпилируется?

sibrin

Удав написал(а):

А программа тогда скомпилируется?

Просто в базу данных попадает "undef".
undef <> 'X' = undef.

Компиляция смотрит только на словарь данных, а не на описание таблицы в БД, и уж тем более не на то, что там в ней заполнено.

John Doe

holocron написал(а):

иногда "глюки" имеют место, если это новое поле в таблице, т.е. оно добавлено после внесения в таблицу данных. Причем в определении поля в таблице не стоит галка "начальные значения". если ситуация не такая - увы..

Я тоже поддержу. Сделайте, на всякий случай, выравнивание данных по таблице и буфера скиньте тоже. Последнее - просто шаманский пасс...

Удав

sibrin написал:

Просто в базу данных попадает "undef".
undef <> 'X' = undef.

Это как сказать.
Oracle с R/3 работает таким образом, что в БД никода не будет поля со значением undef. Или пробел(хотя бы один) - в случае символьного поля), или 0 - в случае I, D или F.
На всякий случай можно запустить утилиту БД для активации, но как правило при добавлении полей этого не требуется.

Удав

John Doe написал:

Последнее - просто шаманский пасс...

Или просто молитву прочитать

)

John Doe

Удав написал(а):

На всякий случай можно запустить утилиту БД для активации, но как правило при добавлении полей этого не требуется.

Собсно о чем мы с holocron и писали (по крайней мере я так понял). Активировать с выравниванием уже существующих данных.

Удав

Обычно утилита базы данных нужна при изменении состава ключевых полей или при удалении полей.
При добавлении полей в 99 % случаев ее применять не надо :wink:

Alex80

Удав написал(а):

Oracle с R/3 работает таким образом, что в БД никода не будет поля со значением undef. Или пробел(хотя бы один) - в случае символьного поля), или 0 - в случае I, D или F.
На всякий случай можно запустить утилиту БД для активации, но как правило при добавлении полей этого не требуется.

Не согласен. Уже наступлено на грабли и проверено не мной одним. Точно на Oracle и точно на R/3.
Или писать:

Code:

SELECT * 
    FROM ztable 
    INTO CORRESPONDING FIELDS OF TABLE it_ztab 
    WHERE 
      UPLOADED NE 'X'
OR UPLOADED IS NULL.

или ставить индикатор инициации поля.

sibrin написал:

Просто в базу данных попадает "undef".
undef <> 'X' = undef.

+1

Цитата:

NULL values in the database
If new fields are inserted in or added to transparent tables in the ABAP Dictionary, the fields are added to the database by means of an ALTER TABLE ADD FIELD <field name>..... .

The values for these new fields are undefined (NULL value in the database), so long as nothing else was specified. This status does not cause any problems, provided the new fields are not selected.

Example: The numeric field <newfield> was added to a table TAB. If you access this table with

'SELECT ... FROM TAB WHERE <newfield> <> 5 ...'

records with NULL values in <newfield> are not found, although they logically satisfy the WHERE condition of the SELECT (since the new column contains only NULL values). The cause of this is the NULL value behavior of the database systems.

If the newly added columns are to be selected in this way, the new field must be created at ADD FIELD with an initial value (force NOT NULL). In this case, the situation shown in the above example could not occur, since fields filled with an initial value could be selected correctly.

ArmAnn

Удав написал(а):

Oracle с R/3 работает таким образом, что в БД никода не будет поля со значением undef. Или пробел(хотя бы один) - в случае символьного поля), или 0 - в случае I, D или F.

Может вы и правы.
Но я как то наступал на грабли с неинициализированным значением поля (NULL) после добавления в таблицу именно на оракловой базе

lumer

Сенкс ответившим. Да, ситуация именно такая - добавили новое поле.
Добавка

Code:

OR UPLOADED IS NULL

все вылечила.

ArmAnn

lumer написал:

Сенкс ответившим. Да, ситуация именно такая - добавили новое поле.
Добавка

Code:

OR UPLOADED IS NULL

все вылечила.

Все таки проинициализируйте. А то мало ли, будет другой человек запрос писать к вашей таблице - и опять вопрос здесь увидим

Правила форума

Не срабатывает поле WHERE в SELECT. Что за карамба?

Кто сейчас на конференции