подскажите пожалуйста в чем тут может быть проблема?
пишу такой триггер
CREATE TRIGGER add_TV FOR TV_NAME after insert POSITION 10 AS
declare variable name varchar(100);
BEGIN
:name = mergename("t",id);
alter table tv add :name;
END
при попытке выполнить SQL генерируется исключение — "Token unknown — :"
(тут mergename(...) — UDF написана мною — "сливает" значение текстового параметра (первый параметр) с параметром типа integer — второй параметр и выдает строку, работает правильно, я проверял... )
в попытке выяснить источник ошибки, я пытаюсь выполнить такой код:
CREATE TRIGGER add_TV FOR TV_NAME after insert POSITION 10 AS
BEGIN
alter table tv add t1;
END
тут генерируется исключение — "Token unknown — alter"
хотя при выполнении кода "alter table tv add t1" вне тела тригера или процедуры никаких ошибок не возникает...
какие соображения будут?
Разве нельзя выполнять операторы ALTER TABLE в телах тригеров и процедур??
Здравствуйте, Denis Tkachov, Вы писали:
DT>Разве нельзя выполнять операторы ALTER TABLE в телах тригеров и процедур??
Да, нельзя. У interbase сосуществуют 4 плохо совместимых диалекта SQL одновременно. В том, который используется в процедурах и триггерах, DDL (т.е. create/alter/drop) запрещены. Вообще все. DDL доступен только из интерактивного SQL. В котором зато нет переменных, циклов и прочей ерунды. В общем, Interbase — suxx forever.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Ау! Скажи, родной, нафига тебе такое чудо?
А ты сам никогда-никогда временные таблички не пользуешь в сторед процедурах?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Igor Trofimov, Вы писали:
iT>>Ау! Скажи, родной, нафига тебе такое чудо? S>А ты сам никогда-никогда временные таблички не пользуешь в сторед процедурах?
Изменения метаданных в Interbase исполняются в отдельных (от изменений данных) транзакциях, и по этой причине не могут исполняться в триггерах и ХП. Временные таблички могут моделируются с помощью глобальных (+ доп. поле).
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Igor Trofimov, Вы писали:
iT>>Ау! Скажи, родной, нафига тебе такое чудо? S>А ты сам никогда-никогда временные таблички не пользуешь в сторед процедурах?
Извbняюсь, а зачем временные таблички в ХП? Я понимаю, это было нужно при использовании навигационнного подхода, но в SQL....
Здравствуйте, DarkGreen, Вы писали:
DG>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Igor Trofimov, Вы писали:
iT>>>Ау! Скажи, родной, нафига тебе такое чудо? S>>А ты сам никогда-никогда временные таблички не пользуешь в сторед процедурах?
DG>Извbняюсь, а зачем временные таблички в ХП? Я понимаю, это было нужно при использовании навигационнного подхода, но в SQL....
и мой ответ к нему (п.2.). особо обрати внимание на исходный запрос и на результат.
... << RSDN@Home 1.1 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
iT>>>>Ау! Скажи, родной, нафига тебе такое чудо? S>>>А ты сам никогда-никогда временные таблички не пользуешь в сторед процедурах?
DG>>Извbняюсь, а зачем временные таблички в ХП? Я понимаю, это было нужно при использовании навигационнного подхода, но в SQL....
_MM_>читни топик Оптимизиция запроса
и мой ответ к нему (п.2.). особо обрати внимание на исходный запрос и на результат.
в IB временные таблицы отсутствуют, хотя довольно просто сделать с помощью генераторов. Но не нужно, 99,9 % задач можно сделать без них. У меня, например, их просто ни в одной базе нет. Просто у каждого сервера своя идеология, и, например, переносить принципы между MSSQL и Interbase будет очень грубой ошибкой.
Такой же ошибкой является alter table в процессе работы. Во-первых, DML в процедурах и триггерах запрещен, во-вторых, количество изменений каждой таблицы IB не должно превосходить 256, считается и счетчик обнуляется только при restore. Структура БД должна быть стабильной, и менять ее при эксплуатации недопустимо.
Здравствуйте, DarkGreen, Вы писали: DG>Извbняюсь, а зачем временные таблички в ХП? Я понимаю, это было нужно при использовании навигационнного подхода, но в SQL....
Бывыают ситуации. В качестве примера могу привести ситуацию, где нужно проагрегированный датасет (результат group by) сджойнить с двумя разными датасетами. Практически невозможно объяснить серверу, что не нужно выполнять дорогостоящий груп бай два раза. Остается только сливать результат во временную табличку.
Да, любой запрос можно выполнить без времянок. Но иногда это приводит к существенной потере производительности.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DarkGreen, Вы писали: DG>>Извbняюсь, а зачем временные таблички в ХП? Я понимаю, это было нужно при использовании навигационнного подхода, но в SQL.... S>Бывыают ситуации. В качестве примера могу привести ситуацию, где нужно проагрегированный датасет (результат group by) сджойнить с двумя разными датасетами. Практически невозможно объяснить серверу, что не нужно выполнять дорогостоящий груп бай два раза. Остается только сливать результат во временную табличку. S>Да, любой запрос можно выполнить без времянок. Но иногда это приводит к существенной потере производительности.
Вот об этом я и говорю. Такая задача в IB эффективно решается через for select или select SP, причем как правило эффективнее, чем через временные таблицы
и мой ответ к нему (п.2.). особо обрати внимание на исходный запрос и на результат.
Спасибо, прочитал.
1. Если я правильно понял, то #tmp — это временная таблица? Если да, то зачем ее использовать, почему нельзя использовать курсоры и переменные? Тогда можно воспользоваться вот такой конструкцией:
for
select T1.Filed1 from Table1 T1
inner join Table2 T2
(on T1.Filed1 = T2.Filed_1)
into :Variable_1
do
for select ............
2. В топике который вы мне предложили почитать неверна, ИМХО, сама структыра БД, если бы в таблице ValInt первичный ключ был UID + POINT + PID, а не POINT + PID (если я правильно понял, и что есть не очень правильно, т. к. PID уникален только для объекта, а POINT вообще не уникален), то в результате можно было бы отказаться от таких запросов с кучей вложений. Запрос выглядел бы вообще просто:
select point, pid, [value]
from ValInt
where (uid=46) and (point<=100000) and (pid in (20,145,555,9834,876235))
как тут уже правильно заметили, идеологиля в IB и MSSQL разные.
в общем я хотел сказать, что в случае когда несколько раз надо выполнить один и тот же "массивный" подзапрос, то лучче выполнить его один раз во времянку и пользовать потом данные оттуда.
... << RSDN@Home 1.1 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, Sinclair, Вы писали:
S>Бывыают ситуации. В качестве примера могу привести ситуацию, где нужно проагрегированный датасет (результат group by) сджойнить с двумя разными датасетами. Практически невозможно объяснить серверу, что не нужно выполнять дорогостоящий груп бай два раза. Остается только сливать результат во временную табличку. S>Да, любой запрос можно выполнить без времянок. Но иногда это приводит к существенной потере производительности.
Как выше написал Romkin, такие задачи решаются в IB с помощью курсовров, в Оракле на сколько помню тоже.
Hello, DarkGreen!
You wrote on Tue, 12 Aug 2003 08:07:48 GMT:
хъ
Курсоры есть и под MS SQL, только временные таблицы (а еще лучше
таблицы-переменный) быстрее и эффективнее.
В оракле есть временные таблицы и они очень часто используються (правда они
несколько отличаються от MS SQL).
