Re: Опять глючит конектс на Yaffil 889
Janex wrote: Попробуй отключить, хотя не думаю что из-за этого. Отключил - будем смотреть чё будет... Хрену :( Сегодня утром всё по старому :( Regards Janex
Re: CURRENT_TABLE
> но я так и не понял что тут упрощает Current_Table. Просто упрощает _написание_ и _чтение_ кода. Вместо того, чтобы прописывать в дизайнтайм (или клеить в рантайм при создании) в каждом триггере имя таблицы аки константу строковую, можно элегантно использовать "псевдоним" CURRENT_TABLE. И если реализация CURRENT_TABLE в сервере гроша ломанного не стоит по стоимости своей, то почему бы и нет (с учетом уже сделанных всевозможных CURRENT_XXX)? Другое дело, что может быть не все так просто - тогда другой разговор и CURRENT_TABLE тогда однозначно в сад или в далекое будущее. Спору нет. > нормальное блокирование всемогущего SYSDBA. Так вот кто заказывал узнать программно пароль SYSDBA в базе? :))) > Зато с самолётиками - хоть залейся. Из самолетиков складывается эскадрилья приятных мелочей. Речь не идет о том, чтобы поставить приоритет для CURRENT_TABLE выше, чем для SMP или таблиц подобных в IB7.
Re: ��������� � ���������������� �������� � FB2
CREATE PROCEDURE TEST ^^^AS BEGIN EXECUTE STATEMENT ''; END ÃÃÃÃ Ã ÃÃÃ -ÃÃÃÃ ALTER?
Re: CURRENT_TABLE
Ded пишет: > >> И если там делов "на две строки >> и на бутылку пива", то польза от CURRENT_TABLE >> будет многократно больше (плюс уже >> куча всяких CURRENT_XXX имеется), не >> смотря, что могут сделать только к >> версии 4.0. > >Какая именно польза - я от тебя пока так и не добился. Польза - и всё > тут ;) Польза - понятие чисто субъективное. :) Ты Димину пользу за пользу не воспринимаешь, так что... не требуй неможливого. А вообще я смысла спора не наблюдаю. Хорсун Влад ответил вроде, что в ближайшее время этого не будэ, но когда-нибудь потом... может быть, если что. Удачи
Re: CURRENT_TABLE
Я позволил себе малость стасовать текст, чтоб не писать 10 раз одно и то же. Dmitriy Kovalenko wrote: > - > Повторяю: польза в том, что в коде > триггера можно "программно" узнать, для > какой таблицы выполняется его код. > - >>Всё-ж таки, что ж эта процедура будет делать? Код, сьестра, код! > > > Да пох абсолютно, что это будет. Причем > тут код? > Более того, если бы у меня была > возможность CURRENT_TABLE, то это я сделал бы > ЕЩЕ ПРОЩЕ. Так понятно, из-за чего > вопрос о CURRENT_TABLE снова возник? :) Нет, непонятно. И всё более и более переходит в жанр "Хачу! Хачу самолётик и всё! А :" Наверное я тупой, но я так и не понял что тут упрощает Current_Table. > Не трогать определения (код) таблиц > (добавление полей в них). Это просто > триггер. Просто обычный триггер. Самый > настоящий триггер. > Только который > может знать через CURRENT_TABLE на КАКОЙ > таблице он исполняется. Я что-то сказал насчёт того, что для логирования нужны дополнительные поля? Свой стандарт таблиц я показал в ответ на вопрос о временных метках, к механизмам логирования не имеющих прямого отношения. То есть они атрибуты как записи, так и лога, и всё. А флаг отключения триггеров очень удобен для ремонтных работ не мешая юзерам и только-то. И ещё для некоторых специфических вещей. Например, для того, чтобы при выполнении в одной транзакции нескольких последовательных связанных действий над одной записью отправлять в лог только результирующую запись. Но это мне потребовалось только один раз. Вопрос о суровой необходимости Current_Table для лог-триггера остаётся по-прежнему незыблемым постулатом Вселенной. Как я раньше без него обходился? Наверное всё делаю неправильно :( >> Хде? Хто? Предлагал? >> Хде? Хто? Предлагал? >> Хде? Хто? Предлагал? > > > Перечитай еще раз и выбери по авторам. > Я ж не с потолка взял, а перечитал все, > выбирая упомянутые решения. Ну, кто-нибудь ведь мог предложить и ещё какую-нить хрень. Ты со мной споришь? Ну вот моим мне в нос и тыкай. > Кучу CURRENT_XX сделали? А там нельзя было > обойтись "с клиента" или десантом с > Марса? А ввод Емановым универсальных > триггеров на события? Зачем? И без них > все было прекрасно... Вот-вот. Это является одной из причин, почему мой личный интерес к дальнейшему развитию FB снизился не до уровня плинтуса конечно, но заметно. Меня, как представителя круга крупных пользующих корпораций, интересуют: 1. SMP-супер. 2. Администрабельность на уровне IB7 - мониторинг коннектов, возможность снять запрос/коннект без риска повредить базу, хранение юзеров в базе и нормальное блокирование всемогущего SYSDBA. 3. Общее повышение производительности. Именно в такой последовательности приоритетов. А что мы имеем? По пункту 3 есть подвижки в плане новых индексов, оптимизатора, стратегии работы с мусором. Это хорошо. По пункту 2 - вроде бы надёжный шатдаун (ещё не тряс как следует) и можно причислить реанимированный nbackup. Негусто. По пункту 1 по нулям. Зато с самолётиками - хоть залейся. > Просто я спрашиваю про одно, а > меня лечат какой-то хренотенью > совершенно не по теме. Взаимно. > Я не выношу на > обсуждение сейчас механизмы, в которых > мне понадобился бы CURRENT_TABLE. Потому что их просто нет. Или они в сфере частных-личных специфических решений. Ладно, я устал и разозлился, хорош флудить, надо ещё кое-что сделать сегодня. -- Regards. Ded.
Re: CURRENT_TABLE
> Резюме: > По полезности далеко не на первом месте фича, скорее она вредна т.к. > порождает новое поколение проктологов. Конечно, не на первом. На счет вредности в образе зачатия молодых проктологов есть сомнения. Перефразируя известную пословицу, скажем таким образом: хорошему проктологу яйца не мешают :) Другими словами, для таких профессий на ibase.ru есть целая статья, которая говорит, что не надо делать в первую очередь. К слову, если вылезти из танка и выглянуть из люка, то можно получить знание о том, что представители некоторых других серверов причисляют к проктологам всех нас вместе взятых, только при упоминании имени сервера, с которым ты работаешь. Это, конечно, оскорбительно и неприятно и не соответсвтует действительности, в общем... Однако, как говорится, дыма без огня не бывает...
Re: CURRENT_TABLE
> На клиенте просто проще со строками работать. Вот-вот. С этого и надо начинать. Имея CURRENT_TABLE можно иметь возможость не переносить такой код на клиента, из-за того, что он существенно теперь упростится на стороне сервера (не надо вычислять и затем "вклеивать" имена таблиц).
Re: CURRENT_TABLE
> Хм, хоть и не встречались давненько, но я ещё помню - когда ты > начинаешь говорить много, горячо и убедительно, знач пошла демагогия ;) Просто внимательно смотри начальные посты. >Имхо облегчение жизни программиста - это когда его не имеют в хвост и > в гриву ежедневно за то что программа не работает или еле ползает. Ты здесь смотришь со стороны вытекающих. Ведь такой результат (когда не имеют программиста), можно добиться и проктологией в том числе. Мне же более по душе, когда меня не имеет сам проктологический процесс (когда не хватает очевидных вещей на ровном месте). Откуда вывод, что из-за CURRENT_TABLE у меня все тормозить будет? > А некоторые очень хочут получить FB в карманных компах. И я > их понимаю. И я очень хочу тоже. И не раз спрашивал сам :) Пользуясь случаем (с) еще раз хочу! :) >Какая именно польза - я от тебя пока так и не добился. Польза - и всё > тут ;) - Повторяю: польза в том, что в коде триггера можно "программно" узнать, для какой таблицы выполняется его код. - Этого недостаточно? Мучает вопрос зачем это надо? :) Может мне не хочется делать вещи дедовскими способами (в прямом и переносном смысле :)) > Всё-ж таки, что ж эта процедура будет делать? Код, сьестра, код! Да пох абсолютно, что это будет. Причем тут код? > И потом в триггере таблицы Execute Statement S_Return? Или где? Домашнее задание: найти упоминание в моих постах из этого треда, где я говорю об использовании EXECUTE STATEMENT в логирующих триггерах. (Правильный ответ: я не использую EXECUTE STATEMENT в логирующих триггерах). >То есть, не трогая их триггеров вообще? Волшебный супертриггер > всеобщего логирования что ли? Не трогать определения (код) таблиц (добавление полей в них). Это просто триггер. Просто обычный триггер. Самый настоящий триггер. Только который может знать через CURRENT_TABLE на КАКОЙ таблице он исполняется. Это проктология? Проктология здесь в моем понимании как раз не иметь возможность в рантайм иметь в руках эту информацию. >Хде? Хто? Предлагал? >Хде? Хто? Предлагал? >Хде? Хто? Предлагал? Перечитай еще раз и выбери по авторам. Я ж не с потолка взял, а перечитал все, выбирая упомянутые решения. >Лично я предлагал и предлагаю статические триггера генерируемые влёт > совершенно несложной приблудой. Ты может будешь удивлен, но я тоже. Более того, если бы у меня была возможность CURRENT_TABLE, то это я сделал бы ЕЩЕ ПРОЩЕ. Так понятно, из-за чего вопрос о CURRENT_TABLE снова возник? :) Кучу CURRENT_XX сделали? А там нельзя было обойтись "с клиента" или десантом с Марса? А ввод Емановым универсальных триггеров на события? Зачем? И без них все было прекрасно... >Если ты очень настаиваешь, я таки сделаю тебе генератор триггеров > процедурой, получающей на вход имя таблицы. Дык, я ни на чем не настаиваю. Такого добра у самого в достатке. >А кому-то зачем-то надобиццо название базы... А кому-то зачем-то имя > хоста... А кому-то зачем-то пароль SYSDBA... И это уже так или иначе практически есть (см GET/SET CONTEXT), окромя пароля. > Дим, чем слезу давить и тельняшку рвать, ответил бы самому себе хотя бы на > ОВСФ сначала вразумительно, а? Не давлю. Просто я спрашиваю про одно, а меня лечат какой-то хренотенью совершенно не по теме. Я не выношу на обсуждение сейчас механизмы, в которых мне понадобился бы CURRENT_TABLE. Я говорю, что с ним мне было бы легче и проще их реализовать и спрашиваю, чем заканчивались ранее обсуждения этой темы.
Re: CURRENT_TABLE
Hello, Ded!
You wrote on Tue, 07 Mar 2006 19:54:25 +0300:
>>CURRENT_TABLE
Бурная дискуссия.
ИМХО, Единственно зачем это может быть нужно для универсального триггера на
все таблицы
например AFTER UPDATE 255
if (not current_table in('LOG','LOG_DETAIL')) then begin
id=gen_id(log_id_gen,1);
insert into log (id,atable,aoper,auser,adate) values
(:id,CURRENT_TABLE,'UPDATE',CURRENT_USER,CURRENT_TIMESTAMP);
/*пожеланию можно еще деталь вести*/
for select * from rdb$relations
join rdb$fileds .
into ..
do
insert into LOG_DETAIL(id,field_name,old_value,new_value)
values ..;
end
Как результат будет пухнуть база неимоверно, зато можно посмотреть кто что
менял,
хотя тоже самое есть в генерилках статических триггеров тот же
логгинг в Expert (Дед правильно говорит)
Еще один вариант использования для проктологов,
когда в название таблицы отображается ее назначение,
например все документы хранятся с префиксом DOC_
все справочники с префиксом REF_
а в универсальном триггере, выполняется некая логика в зависимости названия
с использованием предопредленных полей.
В прочем это тоже можно релизовать тулзой кторая будет генерить спец.
триггеры сама.
Резюме:
По полезности далеко не на первом месте фича, скорее она вредна т.к.
порождает новое поколение проктологов.
Кстати а что с джойном с внешними источниками данных, например ODBC,
и с другой IB базой
например так
select * from table1 a
join ODBC('table2','CONNECTION_STR') b on a.code=b.code
В планах есть ??
With best regards, Konstantin Zaitcev.
Re: CURRENT_TABLE
Хм, хоть и не встречались давненько, но я ещё помню - когда ты
начинаешь говорить много, горячо и убедительно, знач пошла демагогия ;)
Dmitriy Kovalenko wrote:
> Гм... может я в чем-то ошибаюсь, но я
> вижу, что весь мир движется по
> направлению к облегчению жизни именно
> программистов, читай людей, а не
> "серверов".
Имхо облегчение жизни программиста - это когда его не имеют в хвост и
в гриву ежедневно за то что программа не работает или еле ползает.
> К примеру, добавление Олегом в Yaffil встроенных
> функций демонстрирует гуманный подход
> к людям в своем лучшем виде.
Смотря что за функции. Не хочу тоже ударяться в демагогию, не помню
что именно входит в перечень встроенных функций, выскажу своё общее
отношение: cтроковых - да, всю жизнь не хватало. А вот гиперболический
арктангенс, например, подавляющему большинству нафиг не упал. А сервер
от них меньше не становится. И не у всех ещё, особенно клиентов, по паре
гигов RAM. А некоторые очень хочут получить FB в карманных компах. И я
их понимаю. Такшта гуманность - штука тонкое. Хороший набор хорошо
отлаженных UDF обеспечивает большую гибкость. Хотя лично я за
встраиваивание нескольких, потребных подавляющему большинству, функций.
> Вопросы разного рода логирования и
> репликации были, есть и, смотрю, долгое
> время еще будут актуальными в нашем
> народном сервере. Потому как все
> "лучшее" серверу, а программистам - в
> очередь на курсы по проктологии :)
Сервер должен справляться с этим практицки, а не теоретицки. Тогда и
программистам не надо будет в эту очередь. Впрочем, желающие всё равно
найдутся при любом раскладе ;)
> Еще надо смотреть с точки зрения
> сложности реализации фичи в сервере и
> на соотношение стоимость
> реализации/польза на выходе.
Мою подпись сюда приляпай тоже :)
> И если там делов "на две строки
> и на бутылку пива", то польза от CURRENT_TABLE
> будет многократно больше (плюс уже
> куча всяких CURRENT_XXX имеется), не
> смотря, что могут сделать только к
> версии 4.0.
Какая именно польза - я от тебя пока так и не добился. Польза - и всё
тут ;)
> К примеру, вместо
> того, чтобы, допустим, в коде каждого
> триггера (отдельного) просто повторить
> ОДНУ строку:
> EXECUTE PROCEDURE (CURRENT_TABLE, NEW.ID/OLD.ID, <тип
> операции>);
Всё-ж таки, что ж эта процедура будет делать? Код, сьестра, код!
Что-то вроде
S1='Insert Into '||Current_Table||'_Log ('||'TipOper';
S2='Values ('||:Tip_Oper||;
For Select rdb$field_name from rdb$fields
Where rdb$relation_name=:Current_Table
Into :Field_Name
Do
begin
S1=S1||','||Field_Name;
S2=S2||',New.'||Field_Name;
end
S_Return=S1||') '||S2||')'
И потом в триггере таблицы Execute Statement S_Return? Или где?
(Прим. для начинающих проктологов. Код не рабочий, не старайтесь
копировать, просто пытаюсь заставить Диму, вместо попыток взять на
глотку, сформулировать хотя бы для себя самого свою глобальную идею до
конца).
> и при этом НЕ ТРОГАТЬ логируемые
> таблицы вообще на каком-либо уровне,
> включая логический (это значит, что
> можно добавить/изъять или
> включить/выключить целую
> функциональную логическую часть
> системы, что другие части даже об этом
> _не догадаются_ - обращаю на это
> внимание отдельно)
То есть, не трогая их триггеров вообще? Волшебный супертриггер
всеобщего логирования что ли?
> поступают
> предложения:
> - прописывать руками имена таблиц как
> строковые константы
Хде? Хто? Предлагал?
> - добавления доп полей в таблицы
> (размазывать логику логирования по
> всем таблицам в виде доп полей)
Хде? Хто? Предлагал?
> - использования DEFAULT полей с именем (в
> каждое таки надо прописать руками имя
> таблицы)
Хде? Хто? Предлагал?
> - упоминание про GET/SET CONTEXT
Не вникал. Даже в Context ещё не вникал. Так что не буду спорить.
Лично я предлагал и предлагаю статические триггера генерируемые влёт
совершенно несложной приблудой. Я опять же не вникал в возможности
Эксперта по этому поводу, но имхо он именно это и должен делать. Иначе
нах там вообще их генератор.
> Чем плохо, когда пользователь просто
> пометит чекбокс на клиенте в сетке
> напротив имени таблицы,
Уууу... Когда я слышу про чек и прочие бохи в контексте рассуждений
не только о нутре серввера, а и даже об сиквеле, мой палец тянется к
спусковому крючку пистолета ;)
> а в это время
> для этой таблицы _на стороне сервера_
> сгенерится триггер на поддержку
> логирования?
Именно так ситуация и обстоит ныне. Тока триггер, как и положено,
статический. Не увеличивающий вдвое-втрое время выполнения операций. Без
всякого волшебства. И я лично совершенно против вручения гранаты с
динамикой в триггерах в руки... кхм... кхм... как бы это поделикатней ;)
> Стоимость решения на
> клиенте - стремится к 0. Т.е. просто
> включить/отключить чекбокс с коммитом.
> Т.е. вообще ничего, по сути. Вместо
> этого мне надо делать на клиенте код
> генерации триггеров?
Если ты очень настаиваешь, я таки сделаю тебе ген
Re: CURRENT_TABLE
> Моё отношение к прогрессу: > 1. Докажи, что без этого чего-то сделать невозможно. > 2. Не смог - докажи, что это даёт существенное увеличение > производительности СЕРВЕРА, а не программиста, в достаточно широком > классе задач, Гм... может я в чем-то ошибаюсь, но я вижу, что весь мир движется по направлению к облегчению жизни именно программистов, читай людей, а не "серверов". Другое дело, что кто-то может переусердствовать, не будем упоминать в суе кто именно :) К примеру, добавление Олегом в Yaffil встроенных функций демонстрирует гуманный подход к людям в своем лучшем виде. Ведь без них же можно смело обойтись, сделав реализацию в UDF! Однако, как приятно и УДОБНО, что этого делать не надо. Я уже не говорю про экономию времени и сил на сотворение _элементарных_ UDF и их неминуемую отладку, что еще не гарантирует, что багов в результате не будет. Вопросы разного рода логирования и репликации были, есть и, смотрю, долгое время еще будут актуальными в нашем народном сервере. Потому как все "лучшее" серверу, а программистам - в очередь на курсы по проктологии :) Еще надо смотреть с точки зрения сложности реализации фичи в сервере и на соотношение стоимость реализации/польза на выходе. К слову, никто из Чапаев не высказался по этому вопросу. И если там делов "на две строки и на бутылку пива", то польза от CURRENT_TABLE будет многократно больше (плюс уже куча всяких CURRENT_XXX имеется), не смотря, что могут сделать только к версии 4.0. Если там гиенна огненная это делать, тогда совсем другой разговор и CURRENT_TABLE этого просто не заслуживает. > а не в той личной проктологии, в которую ты сам себя > загнал, забивая болт на правила проектирования. На правила проектирования и проктологические аспекты тоже может быть разное видение. К примеру, вместо того, чтобы, допустим, в коде каждого триггера (отдельного) просто повторить ОДНУ строку: EXECUTE PROCEDURE (CURRENT_TABLE, NEW.ID/OLD.ID, <тип операции>); и при этом НЕ ТРОГАТЬ логируемые таблицы вообще на каком-либо уровне, включая логический (это значит, что можно добавить/изъять или включить/выключить целую функциональную логическую часть системы, что другие части даже об этом _не догадаются_ - обращаю на это внимание отдельно) поступают предложения: - прописывать руками имена таблиц как строковые константы (вспоминаем Коваленко, когда он говорил, что где-то забыл триггер сделать, здесь можно просто сделать ошибку в букве) - добавления доп полей в таблицы (размазывать логику логирования по всем таблицам в виде доп полей) - использования DEFAULT полей с именем (в каждое таки надо прописать руками имя таблицы) - упоминание про GET/SET CONTEXT - кто-то еще призагнул про какие-то ветвления по имени таблицы, вообще не разобравшись в сути треда (это уже проблемы индейцев и где-то таки может быть удобным) И это все менее проктологичнее одной строки кода, плюс сделанной автоматически? (конечно, при прочих равных условиях) Чем плохо, когда пользователь просто пометит чекбокс на клиенте в сетке напротив имени таблицы, а в это время для этой таблицы _на стороне сервера_ сгенерится триггер на поддержку логирования? Стоимость решения на клиенте - стремится к 0. Т.е. просто включить/отключить чекбокс с коммитом. Т.е. вообще ничего, по сути. Вместо этого мне надо делать на клиенте код генерации триггеров? Это дешевле? Он у меня есть, но в данном случае, я хочу, чтобы даже его не было (в общем, это не относится к CURRENT_TABLE). > 4. Ничего доказать не смог - иди в сад со своими хотелками. Голос из сада :))): имхо, если в триггерах кому-то надобится иметь непосредственное название таблицы, то CURRENT_TABLE уже автоматически лучше, со всеми вытекающими, чем прописывать 'MY_TABLE_NAME' в каждом разе. И это все просто БЕЗОТНОСИТЕЛЬНО к разного рода проктологическим приемам.
Re: Опять глючит конектс на Yaffil 889
"Alex Pugovko" ... > Hello, Janex! > You wrote on Tue, 07 Mar 2006 11:32:41 +0200: > > J> Alexander A. Venikov wrote: > Hello, Janex! > ??>> You wrote on Tue, 07 Mar 2006 10:57:45 +0200: > > J>>> голыи ХP с вторым сервиспаком. > XP вроде как не серверная ось, там есть ограничение на 15 (если меня не > глючит) одновременных коннектов или это только на шары... не помню... Это ты про named pipes говоришь -- Хорсун Влад
Re: Опять глючит конектс на Yaffil 889
> XP вроде как не серверная ось, там есть ограничение на 15 (если меня не > глючит) одновременных коннектов или это только на шары... не помню... Опаньки ... Ктото чтото слышал об етом ? На конект к базе врятли будет ограничение, a как там на ети шары ? У меня какраз шас проект где апликуха у клентов бидет запускатся с шареного каталога "сервера "(XP pro) и клиентов можбить и более 15 - хана мне чтоли Regards Janex
Re: Опять глючит конектс на Yaffil 889
Hello, Janex! You wrote on Tue, 07 Mar 2006 11:32:41 +0200: J> Alexander A. Venikov wrote: > Hello, Janex! ??>> You wrote on Tue, 07 Mar 2006 10:57:45 +0200: > J>>> голыи ХP с вторым сервиспаком. XP вроде как не серверная ось, там есть ограничение на 15 (если меня не глючит) одновременных коннектов или это только на шары... не помню... With best regards, Alex Pugovko. E-mail: [EMAIL PROTECTED]
Re: CURRENT_TABLE
Hello, Ded! You wrote on Tue, 07 Mar 2006 14:00:27 +0300: D> Karabas Barabas wrote: D>>> Ай, а default-поле в таблице - уже прошлый век ;) ??>> Какое default-поле ? D> Ну, если увеличить размер записи на 31 символ (а нынче уже и поболе) и D> держать одно и то же в миллионе записей не в падлу, а написать за часок D> генератор триггеров по шаблону в падлу, то оно конешно. Проблема со D> статическими логирующими триггерами не в том, как их сделать не D> утруждаясь особо, а в том, как всё это добро поддерживать не путаясь при D> изменении метаданных Всё понятно :) -
Re[2]: OFF: Friday again
Hello Ded, Tuesday, March 7, 2006, 1:16:02 PM, you wrote: > Marina Novikova wrote: >> Sincerely yours, >> Marina > Мариночка, тебя и в твоём лице всех милых дам с праздником! > http://www.biletovnet.ru/modules/My_eGallery/gallery/leto/ai/P9100119.JPG Лучше так http://forum.4x4club.ru/index.php?act=Attach&type=post&id=6262 -- Best regards, Ruslanmailto:[EMAIL PROTECTED]
Re: CURRENT_TABLE
Знаете в какой то степени он прав. Нужна такая переменная.
Я сам уже и забыл когда впоследний раз эта тема меня мучила. Писались кучи
процедур тел триггиров одинаковые. Но потом из за этой возни пришлось в свой
генератор баз данных внести макрос дабы упростить себе роботу от этой
рутины. Что бы поменять в одном месте и везде поменялось.
и получилось пишем
%SCRIPT(SQLNameIsExistsIns;D025;D025_1;D025_2;IEIIO)
где макрос
IF (NEW.%2:S IS NULL) THEN NEW.%2:S = '%3:S';
IF (EXISTS(SELECT * FROM %0:S S WHERE B_UPPER(S.%2:S) = B_UPPER(NEW.%2:S)
and (S.%1:S <> NEW.%1:S)))
THEN EXECUTE PROCEDURE ERROR('NameIsExists', NEW.%2:S);
после чего генерится
CREATE TRIGGER D025_INS FOR D025 ACTIVE BEFORE INSERT POSITION 1
AS
BEGIN
IF (NEW.D025_2 IS NULL) THEN NEW.D025_2 = 'IEIIO';
IF (EXISTS(SELECT * FROM D025 S WHERE B_UPPER(S.D025_2) =
B_UPPER(NEW.D025_2) and (S.D025_1 <> NEW.D025_1)))
THEN EXECUTE PROCEDURE ERROR('NameIsExists', NEW.D025_2);
END
но это не решение проблемы т.к. если меняется логика нашего макроса
"SQLNameIsExistsIns" наступает пипец который заставит нас перекомпилить все
триггера. Буть переменная можно было просто создать процедуру в которой мы
получили какая таблица вызвала ее и сгенерили бы код.
"Dmitriy Kovalenko" <[EMAIL PROTECTED]>
сообщил/сообщила в новостях следующее:
news:[EMAIL PROTECTED]
> Всем привет.
>
> Имеется ли возможность (вопрос
> теоретический, адресуется шаманам)
> сотворить некую контекстную
> переменную, видимую в теле триггера, да
> бы в нем "программно" знать, для какой
> таблицы выполняется искомое тело
> триггера?
> Если такой вопрос рассматривался уже,
> то чем закончился? Избили ногами
> вопрошающего или "шанс" остался? :)
>
Re: OFF: Friday again
"Vladimir A.Bakhvaloff" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >И от нас тоже!.. %))) > http://www.nmt.ru/ Пардон, чтобы долго не искать о чём "это": http://nmt.ru/&id=121 -- [http://bakh.spb.ru] [email:bob#bakh.spb.ru] [icq:1608235]
Re: OFF: Friday again
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Мариночка, тебя и в твоём лице всех милых дам с праздником! > http://www.biletovnet.ru/modules/My_eGallery/gallery/leto/ai/P9100119.JPG И от нас тоже!.. %))) http://www.nmt.ru/ -- [http://bakh.spb.ru] [email:bob#bakh.spb.ru] [icq:1608235]
Re: OFF: Friday again
Marina Novikova wrote: > Sincerely yours, > Marina Мариночка, тебя и в твоём лице всех милых дам с праздником! http://www.biletovnet.ru/modules/My_eGallery/gallery/leto/ai/P9100119.JPG -- Regards. Ded.
Re: CURRENT_TABLE
aLKoGolik wrote: > Смотрю я, Дед оказывется хоть и старожил, но вовсе не старый, Эт как считать. > хоть, иногда, и воспринимает всё новое в штыки, но тоже не > чужд прогрессу ... Моё отношение к прогрессу: 1. Докажи, что без этого чего-то сделать невозможно. 2. Не смог - докажи, что это даёт существенное увеличение производительности СЕРВЕРА, а не программиста, в достаточно широком классе задач, а не в той личной проктологии, в которую ты сам себя загнал, забивая болт на правила проектирования. 3. Не смог - докажи, что это не абстрактно "удобно" (эт кому как и что), а уменьшает объём кода, делает его читаемым и способствует уменьшению количества ошибок. Опять же в широком классе задач. 4. Ничего доказать не смог - иди в сад со своими хотелками. Кроме того, любое новшество широкими массами проктологов, составляющими до 80% процентов разработчиков "прог", используется в случаях, ровно противоположных тем, которые держали в уме разработавшие его титаны. И прибегают потом в горьких слезах - ну и как же мине теперь быть? Execute чего-нибудь это касается в первую голову. На форумах я ещё НИ РАЗУ не видел чтоб его применяли по месту или советовали применить по месту. Вот так. -- Regards. Ded.
Re: CURRENT_TABLE
Karabas Barabas wrote: > D> Ай, а default-поле в таблице - уже прошлый век ;) > Какое default-поле ? Create Table T( ... DateReg TimeStamp Default 'now', UserReg Char (6) Default Current_User, /*Фантазии не поощряю, 6 */ DateIzm TimeStamp, UserIzm Char (6), Triggers_Off Char(1) Default 'Н' ) Если after-триггера не нужны (а я их избегаю), то Create Trigger T_BI For T Before Insert As Begin if ((New.Triggers_Off is NULL) OR (New.Triggers_Off <> 'Д')) then begin Trigger body; end New.Triggers_Off='Н' End Create Trigger T_BU For T Before Update As Begin if ((New.Triggers_Off is NULL) OR ((New.Triggers_Off = Old.Triggers_Off) And (New.Triggers_Off <> 'Д'))) then begin New.UserIzm=USER; New.DateIzm='NOW; Trigger body; End New.Triggers_Off='Н'; End Такой вот технологический стандарт структуры таблиц. > У меня почему-то появилась мысль добавить в логируемые таблицы поле с ее > именем, тогда в триггере будет доступно имя текущей таблицы. Или это не > кошерно ? Ну, если увеличить размер записи на 31 символ (а нынче уже и поболе) и держать одно и то же в миллионе записей не в падлу, а написать за часок генератор триггеров по шаблону в падлу, то оно конешно. Проблема со статическими логирующими триггерами не в том, как их сделать не утруждаясь особо, а в том, как всё это добро поддерживать не путаясь при изменении метаданных. -- Regards. Ded.
Re: Опять глючит конектс на Yaffil 889
Alexander A. Venikov wrote: > Hello, Janex! > You wrote on Tue, 07 Mar 2006 10:57:45 +0200: > > J> голыи ХP с вторым сервиспаком. > . > J> А в другом учереждение всё тож самое пашет уже третии год без > J> проблем (железо конешно отличается и там только сервиспак 1). > > Со вторым сервиспаком brandmauer по умолчанию ставится. Не в нем проблема? > Попробуй отключить. Отключен конешно ... Regards Janex
Re: Опять глючит конектс на Yaffil 889
> Попробуй отключить, хотя не думаю что из-за этого. Отключил - будем смотреть чё будет... >> Куда копать ? > > Х.З. Почему помогает только рестарт всей машины а не перезапуск сервера? К тому ешё странность токая, что при етои коме нормально остановить сервис птици невозможно. Делал унинстал птицы - прошёл, незнаю как унинсталятор остоновил её но всё прошло. Потом проинсталировал заного - птица запушена, конект непроходит и опят сервис неостоновить - вот только шас непомню питался ли его остановить свежо проинсталированыи или после первого неудачного конекта :( Regards Janex
Re: Опять глючит конектс на Yaffil 889
Hello, Janex! You wrote on Tue, 07 Mar 2006 10:57:45 +0200: J> голыи ХP с вторым сервиспаком. . J> А в другом учереждение всё тож самое пашет уже третии год без J> проблем (железо конешно отличается и там только сервиспак 1). Со вторым сервиспаком brandmauer по умолчанию ставится. Не в нем проблема? Попробуй отключить. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixtntobru
Re: OFF: Friday again
"Marina Novikova" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Oleg >> За отсутствие наклеки Ш и грязные номера попросите в другой раз уазать >> статью КОAП, по которой вас можно привлечь к административной >> ответственности > Про номера, например, можно сослаться на Нечитаемый, нестандартный гос. > номер (50 р штраф) - http://izvestia.ru/auto/article3084664. Номер статьи не > искала, но постараюсь :) Нечитаемый говрите? Выходите из машины и читаете свой номер...что инспектор его не моджет прочитать? Гмтак когда он медкомиссию-то проходил? :-). Вменяемый ИДПС просит просто протереть номера, невменяемый объясняет начальнику какого хера ему опять разбирать жалобу из РУВД/прокуратуры от г.Иванова ;-);-);-)
Re: Опять глючит конектс на Yaffil 889
"Janex" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > А в другом учереждение всё тож самое пашет уже третии год без > проблем (железо конешно отличается и там только сервиспак 1). > Заметил что почемуто поставил "ENABLE_IP_LOG 1" ...ето чтоли > гробит всё ? Попробуй отключить, хотя не думаю что из-за этого. > Куда копать ? Х.З. Почему помогает только рестарт всей машины а не перезапуск сервера?
Опять глючит конектс на Yaffil 889
Приривет алл Писал тут недавно, но таки некто толком ничего непосоветовал :( Проблема старая - через некоторое время невозможно подкэлючится к базе. Когдато было так что с клиентских компов ешё можно было а с самого сервера хрену :( Шас при наступления етои комы сооовсем неоткуда невозможно. На сервере некоких фиреwоллов, неноких антивирусов, некоких левых апликух или "чудо сервисов" - голыи ХP с вторым сервиспаком. Остальное всё идёт - только нету конекта к базе. Делаем конект и он завысает а проц одыхает. Неперестарируя само железо переинсталировал птицу - тож самое. Помогает только рестарт железа, но когдато на 2 недели, а шас уже чуть не каждыи 2-3 день :( Самое последее на что вроде можно грешить ето вроде сетевая карта, но кроме птицы всё остальное пашет нормально ... А в другом учереждение всё тож самое пашет уже третии год без проблем (железо конешно отличается и там только сервиспак 1). Заметил что почемуто поставил "ENABLE_IP_LOG 1" ...ето чтоли гробит всё ? Куда копать ? Ктото можбить может какуюто тулзу посоветовать чем покавырать сервер когда кома наступает чтоб поимать зладея ? :) Regards Janex
