Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 between probleme...  [new]
gda
Member

Откуда:
Сообщений: 985
Hi....

I have a probleme with the 'between'. I query data with the select:
SQL>select name from dima;

NAME
---------------
Ace
Ace
Bob
Ruslan
Peter
Ace
Peter


after I query the data with:

SQL> select name from dima where name between 'A' and 'G';

NAME
---------------
Ace
Ace
Bob
Ace

OR the other select:

SQL> select name from dima where name between 'A' and 'B';

NAME
---------------
Ace
Ace
Ace


I do not understand who work the second and the third select, the selects with 'between'.

HELP ME!!!
17 окт 02, 17:55    [65702]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
Trampler
Member

Откуда:
Сообщений: 101
Если надо ограничения делать на 1-ю букву, то так и надо писать -

select name
from dima
where SUBSTR(name,1,1) between 'A' and 'B';

Иначе по правилам сравнения строк Bob>B
17 окт 02, 18:06    [65710]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
gda
Member

Откуда:
Сообщений: 985
Почему строка 'Bob' больше чем 'B'. Bob>B ????
18 окт 02, 09:38    [65842]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
Vlad_P
Member

Откуда: Москва
Сообщений: 23
Если сравниваемые строки разной длины, то более короткая дополняется пробелами, а пробел < любого символа алфавита.
18 окт 02, 10:13    [65869]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
SAA_
Member

Откуда: Латвия, Рига
Сообщений: 283
To Vlad_P:

> Если сравниваемые строки разной длины, то более
> короткая дополняется пробелами, а пробел < любого
> символа алфавита.

А как вы объясните это?


select * from dual where 'B' || chr(0) > 'B'
[color=green]
no rows returned.[/color]


И вот это:

select * from dual where 'B' || chr(0) > 'B '
[color=green]
D
-
X[/color]


В вашем случае оба выражения должны были вернуть одинаковый результат. Ведь в первом выражении 'B' должно было дополниться пробелом, судя по вашему утверждению.


о-моему все вы здесь должны иметь представление о программировании как таковом.
- Строки сравниваются посимвольно с начала строки.
- Аксиома:
'Bob' < 'Bobik'
Строка с меньшей длиной в данном случае и в операции сравненрия меньше
18 окт 02, 13:15    [66037]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
SAA_
Member

Откуда: Латвия, Рига
Сообщений: 283
Сорри... результаты надо поменять местами :)
18 окт 02, 13:17    [66042]     Ответить | Цитировать Сообщить модератору
 Re: between probleme...  [new]
Vlad_P
Member

Откуда: Москва
Сообщений: 23
Не думал, что развезется такая бодяга. Я специально написал символ алфавита. Так как спец.символы тоже имел в виду, но не думал. что кому то захочется рыть в эту сторону.

