» InterBase и FireBird: вопросы по работе и их решение

miwa
можно конечно, но вопрос был про iif именно в order by
ведь если уже всё было посчитано в вычислимом поле - то можно было бы просто написать order by fieldcalculated

ant0ni02004
Я имел в виду не вычислимое поле, а индекс по выражению.

miwa
а ведь точно, можно и index computed by завести для этих целей

xpin2013

Цитата:

А можно ли в конструкции ORDER BY использовать IIF

Можешь объяснить к чему эти извращения? Что мешает пойти стандартным путем?

Код: select FIELD1, FIELD2, iif(FIELD1 > FIELD2, FIELD1, FIELD2)
from (select 1 FIELD1, 9 FIELD2
from RDB$DATABASE
union all
select 8, 2
from RDB$DATABASE
union all
select 3, 7
from RDB$DATABASE)
order by 3 asc

OXDBA
Интересные представления о стандарте и извращениях. А если надо будет с реальных таблиц данные получить? И данных будет больше трех строк?

Цитата:

А если надо будет с реальных таблиц данные получить?

А причем здесь определение порядка сортировки выходных данных?

Цитата:

А можно ли в конструкции ORDER BY использовать IIF?

Куда здесь запихивать IIF? И самое главное, зачем?

Код: [ORDER BY {{столбец-результат [ASC|DESC]}.,..}
|{{положительное целое [ASC|DESC]}.,..}];

Цитата:

Куда здесь запихивать IIF? И самое главное, зачем?

Отлично запихивается.

Код: select FIELD1, FIELD2
from (select 1 FIELD1, 9 FIELD2
from RDB$DATABASE
union all
select 8, 2
from RDB$DATABASE
union all
select 3, 7
from RDB$DATABASE)
order by iif(field1>field2,field1,field2)

Цитата:

А причем здесь определение порядка сортировки выходных данных?  

Неправильно понял запрос, каюсь.

Тем не менее, с ходу не вижу причин почему нельзя использовать iif как в секции select так и в order by. Интереса ради надо бы тест сделать.

exteris
Поясню еще раз, про стандартный путь, т.е. определенный стандартом, для упрощения возьмем за основу SQL-92, ибо текст SQL-86 уже не найти, где есть описание синтаксиса order by. Если задача решается с использованием синтаксиса, определенного стандартом, то зачем изобретать велосипед? Завтра, текст этого запроса будет разбирать другой разработчик, упорно пытаясь понять сакральный смысл этого order by.

OXDBA

SELECT ... FROM ...
...
ORDER BY <ordering-item> [, <ordering-item> ...]

<ordering-item> ::= {col-name | col-alias | col-position | expression}
[COLLATE collation-name]
[ASC[ENDING] | DESC[ENDING]]
[NULLS {FIRST|LAST}]


Отсюда.

OXDBA
SQL-92 уже 22 года, как бэ.

Во многих популярных СУБД есть фичи, отсутствующие в стандарте. В том числе и order by expression.
Если это удобно и помогает в разработке, не вижу смысла этим не пользоваться.

miwa
Этот документ мне до боли знаком , но
exteris

Цитата:

Если это удобно и помогает в разработке, не вижу смысла этим не пользоваться.

Конечно, но за много лет выработал правило использовать стандартный синтаксис, если это возможно для решения задачи и не ухудшает план. Неизвестно под какую СУБД будет следующий проект, а портировать существующие наработки будет намного проще. Это может показаться незначительной мелочью, но жизнь облегчает.

Цитата:

SQL-92 уже 22 года, как бэ.

Так после 92го синтаксис особенно и не менялся, только дополнялся новой функциональностью.
Мдаа.. мечтательно.. помню те прекрасные времена, когда еще не было FB, а IB приходил на 4 дискетах, с коробкой печатной документации

OXDBA

А чего помнить те времена, FB и сейчас влезет на четыре дискеты.

noisy

На 5. А 64-разрядный - даже на 7

OXDBA
Стандарт - это хорошо и правильно, кончено. В связи с чем вопрос - вы процедуры и тригеры вообще не используете по тем же причинам?


