хм...может быть

ORACLE 8.1.6.0.0 у меня...
у кого как?

БД здесь ни причем. Open SQL обрабатывает SAP: преобразовывает его в Native SQL, и уже затем в таком виде передает в БД.

Так-то оно так, но алгоритм преобразования Open SQL в Native SQL зависит от БД. Поэтому вполне возможна ситуация, когда "что для MS хорошо, то для Oracle - смерть". И в этой ситуации SAP может рисовать дамп для одной БД и не рисовать для другой.
У меня, например, тоже Oracle стоит.

По идее, все рэнджесы раскладываются в элементарные условия вида
"(FIELD1 = VALUE 1 OR FIELD1 BETWEEN VALUE2 AND VALUE3 OR FIELD1 > VALUE4) AND NOT FIELD1 = VALUE5".
Версия БД вроде бы не должна иметь значения, т.к. синтаксис SQL используется базовый.

Но у меня БД - MS SQL.

Почти правда. Рейндж разложится в простые условия, только соединены они будут не по AND а OR. За счет этого могут быть кое-какие не очень приятные спецэфекты
СУБД в таком разрезе несколько непричем

У меня они и связаны по OR.
Положительные условия связываются между собой, конечно, по OR.
А вот с отрицательными вся совокупность положительных условий связывается по AND. И между собой, понятно, отрицательные связываются по AND.
RANGES - интервал.
Имеет место быть сложение множеств значений. Одни значения прибавляются, другие вычитаются - получаем итоговое множество значений.
"Значение поля лежит либо в интервале А, либо в интервале В, но не в интервале С и не в интервале D".

всё это интересно и познавательно...однако какая то причина должна быть

для своего случая , в качестве альтернативы воспользовался
generate subroutine pool ...
где и генерирую нужный мне селект. правда , это вроде как более громоздко , но работает.

Фига. Все строчки в рейндже объединяются по OR вне зависимости от наличия NOT и в объединение дают единое условие. Можешь проверить.

Сам-то пробовал?
Много, конечно, в SAPе маразма встречается. Но до такого даже они не додумались. Логически подумай - какой был бы смысл в рэйнджесах, если бы все условия без разбора соединялись по OR?

Пробуй, проверяй, наслаждайся.
===================
SE16
Таблица TSTCT (первая попавшаяся).
Транзакция ST05 - включаем SQL-трассировку этой таблицы.
В SE16 для поля TCODE набираем следующее ограничение:

SIGN = 'I'.
AAAAAAAAAAAAAAAAAAAA - FFFFFFFFFFFFFFFFFFFFFFFF
GGGGGGGGGGGGGGGGGG - ZZZZZZZZZZZZZZZZZ

Добавляем отрицательных условий (SIGN = 'E')
FFFFFFFFFFFFFFFFFFFFFFFFFFF
EEEEEEEEEEEEEEEEEEEEEEE

Делаем выборку.
Идем в трассировщик, смотрим трэйс и наслаждаемся:
================================
SQL Statement

SELECT
"SPRSL" AS c ,"TCODE" AS c ,"TTEXT" AS c
FROM
"TSTCT"
WHERE
( "TCODE" BETWEEN @P000 AND @P001 OR "TCODE" BETWEEN @P002 AND @P003 ) AND
NOT "TCODE" IN ( @P004 , @P005 ) /* R3:/1BCDWB/DBTSTCT:1179 */ /*Dynamic
SQL statement no cursor, upto 200, conn. 0:2*/

Variable

A0(CH,20) = GGGGGGGGGGGGGGGGGGGG
A1(CH,20) = ZZZZZZZZZZZZZZZZZZZZ
A2(CH,20) = AAAAAAAAAAAAAAAAAAAA
A3(CH,20) = FFFFFFFFFFFFFFFFFFFF
A4(CH,20) = EEEEEEEEEEEEEEEEEEEE
A5(CH,20) = FFFFFFFFFFFFFFFFFFFF

Ха.. Это не условие NOT, это операция исключения. Просто о разных вещах говорили. Я имел ввиду. что при использовании операторов OPTION = 'NE' и прочее фигня может получится.

SIGN - в переводе "знак отрицательности". Я в этом смысле имел ввиду отрицательность. Хотя, конечно, тоже был не совсем точен - "отрицательные интервалы", а не "отрицательные условия". Для краткости так говорил ("условия не вхождения в отрицательные интервалы" - больно длинно).