Посмотрел доку по 8-му релизу, почерпнул немало интересного для себя. Думаю и для всех.
Вот что вкратце там говорится по сему поводу.
Существует 2 метода сравнения срок
1. Blank-Padded Comparison Semantics
2. Nonpadded


  • Blank-Padded Nonpadded
    ’ab’ > ’aa’ 'ab’ > ’aa’
    ’ab’ > ’a ’ ’ab’ > ’a ’
    ’ab’ > ’a’ ’ab’ > ’a’
    ’ab’ = ’ab’ ’ab’ = ’ab’
    ’a ’ = ’a’ ’a ’ > ’a’

    Oracle uses blank-padded comparison semantics only when both values in the comparison are either expressions of datatype CHAR, NCHAR, text literals, or values returned by the USER function.

    Oracle uses nonpadded comparison semantics whenever one or both values in the comparison have the datatype VARCHAR2 or NVARCHAR2.
  • 18 окт 02, 14:33    [66109]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    SAA_
    Member

    Откуда: Латвия, Рига
    Сообщений: 283
    А если бы почитали еще внимательнее эту самую доку, то увидели, что поля типа CHAR в базе хранятся даже дополненные справа пробелами до максимальной длины поля! Вот и пошло non-padded comparison
    19 окт 02, 16:42    [66460]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "select * from dual where 'B' || chr(0) > 'B'
    В вашем случае оба выражения должны были вернуть одинаковый результат. Ведь в первом выражении 'B' должно было дополниться пробелом, судя по вашему утверждению. "

    for SAA_:
    Просто так для справки замечу, что пробел это не chr(0),
    а chr(32).
    21 окт 02, 09:28    [66592]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    Vlad_P
    Member

    Откуда: Москва
    Сообщений: 23
    Странное замечание... Наверное ничего не придумали лучше, чтобы съязвить....

    Во-первых, я СПЕЦИАЛЬНО, не стал указывать все особенности сравнения. А выбрал наиболее общий, понятный и достаточный для новичка.
    Как позже оказалось, M.Gruber приводит аналогичное правило. Из-за того что тип CHAR - стандарт ANSI, VARCHAR - нет. Во всяком случае для SQL-92. Так что смело синенький свой текст можете смело отправлять и ему.

    Во-вторых, Аксиом сравнения не бывает - есть правила сравнения, реализованные в том или ином языке.

    В третьих, Ваш последний постинг - вообще не по делу. Если не поняли из-своей раздражительности, что я имел в ввиду, цитируя документацию, то, плиз, пропустите такой скрипт.
    CREATE TABLE REG.TABCH
    
    (
    F1 Char(1),
    F2 Char(2)
    );

    insert into Tabch values ('D', 'D'||chr(0));
    commit;

    select length(F1), length(F2) from TABCH
    where F1>F2;


    Получите следующее:


    LENGTH(F1) LENGTH(F2)
    ---------- ----------

    1 2


    Т.е. короткая строка больше длинной.
    Аналогичный результат получите и в PL/SQL блоках, сранивая локальные переменные типа CHAR.

    И еще раз, чтобы дошло:
    Oracle использует 2 метода сравнения срок
    1. Blank-Padded Comparison Semantics
    2. Nonpadded

    Извинений дождаться от Вас, думаю будет трудно, так что и можете не стараться. Принимаются.
    А свою энергию направляйте в более деловое русло, выдерживая правила поведения в форуме.
    21 окт 02, 09:34    [66596]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "Странное замечание... Наверное ничего не придумали лучше, чтобы съязвить...."


    Не знаю ко мне это относилось или нет, но в любом случае не надо думать от людях так плохо.

    По поводу символа chr(0) в операциях сравнения: если почитать про символьные литералы,(называемые также строковыми) в документации по Oracle, то мы узнаем, что "Считается, что все строковые литералы имеют тип данных CHAR. Частью литерала может быть любой печатный символ из набора символов PL/SQL, в том числе и еще одна одинарная кавычка."

    Встаёт вопрос, что такое набор символов PL/SQL, смотрим также в доке:
    "The
    PL/SQL character set includes
    the upper- and lower-case letters A .. Z and a .. z
    the numerals 0 .. 9
    the symbols ( ) + - * / < > = ! ~ ^ ; : . ’ @ % , " # $ & _ | { } ? [ ]
    tabs, spaces, and carriage returns"

    Вывод chr(0) - не является корректным символьным литералом. Поэтому никто вам не будет гарантировать что при операциях сравнения при использовании неккоректных символьных литералов - эти операции будут правильно возвращать результат.

    Поэтому приводить пример:
    select * from dual where 'B' || chr(0) > 'B'
    в качестве доказательства - не правильно.
    21 окт 02, 10:48    [66630]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    Vlad_P
    Member

    Откуда: Москва
    Сообщений: 23
    Уважаемый softbuilder!
    Мое сообщение ни в коей мере не относилось к Вашему постингу. Его еще не было в форуме, когда я начал набирать ответ.

    Так получилось, что Ваш постинг вклинился в нашу дискуссию с SAA.

    Возможно я и не прав, но подобные замечания и комментарии могут вывести из себя кого-угодно.

    Возможность использования chr(0) давайте здесь уже не будем обсуждать. В качестве альтернативы вместо chr(0) можно взять те же таб (CHR(9)) или carriage returns. Сути и поведения моего примера не изменит.
    21 окт 02, 12:00    [66694]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "Возможность использования chr(0) давайте здесь уже не будем обсуждать. В качестве альтернативы вместо chr(0) можно взять те же таб (CHR(9)) или carriage returns. Сути и поведения моего примера не изменит."

    Вообще говоря, моё предыдущее сообщение конечно же относилось не к вам, а к тому кто привёл пример с использованием chr(0). Поэтому не совсем понятно почему именно вы включаетесь в спор.

    А касаемо chr(9) и CR, скажу что эти символы также не являются печатными символами, скорее всего они относятся к так называемым управляющим символам.
    Еще раз сформулирую : "Частью литерала может быть любой печатный символ из набора символов PL/SQL".
    В наборе PL/SQL есть "tabs, spaces, and carriage returns" - но это не печатные символы!!!

    А по воводу "Возможно я и не прав, но подобные замечания и комментарии могут вывести из себя кого-угодно."
    это не ко мне, а видимо к лечущему врачу.
    21 окт 02, 12:30    [66712]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    SAA_
    Member

    Откуда: Латвия, Рига
    Сообщений: 283
    To: softbuilder@inbox.ru - я действительно и клонил к тому, что #0 вовсе не равен #32 и тем самым показал, что символ пробела в данном случае просто ПУТАННИЦА.

    To: Vlad_P - если бы вы также ответили бы на каком-либо сертификационном экзамене, то вам бы прямо оценкой и сказали: ВАШ ОТВЕТ НЕПРАВИЛЬНЫЙ (я бы добавил - бездарный).
    Выражение АКСИОМА использовано для усиления значимости (выражение, которое чтоит запомнить и тем более не стоит доказывать).
    И уж совсем из области параллелеризма-перпендикуляризма: ОТВЕТ ДОЛЖЕН БЫТЬ ПРАВИЛЬНЫМ, А НЕ ДЛЯ НОВИЧКА/СРЕДНЕЧКА/ПРОФЕССИОНАЛА. ТОЛЬКО ПРАВИЛЬНЫЙ ОТВЕТ ОБУЧАЕТ, А НЕ ПУТАЕТ.
    Насчет поведения в форуме... простите, но я в ваш адрес НИЧЕГО грубого не сказал, просто показал ВАМ же ВАШУ ошибку... причем на примерах.
    И извинений, наверное, стоит ждать мне от вас, за то, что вы излили достаточное количество оскорблений в мой личный адрес на этом форуме.
    21 окт 02, 16:54    [66921]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    vskv
    Member

    Откуда: Рига
    Сообщений: 521
    [offtopic]Ой, как я люблю быть модератором :)[/offtopic]

    2SAA_: Если приводишь примеры с ошибками, то исправлять следует всё. От и до. А не ссылаться, "вот эту строчку и вот эту поменяйте местами". Запутывает, знаетели.

    2All: А в не пробовали создать базу в EBCDIC и прогнать вариант с "любой символ алфавита" на ней?

    2Vlad_P, SAA_: Вас устроит определение Blank-padded, как Nonpadded, c выравниванием меньшей строки до большей символом, считающимся в данном алфавите пробелом, справа?
    Поймите, nonpadded объясняется (и реализуется) на порядок проще.

    2Vlad_P: Отсутствие типа по имени VARCHAR в SQL-92 ещё не повод объявлять его не ANSI типом. В ANSI SQL есть тип CHAR VARYING, который является семантическим эквивалентом VARCHAR.

    И вообще, правильный тип для строк именно VARCHAR с его понятием "длины", которого у типа CHAR нет в силу его определения. (У CHAR "длинна" -- атрибут типа, а не данных.)
    22 окт 02, 00:19    [67088]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    gda
    Member

    Откуда:
    Сообщений: 985
    Rebeata I tut pocital vasi reci... Please napisiti v conte contov pravilo ili ... a to I tac i ne ponial cac sravnivaiutsea stroki.
    22 окт 02, 09:37    [67147]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "Rebeata I tut pocital vasi reci... Please napisiti v conte contov pravilo ili ... a to I tac i ne ponial cac sravnivaiutsea stroki."

    to gda:

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

    Может быть есть смысл, хоть что-то вначале изучить самостоятельно.
    22 окт 02, 09:51    [67157]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    Vlad_P
    Member

    Откуда: Москва
    Сообщений: 23
    Хотел первым написать, но vskv меня опередил. Впрочем это и хорошо.
    Предлагаю принести друг друг извинения, не захламлять сей топик не по существу и вести корректный диалог.
    Заранее приношу извинения собеседникам за все, что им не понравилось.
    2SAA Правила поведения в форумах, в которых я участвую, (но здесь я их правда не нашел), кроме недопущения оскорблений, говорят о том,
    что нельзя подвергать сомнению компетенцию собеседника. какой бы она ни была по-вашему мнению.
    Каюсь, что сорвался тоже, но считаю, что это было спровоцировано Вами в 1-м и 2 постинге.

    Как правильно заметил vskv, для простоты давайте не будем рассматривать символы, состоящие более чем из одного байта.
    А то залезем в такие дебри ...
    Извините, что буду многословен и приводить немало цитат.

    2vskv

    Отсутствие типа по имени VARCHAR в SQL-92 ещё не повод объявлять его не ANSI типом...

    возможно я чересчур доверял Граберу, который пишет следующее ( www.sql.ru/docs/sql/u_sql/c.shtml )
    ТИПЫ ТЕКСТОВОЙ СТРОКИ
    
    ANSI поддерживает только один тип чтобы представлять текст. Это - тип CHAR.
    Любое поле такого типа должно иметь определенную длину. Если строка вставлена в поле меньше
    чем длина поля, она дополняется пробелами; строка не может быть длиннее чем длина поля.


    Резюме. Книга морально устарела, про CHAR VARYING(n) я там не нашел ничего. Дальше на нее ссылаться не буду, имя под рукой доку по ORACLE.

    2softbuilder. Вы писали

    Встаёт вопрос, что такое набор символов PL/SQL, смотрим также в доке:
    "The PL/SQL character set includes
    the upper- and lower-case letters A .. Z and a .. z
    the numerals 0 .. 9
    the symbols ( ) + - * / < > = ! ~ ^ ; : . ’ @ % , "
    # $ & _ | { } ? [ ] tabs, spaces, and carriage returns"

    Вас не удивляет после этого такой корректный оператор
    VAR1 := 'ПЕРЕМ1'; в котором присутствуют неперечисленные Вами символы?
    Дело в том, что перечисленный Вами набор символов - это, опять же не внедряясь в детали, набор из которых можно составлять имена переменных,
    функций, строить различные выражения и т.д. Значения же, которые может принимать переменная текстового типа может быть любым от CHR(0)
    до CHR(255). Поэтому все приведенные в топике примеры корректны.
    А вот такой записи ПЕРЕМ1 := 'VAR1'; будет отлуп.

    2SAA Вы писали
    Выражение АКСИОМА использовано для усиления значимости (выражение, которое чтоит запомнить и тем более не стоит
    
    доказывать).
    И уж совсем из области параллелеризма-перпендикуляризма:
    ОТВЕТ ДОЛЖЕН БЫТЬ ПРАВИЛЬНЫМ, А НЕ ДЛЯ НОВИЧКА/СРЕДНЕЧКА/ПРОФЕССИОНАЛА. ТОЛЬКО ПРАВИЛЬНЫЙ ОТВЕТ ОБУЧАЕТ, А НЕ ПУТАЕТ.


    Почему же Вы требуете от других такой снайперской точности в определении, а себе позволяете вольности?
    За Вашу формулировку в 1-м постинге на том же экзамене Вас ждало бы тжс.
    А позже приведенный мной пример показывает, что и Вы были неправы.

    Второй резюм. Если встретились подобные операторы
    F1 := 'D';
    F2 := 'D'||chr(0);
    то результат сранения F1 и F2 непредсказуем, если не знать типов переменных.

    Поэтому я предлагаю Вам SAA .
    1.попросить модератора vskv убить весь этот базар, включая и сие послание,
    оставив только постинг с вопросом.
    2. Четко сформулировать правила сравнения текстовых переменных, используемые ORACLE.
    3. На этом конфликт считать исчерпанным. И впредь недопускать подобного поведения.

    Приведу выдержки из доки ORACLE 8, которые по-моему стоит осветить в ответе на поставленный вопрос. Если у Вас есть Oracle9..., то еще лучше.

    Character String Values
    
    Character values are compared using one of these comparison rules:

    1. blank-padded comparison semantics
    2. nonpadded comparison semantics

    Blank-Padded Comparison Semantics
    If the two values have different lengths, Oracle first adds blanks to the end of the shorter one so their lengths are equal.
    Oracle then compares the values character by character up to the first character that differs.
    The value with the greater character in the first differing position is considered greater.
    If two values have no differing characters, then they are considered equal. This rule means
    that two values are equal if they differ only in the number of trailing blanks.
    Oracle uses blank-padded comparison semantics only when both values in the comparison are
    either expressions of datatype CHAR, NCHAR, text literals, or values returned by the USER function.

    Nonpadded Comparison Semantics
    Oracle compares two values character by character up to the first character that differs.
    The value with the greater character in that position is considered greater.
    If two values of different length are identical up to the end of the shorter one, the longer value is considered greater.
    If two values of equal length have no differing characters, then the
    values are considered equal.
    Oracle uses nonpadded comparison semantics whenever one or both values in the comparison have
    the datatype VARCHAR2 or NVARCHAR2.

    Своими словами разумеется.
    Зы. Пока писал появилось еще два постинга. Думаю для начала GDA будет удовлетворен английской трактовкой, но стоит поторопиться.
    22 окт 02, 11:02    [67213]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "Дело в том, что перечисленный Вами набор символов - это, опять же не внедряясь в детали, набор из которых можно составлять имена переменных,
    функций, строить различные выражения и т.д. Значения же, которые может принимать переменная текстового типа может быть любым от CHR(0)
    до CHR(255). Поэтому все приведенные в топике примеры корректны. "

    Я опять хочу повторить свою мысль, но не с целью что-бы поспорить, а всё же докапаться до истины.
    Я держу в руках книгу "Oracle8. Программирование на языке PL/SQL. Руководство для программистов Oracle. Скотт Урман. Oracle Press."

    В ней на странице 25 с разделе "Основы PL/SQL", "Cимвольные литералы" написано:
    "Символьные литералы(называемые также строковыми) состоят из одного или несколько символов, ограниченных одиночными кавычками. Символьные литералы могут быть присвоены переменным, имеющие типы CHAR и VARCHAR2, без преобразования. Например, ниже приведены корректные символьные литералы:
    '12345'
    'Four score and seven years ago...'
    '100%'
    '"'
    Считается, что все строковые литералы имеют тип данных CHAR. Частью литерала может быть любой печатный символ из набора символов PL/SQL, в том числе и еще одна одинарная кавычка...."

    Снова возвращаемся к определению что же такое набор символов Pl/SQL, смотрим страницу 22:
    "....PL/SQL.В состав этого набора входят:"
    Буквы верхнего и нижнего регистров A-Z b a-z
    Цифры 0-9
    Разделители: символы табуляции, пробелы и символы возврата корретки
    Метематичнские символы: + - * / <> =
    Символы пунктуации: () {} [] ? ! ` ; : . ! " @ # % ^ $ _ |"

    Так вот печатными символами не будут считаться символы табуляции, пробелы и символы возврата корретки, это управляющие символы. А символ chr(0) тем более, так как он вообще не входит в этот набор.

    Теперь смотрим страницу 72, "SQL в PL/SQL. Сравнение символов:
    ....Какой же метод тогда использовать? В PL/SQL метод сравнения с дополнением пробелами используется только в том случае когда оба сравниваемых значения имеют фиксированную длину. Если же одно из значений имеет фиксированную длину, то применяется сравнение без дополнения пробелами. Данные типа CHAR имеют фиксированную длину, а данные типа VARCHAR2 - переменную. Считается что символьные литералы(заключённые в одиночные кавычки) ВСЕГДА ИМЕЮТ ФИКСИРОВАННУЮ ДЛИНУ."

    То есть символьные литералы всегда имеют тип CHAR. И не важно где они используются в PL/SQL иди в SQL, принцип один и тот же.

    То есть исходя из вышеуказанного получаем:при использовании символьных литералов в запросе их тип есть тип CHAR и при этом используется дополнение пробелами при разной длине литералов.
    И в данном котексте слова vskv:
    "И вообще, правильный тип для строк именно VARCHAR...)"
    выглядят некорректно.

    Теперь рассмотрим запрос:
    select * from dual where 'B' || chr(0) > 'B'

    SQLWKS> select * from dual where 'B' || chr(0) > 'B'
    2>
    D
    -
    X
    Выбрана 1 строка.

    Так как оба строковых литерала имеют тип CHAR, используется дополнение пробелами. Значит правый литерал дополняется одним пробелом. В этом случае ASCII(char(0)) < ACSII(chr(32)).То есть левый литерал должен быть меньше. Значит запрос не ДОЛЖЕН возвращать строку. Тогда почему же это происходит? Пока непонятно.
    Теперь рассмотрим такой запрос. Сравняем длину литералов в запросе:
    select * from dual where 'B' || chr(0) > 'B '
    SQLWKS> select * from dual where 'B' || chr(0) > 'B '
    2>
    D
    -
    Выбрано 0 строк.

    Теперь работает правильно. Тогда почему же первый запрос не сработал? - вывод: в первом запросе не было автоматического добавления пробела. Значит в сравнении использовался алгоритм без дополнения пробелами. При котором более короткая строка меньше длинной.
    Что это означает? - Это означает что тип литералов 'B' || chr(0) и 'B' - отличен. Если тип литерала 'B' не вызывает сомнения - CHAR, значит тип левого литерала VARCHAR2.
    Почему? - потому-что перестало действовать условие корректности строкового литерала: печатные символа из набора PL/SQL.
    22 окт 02, 12:30    [67285]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    "Так вот печатными символами не будут считаться символы табуляции, пробелы и символы возврата корретки, это управляющие символы. А символ chr(0) тем более, так как он вообще не входит в этот набор"

    Насчёт пробела это просто недосмотр, великий Ctrl-C, Ctrl-V
    22 окт 02, 12:34    [67290]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    В доказательство своих слов также привожу практическую проверку.
    В Oracle есть фунцкция DUMP, которая возвращает информацию о внутреннем представлении выражения.
    Формат определяется по таблице:
    Код Тип
    1 VARCHAR2
    2 NUMBER
    8 LONG
    12 DATE
    23 RAW
    24 LONG RAW
    69 ROWID
    96 CHAR
    106 MSLABEL

    Применим:
    select DUMP('B' || chr(0)), DUMP('B') from dual where 'B' || chr(0) > 'B'

    SQLWKS> select DUMP('B' || chr(0)), DUMP('B') from dual where 'B' || chr(0) > 'B'
    2>
    DUMP('B'||CHR(0)) DUMP('B')
    ----------------- ----------------
    Typ=1 Len=2: 66,0 Typ=96 Len=1: 66
    Выбрана 1 строка.

    Видим, что действительно выражение 'B' || chr(0) имеет тип 1, то есть VARCHAR2, а 'B' тип 96, то есть CHAR.
    22 окт 02, 13:57    [67356]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    Проведём еще одно исследование:
    select DUMP('B' || 'B'), DUMP('B') from dual where 'B' || chr(0) > 'B'

    DUMP('B'||'B') DUMP('B')
    ------------------- ----------------
    Typ=96 Len=2: 66,66 Typ=96 Len=1: 66
    Выбрана 1 строка.

    Мы видим что при использовании оператора || не происходит автоматического приведения к типу VARCHAR2.

    Теперь же букву 'B', заменим на chr(66), что есть тоже самое.

    select DUMP('B' || chr(66)), DUMP('B ') from dual where 'B' || chr(0) > 'B'
    DUMP('B'||CHR(66)) DUMP('B')
    ------------------ -------------------
    Typ=1 Len=2: 66,66 Typ=96 Len=2: 66,32
    Выбрана 1 строка.

    В этом случае получаем тип VARCHAR2.
    Функция chr используется для того что-бы получить символ, когда он не является печатным, поэтому с случае
    с DUMP('B' || chr(66)) и в любом случае с chr(X) Oracle приводит выражение к VARCHAR2.
    Опять же отсюда вывод:Частью литерала может быть любой печатный символ из набора символов PL/SQL и он является типом CHAR
    22 окт 02, 14:12    [67371]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    Vlad_P
    Member

    Откуда: Москва
    Сообщений: 23
    2Softbuilder.
    Не могу так быстро отвечать, работа видите ли.... Пока кусками писал ответ ты еще что-то запостил.
    Но чтоб не пропал даром труд, публикую. Последний пост внимательно не читал, не обессудь, если будут повторы.

    Согласен покопаться вместе. Может кто-то еще подключится и прояснит ситуацию, опираясь не на интуицию, а четко указав место, где мы правы, где нет.
    А самое главное - почему?
    С англицким у нас, не сомневаюсь, все в порядке, поэтому для скорости предлагаю копировать найденные места без перевода.

    Вот что я нарыл.
    Во первых,
    CHR(n [USING NCHAR_CS])

    Returns the character having the binary equivalent
    to n in either the database character set or the national character set.

    If the USING NCHAR_CS clause is not specified, this function returns the character having
    the binary equivalent to n as a VARCHAR2 value in the database character set....

    Так что при вычислении 'B' || chr(0) один из операндов varchar2 -> и рез-т того же типа. Будем считать это за true (надоело уже рыться в доке),
    пока кто-нибудь не опровергнет. Этим можно понять рез-т вашего первого примера.

    Теперь о наборе символов. Мы оба понимаем, что русские буквы можно использовать,
    можно использовать и CHR(10)+CHR(13) (я часто этим пользовался в свое время),
    значит где-то есть указание об этом.
    Вот для затравки одно место
    Elements of Oracle8 SQL
    
    Literals
    ....
    You can specify character literals with the 'text' notation, national character literals with the N'text' notation...

    Text
    Text specifies a text or character literal. You must use this notation to specify values
    whenever 'text' or char appear in expressions, conditions, SQL functions, and SQL commands
    in other parts of this reference.

    The syntax of text is as follows:

    text::= N'c[ccc...]' (изображу диаграмму условно)

    where
    N specifies representation of the literal using the national character set. Text entered
    using this notation is translated into the national character set by Oracle when used.

    c is any member of the user's character set, except a single quotation mark (').
    ...
    Text literals have properties of both the CHAR and VARCHAR2 datatypes:

    - Within expressions and conditions, Oracle treats text literals as though they have the datatype CHAR
    by comparing them using blank-padded comparison semantics.
    - A text literal can have a maximum length of 4000 bytes.


    Дальше нет времени, припахали.
    22 окт 02, 14:47    [67414]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    softy
    Member

    Откуда: from Russia
    Сообщений: 5911
    to Vlad_P:
    Я получил уже второе письмо от твоего имени, но хочу сказать сразу я не открываю письма от незнакомых мне людей и я их просто удаляю. Так что я не в курсе о чём была речь. Лучше пиши в конфе.
    22 окт 02, 14:55    [67417]     Ответить | Цитировать Сообщить модератору
     Re: between probleme...  [new]
    SAA_
    Member

    Откуда: Латвия, Рига
    Сообщений: 283
    Мое мнение: приведенные выше факты, примеры, проверки, обсуждения и конфронтации считать исчерпывающими по этой теме. Скопировать данную ветку в отдельный докмент и сдать вместо какой-нибудь курсовой... например мне и Vlad_P. Я думаю после такого оценка будет хорошей.
    23 окт 02, 16:13    [68069]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Oracle Ответить