Цитата:

Так после 92го синтаксис особенно и не менялся, только дополнялся новой функциональностью.

Не берусь судить, так как не имел возможности ознакомиться, но - вы точно уверены, что в дополненой новой функциональности стандарта нету order by expression? А то википедия, например утверждает что так можно делать.

В последнее время наблюдаю ошибки при подключению к базам с кириллицей в путях.
т.е. C:\БАЗА\b.fdb - ошибка, а C:\S\b.fdb - все хорошо.

Система win 7, FB 2.1/2.5, antivir COMODO.

Уже не заню где искать причину, ранее такой проблемы не было.

Кто сталкивался с такой проблемой?

noisy
Текст ошибки (полный) - большой-большой секрет?

Всех с праздником Победы!



miwa текст, ошибки

Error Message:
----------------------------------------
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
I/O error for file "D:\Р—РђРљРђР—Р§Р&#152;РљР&#152;\DB\F.FDB".
Error while trying to open file.
Системе не удается найти указанный путь. .


сам файл лежит D:\Заказчики\DB\F.FDB

noisy
Тоесть, проблема в переменной, в которой хранится путь к базе в программе и firebird тут вообще не при делах. Скорее всего в твоей программе/среде программирования/библиотеке доступа где-то путаница с unicode/win1251 строками.

miwa

Спасибо. Действительно проблема в кодировке была.

В базе имеется поле varchar (500). Требуется после всех запятых, в этом поле, добавить пробел (если его нет). Конструкция с '_,_' на '_, _' не прокатила. Подскажите, как оформить сей фокус.

Maximus777
Где полный текст запроса, в котором конструкция "не прокатила"? И чтоб два раза не вставать - в этом запросе функция replace используется?

Код: UPDATE CLIENT_CATALOG SET ITEM_KOMMENT = REPLACE(ITEM_KOMMENT, '_,_', '_, _');

Maximus777
Если после приведенного запроса в item_comment ничего не поменялось, значит там нет последовательности символов «подчеркивание-запятая-подчеркивание».

Еще варианты - не закоммичена транзакция, неправильные параметры транзакции, данные меняются в одной базе, а просматриваются во второй...

miwa
Мне надо найти все запятые, которые имеются в тексте этого поля и поставить после них пробел. Если пробел уже есть, то такие места не трогать. Т.е. если в поле встречается "бла-бла-бла,бла-бла", то надо заменить на "бла-бла-бла, бла-бла".

Maximus777
ох, не на SQL такое делать... тут бы регуляркой
но можно и так вывернуться:
1. поставьте пробел после каждой запятой (заменяете "," на ", ")
2. заменяете все ", " (там 2 пробела!) на ", " пока что-то заменяется (т.е. пока пред. и текущая версия строки не станут равны)

ant0ni02004
«Если вы решили проблему регуляркой, теперь у вас две проблемы»©

Maximus777
Вообще ant0ni02004 правильно говорит. А если при этом допустить, что в изначальном тексте нету длинных последовательностей пробелов, тогда можно и одной строкой типа

Код:
update client_catalog set item_comment = replace(replace(item_comment, ',' ', '), ', ', ', ')

Maximus777

я бы обновил в три шага:
1. заменил конструкцию ', ' на один символ не попадающийся в строке, например ~
2. потом заменил все ',' на ', '
3. и затем '~' на ', '

miwa

Цитата:

«Если вы решили проблему регуляркой, теперь у вас две проблемы»©

так и есть
тут, как мне кажется, именно тот случай, когда данные должны быть обработаны именно на клиенте, а не напрягать SQL подобным
noisy
таким образом поостаются, например ", " итд (т.е. запятая и более чем 1 пробел)

Всем спасибо. Всё получилось.

miwa
Цитата:

(внимательнее с пробелами и запятыми)

Да, одна была пропущена. Что тоже только на пользу мне

Ребят не знает ли кто как можно убыстрить сравнение длинных строк ? Запросы жутко тормозят...