Сортировка в execute block

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
UNK
Сообщения: 22
Зарегистрирован: 08 дек 2006, 17:34

Сортировка в execute block

Сообщение UNK » 23 фев 2009, 14:52

FB2.0
Данные для отчетов формирую в execute block(чтобы не плодить хранимые процедуры).
Необходимо сортировать выходные данные.
Это возможно?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: Сортировка в execute block

Сообщение hvlad » 23 фев 2009, 15:11

UNK писал(а):FB2.0
Данные для отчетов формирую в execute block(чтобы не плодить хранимые процедуры).
И чем мешают процедуры ?
UNK писал(а):Необходимо сортировать выходные данные.
Это возможно?
На клиенте возможно всё

UNK
Сообщения: 22
Зарегистрирован: 08 дек 2006, 17:34

Re: Сортировка в execute block

Сообщение UNK » 23 фев 2009, 18:03

С execute block гораздо гибче не надо менять метеданные. Отправил заказчику почтой отчет и все.

zz 5
Сообщения: 32
Зарегистрирован: 02 мар 2006, 10:52
Откуда: Россия, Москва

Re: Сортировка в execute block

Сообщение zz 5 » 06 мар 2009, 15:58

2UNK И как получилось реализовать аналог ХП с помощью EXECUTE BLOCK? Тоже стоит пока такая проблема. Не все отчеты можно реализовать с помощью чистого SQL, а собирать на клиенте - накладно. Надо будет поставить себе погонять двойку.

hvlad Вопрос разработчику можно? :roll: Насколько опасно для базы использовать в качестве вывода отчета создание, выполнение и удаление ХП? Допустим, отчет вызывается десяток раз на дню. Это порочная практика? На другом форуме спрашивал - все отговаривали, на чем, собственно, и остановился. Но аргументированных доводов до сих пор, увы, не услышал.

Attid
Спец
Сообщения: 375
Зарегистрирован: 14 ноя 2006, 09:58
Контактная информация:

Re: Сортировка в execute block

Сообщение Attid » 06 мар 2009, 17:01

zz 5 писал(а): Насколько опасно для базы использовать в качестве вывода отчета создание, выполнение и удаление ХП? Допустим, отчет вызывается десяток раз на дню. Это порочная практика? На другом форуме спрашивал - все отговаривали, на чем, собственно, и остановился. Но аргументированных доводов до сих пор, увы, не услышал.
для методанных есть счетчик который скидывается при бекап\ресторе если не изменяет склероз
то он smolinteger и может быть при таком варианте достигнут. и новые процеру обломятся.

Attid
Спец
Сообщения: 375
Зарегистрирован: 14 ноя 2006, 09:58
Контактная информация:

Re: Сортировка в execute block

Сообщение Attid » 06 мар 2009, 17:07

UNK писал(а):С execute block гораздо гибче не надо менять метеданные. Отправил заказчику почтой отчет и все.

Код: Выделить всё

execute block   . . .. . .
as
begin
   select ..
   from 
   /*order*/order by 2/*order_end*/

   select ..
   from 
   order by 1

   select ..
   from 
   /*order*/order by 9/*order_end*/
end
на клиенте через вырезаешь нужные ордера и заменяешь на свои.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: Сортировка в execute block

Сообщение hvlad » 06 мар 2009, 17:47

zz 5 писал(а):hvlad Вопрос разработчику можно? :roll: Насколько опасно для базы использовать в качестве вывода отчета создание, выполнение и удаление ХП? Допустим, отчет вызывается десяток раз на дню. Это порочная практика? На другом форуме спрашивал - все отговаривали, на чем, собственно, и остановился. Но аргументированных доводов до сих пор, увы, не услышал.
Документация гласит, что все изменения метаданных нужно делать в монопольном соединении. Рекомендую прислушаться к этому. Иначе можно действительно напороться на несколько неожиданные эффекты.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Сортировка в execute block

Сообщение WildSery » 07 мар 2009, 14:31

hvlad писал(а):Документация гласит, что все изменения метаданных нужно делать в монопольном соединении. Рекомендую прислушаться к этому. Иначе можно действительно напороться на несколько неожиданные эффекты.
+1. Даже в монопольном режиме, если не применять голову, можно нарваться.
У меня разработчик не поставив меня в известность сбацал модуль, который (монопольно, замечу! т.е. в БД кроме него никого) в процессе своей работы выключал запрещающий сохранение триггер, и включал после этого самого сохранения.
Дык вот, примерно каждый десятый раз попытка выключения триггера натыкается на deadlock. Разбираться, почему, я не стал, а сделал правильно. Т.е. без изменений метаданных на ходу.

Ответить

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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя