Re: Universal tirggers
А может лучше разработать и предложить механизм предназначенный для решения именно этой задачи ? А не круглого жывотного в безвоздушном пр-ве... В принципе, две таблицы плюс один флаг в RDB$RELATIONS (логировать/не логировать). 2) работа с псевдообъектной БД, для обеспечения возможности наследования поведения объектов БД, вызова ХП. Не понято. тут другая бредовая мысль :) я как то летом здесь поднимал вопрос про наследованные таблицы типа CREATE TABLE B EXTENDS A... В общем, неважно. Как сейчас работает: есть у меня система, в которой все документы наследуются от абстрактного документа. В базе есть таблицы-журналы, в которых храниться шапка документа, при этом все документы регистрируются в главном журнале (он же абстрактный документ). Специфичные для данного вида документа атрибуты хранятся в своих таблицах по связи один-ко-одному с главным журналом. Некоторые документы имеют третий или четвертый уровень иерархии. То есть вот таким проктологическим методом создана объектная БД, где документы потомки наследуют поведение родителей, например, при проведении. В главном журнале есть признак закрытия документа, что значит, что он ушел в историю и изменению не подлежит. В остальных журналах приходиться колотить кучу триггеров, запрещающих редактирование. При этом есть возможность потребителю ПО создавать свой тип документов, расписывать для него проводки, что говорит о не знании на уровне разработки, как документы будут потом созданы. Понятно, конечно, что автогенератор объектов сам втихаря создает триггер, но до базы можно достучаться не только из моего ПО, а например из модулей на ПыХПых, идущих в стандартном комплекте поставки. А вот универсальным триггером можно было бы проанализировать вызвавшую таблицу на предмет зависимости от главного журнала, и если документ закрыт, то выкидывать пользователю отлуп.
Re: Universal tirggers
PEAKTOP ... А может лучше разработать и предложить механизм предназначенный для решения именно этой задачи ? А не круглого жывотного в безвоздушном пр-ве... В принципе, две таблицы плюс один флаг в RDB$RELATIONS (логировать/не логировать). Что логировать ? Как логировать ? Куда логировать ? Давай забудем о триггерах, RDB$RELATIONS и т.п. И сосредоточимся на задаче, а не на вкорячивании сомнительных механизмов для сомнительной полезности решения. 2) работа с псевдообъектной БД, для обеспечения возможности наследования поведения объектов БД, вызова ХП. Не понято. тут другая бредовая мысль :) я как то летом здесь поднимал вопрос про наследованные таблицы типа CREATE TABLE B EXTENDS A... В общем, неважно. Как сейчас работает: есть у меня система, в которой все документы наследуются от абстрактного документа. В базе есть таблицы-журналы, в которых храниться шапка документа, при этом все документы регистрируются в главном журнале (он же абстрактный документ). Специфичные для данного вида документа атрибуты хранятся в своих таблицах по связи один-ко-одному с главным журналом. Некоторые документы имеют третий или четвертый уровень иерархии. То есть вот таким проктологическим методом создана объектная БД, где документы потомки наследуют поведение родителей, например, при проведении. В главном журнале есть признак закрытия документа, что значит, что он ушел в историю и изменению не подлежит. В остальных журналах приходиться колотить кучу триггеров, запрещающих редактирование. При этом есть возможность потребителю ПО создавать свой тип документов, Это новая таблица что-ли ? Надеюсь - нет... расписывать для него проводки, что говорит о не знании на уровне разработки, как документы будут потом созданы. Понятно, конечно, что автогенератор объектов сам втихаря создает триггер, но до базы можно достучаться не только из моего ПО, а например из модулей на ПыХПых, идущих в стандартном комплекте поставки. Закрывай доступ на таблицы, открывай через view\procedure. Ничего нового. А вот универсальным триггером можно было бы проанализировать вызвавшую таблицу на предмет зависимости от главного журнала, и если документ закрыт, то выкидывать пользователю отлуп. А не пробовал *создать* запись о факте зависимости от главного журнала и уже на неё повесить один маленький, серенький, не универсальный, а самый обычный триггер ? -- Хорсун Влад
Re: Universal tirggers
Tonal ... Khorsun Vlad пишет: 1) логирование изменений в таблицах БД (особенно на фоне грядущих А может лучше разработать и предложить механизм предназначенный для решения именно этой задачи ? Типа: LOG SRC_COLUMN_LIST FROM TABLE_LIST [ON [INSERT [OR UPDATE [OR DELETE]]] INTO TABLE (DST_COLUMN_LIST) Где в SRC_COLUMN_LIST включает общин имена столбцов, псевдостолбец TABLE_NAME, псевдостолбец OPERATION со зхначениями (INSERTING | UPDATING | DELETING), кроме того все стандартные выражения. Это уже несколько лучше. Но выглядит как притягивание за уши всем известных механизмов с универсальным логгированием через триггеры и таблицы логов. Не интересно :) Можно ещё добавить функцию CONCAT_FIELD(SEPARATOR=',', ONLY_CHANGED=1, INCLUDE_FIELD_NAME='%name=%value') в которой конкатенируются все остальные, неперечисленные явно поля исходной таблицы, через указанный разделитель, возможно только изменённые, с дополнением именами полей. Тогда логгирование изменений будет выглядеть примерно так: LOG ID, TABLE_NAME, 'update ' || TABLE_NAME || ' set ' || CONCAT_FIELD || ' where ID = ' || ID FROM TABLE1, TABLE2, TABLE3, ON UPDATE INTO LOG_TABLE (ID, TABLE_NAME, SQL) Выглядит ужасно :) -- Хорсун Влад PS это моё личное мнение, а не fb dev team
Re: ANN: FBScanner
Oleg Matveyev пишет: А как лог запросов вести? Можно? в контекстном меню коннекта есть Latest Query последние 20 запросов помнит. Если окно не закрывать (как бы в отладке один коннект), то в него так и будут поступать новые запросы. ОК. Пока так и попробую. Полноценное логгирование увы, недоделал, хотя на малой нагрузке работает. Это будет фича полезная именно для разработчиков. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Universal tirggers
Khorsun Vlad пишет: 1) логирование изменений в таблицах БД (особенно на фоне грядущих А может лучше разработать и предложить механизм предназначенный для решения именно этой задачи ? Типа: LOG SRC_COLUMN_LIST FROM TABLE_LIST [ON [INSERT [OR UPDATE [OR DELETE]]] INTO TABLE (DST_COLUMN_LIST) Где в SRC_COLUMN_LIST включает общин имена столбцов, псевдостолбец TABLE_NAME, псевдостолбец OPERATION со зхначениями (INSERTING | UPDATING | DELETING), кроме того все стандартные выражения. Можно ещё добавить функцию CONCAT_FIELD(SEPARATOR=',', ONLY_CHANGED=1, INCLUDE_FIELD_NAME='%name=%value') в которой конкатенируются все остальные, неперечисленные явно поля исходной таблицы, через указанный разделитель, возможно только изменённые, с дополнением именами полей. Тогда логгирование изменений будет выглядеть примерно так: LOG ID, TABLE_NAME, 'update ' || TABLE_NAME || ' set ' || CONCAT_FIELD || ' where ID = ' || ID FROM TABLE1, TABLE2, TABLE3, ON UPDATE INTO LOG_TABLE (ID, TABLE_NAME, SQL) -- Александр Замараев
Re: Universal tirggers
Это новая таблица что-ли ? Надеюсь - нет... Именно - пользователь (в монопольном режиме, спасибо за MON $ATTACMENTS), не явно для себя и явно для базы, создает таблицу. И мы не знаем, таблица с каким именем будет создана. Чтоб было понятней - типа как конфигуратор в 1С. Закрывай доступ на таблицы, открывай через view\procedure. Ничего нового. Да и без них обходимся - автоматика код запросов генерит (спасибо за EXECUTE BLOCK). Да и объекты в системе подцепляются только те, что созданы системой - той же автоматикой, которая и триггеры создает и проверяет все. Таблиц 150-200, на каждую по три триггера. Куча проверок. Как-то некузяво все это в сумме выглядит. Базу, проработавшую полгода в автономном режиме у заказчика, открывать страшно. А не пробовал *создать* запись о факте зависимости от главного журнала и уже на неё повесить один маленький, серенький, не универсальный, а самый обычный триггер ? Ну дык я и сказал, что автогенератор объектов сам втихаря создает триггер, проверяющий главный журнал.
Re: Invalid parameter in transaction parameter block.
Kovalenko Dmitry wrote: Если это все передается на сервер, то убери rec_version. Он тут не приделах. Юзается только вместе с read_committed Вот. Это типа я блеснул знаниями алгоритма проверки TPB :))) А может, просто игнорировать параметры не при делах ?
Re: Universal tirggers
PEAKTOP ... Это новая таблица что-ли ? Надеюсь - нет... Именно - пользователь (в монопольном режиме, спасибо за MON $ATTACMENTS), не явно для себя и явно для базы, создает таблицу. Зачем ??? И мы не знаем, таблица с каким именем будет создана. Чтоб было понятней - типа как конфигуратор в 1С. (*) Закрывай доступ на таблицы, открывай через view\procedure. Ничего нового. Да и без них обходимся - автоматика код запросов генерит (спасибо за EXECUTE BLOCK). Да и объекты в системе подцепляются только те, что созданы системой - той же автоматикой, которая и триггеры создает и проверяет все. Столько усилий, а результат : Таблиц 150-200, на каждую по три триггера. Куча проверок. Как-то некузяво все это в сумме выглядит. Базу, проработавшую полгода в автономном режиме у заказчика, открывать страшно. (**) Ибо - см (*) А не пробовал *создать* запись о факте зависимости от главного журнала и уже на неё повесить один маленький, серенький, не универсальный, а самый обычный триггер ? Ну дык я и сказал, что автогенератор объектов сам втихаря создает триггер, проверяющий главный журнал. Зачем ??? Раз уж обвязка создаётся динамически, то можно и запись о факте зависимости не забыть создать. Но это вообще всё не нужно, ибо есть же корневая таблица документов. Через её триггеры и делать общесистемные вещи. Хотя я лично считаю, что логику сложнее проверки параметров\логгирования\ рассчёта агрегатов в триггерах держать категорически нельзя. Себе дороже будет - см. (**) -- Хорсун Влад
Re: Invalid parameter in transaction parameter block.
åÓÌÉ ÜÔÏ ×ÓÅ ÐÅÒÅÄÁÅÔÓÑ ÎÁ ÓÅÒ×ÅÒ, ÔÏ ÕÂÅÒÉ rec_version. ïÎ ÔÕÔ ÎÅ ÐÒÉÄÅÌÁÈ. á ÍÏÖÅÔ, ÐÒÏÓÔÏ ÉÇÎÏÒÉÒÏ×ÁÔØ ÐÁÒÁÍÅÔÒÙ ÎÅ ÐÒÉ ÄÅÌÁÈ ? æÓÁÔ. ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: Invalid parameter in transaction parameter block.
Konstantin R. Beliaev wrote: А может, просто игнорировать параметры не при делах ? Откуда серверу знать, что ты хотел: неявно указать read_committed или snapshot но случайно засандалил еще и rec_version? -- Дмитрий Еманов
Полный оффтоп
Случайно наткнулся - в fbclient.dll (2.0.3.12981) ровно 50 раз повторяются названия месяцев. Просто любопытно: они там сами размножаются или так надо? :)
Re: Полный оффтоп
М.Королев [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Случайно наткнулся - в fbclient.dll (2.0.3.12981) ровно 50 раз повторяются названия месяцев. Просто любопытно: они там сами размножаются или так надо? :) Значит он на 50 лет работы рассчитан... With b/r. Gleb.
Re: Universal tirggers
Khorsun Vlad пишет: Это уже несколько лучше. Но выглядит как притягивание за уши всем известных механизмов с универсальным логгированием через триггеры и таблицы логов. Не интересно :) А что бы было интересно? Идею можно несколько развить, например указывать не одну таблицу логов а несколько, и каким-то образом раскидывать по ним поля (например по типам). А можно добавить возможность не только в таблицы заливать, а например в текстовые файлы сразу... LOG ID, TABLE_NAME, 'update ' || TABLE_NAME || ' set ' || CONCAT_FIELD || ' where ID = ' || ID FROM TABLE1, TABLE2, TABLE3, ON UPDATE INTO LOG_TABLE (ID, TABLE_NAME, SQL) Выглядит ужасно :) Ну, мне бы хватило такого: LOG ID, TABLE_NAME FROM TABLE1, TABLE2, TABLE3 ON DELETE INTO SYS_DELETED (ID, TABLE_NAME) -- Александр Замараев
Re: Universal tirggers
Tonal ... Khorsun Vlad пишет: Это уже несколько лучше. Но выглядит как притягивание за уши всем известных механизмов с универсальным логгированием через триггеры и таблицы логов. Не интересно :) А что бы было интересно? Дык. Я не знаю, я пытаюсь народ на нетривиальные идеи развести :) -- Хорсун Влад
Re: ������ ������
óÌÕÞÁÊÎÏ ÎÁÔËÎÕÌÓÑ - × fbclient.dll (2.0.3.12981) ÒÏ×ÎÏ 50 ÒÁÚ ÐÏ×ÔÏÒÑÀÔÓÑ ÎÁÚ×ÁÎÉÑ ÍÅÓÑÃÅ×. ðÒÏÓÔÏ ÌÀÂÏÐÙÔÎÏ: ÏÎÉ ÔÁÍ ÓÁÍÉ ÒÁÚÍÎÏÖÁÀÔÓÑ ÉÌÉ ÔÁË ÎÁÄÏ? :) üÔÏ ÄÌÑ ÚÁËÒÅÐÌÅÎÉÑ ÍÁÔÅÒÉÁÌÁ. ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: distinct и union в 2.1
Taras Kucher ... Эм-м, стесняюсь спросить - так где же взять RC2? Или на публику не выносят сообщения о его выходе? Выносят, когда он уже вышел. Но никто не отменял снапшоты, которые уже не rc1 и практически rc2 -- Хорсун Влад
Re: ������ ������
üÔÏ ÄÌÑ ÚÁËÒÅÐÌÅÎÉÑ ÍÁÔÅÒÉÁÌÁ. ðÏÓÍÏÔÒÅÌ. ðÒÅÄÌÏÖÉ × FB-ÄÅ×ÅÌÅ ÐÅÒÅÎÅÓÔÉ ÓÔÁÔÉÞÅÓËÉÊ ÍÁÓÓÉ× Ó ÎÁÚ×ÁÎÉÑÍÉ ÍÅÓÑÃÅ× ÉÚ ÈÅÄÅÒÁ × CPP ÆÁÊÌ. âØÀÓØ Ï ÚÁËÌÁÄ - ÂÕÄÕÔ Ä×Á ÄÎÑ ÍÕÓÏÌÉÔØ. ðÏÔÏÍ ×ÓÅ ÏÓÔÁÎÅÔÓÑ ËÁË ÐÒÅÖÄÅ. ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: Полный оффтоп
Kovalenko Dmitry ... Это для закрепления материала. Посмотрел. Предложи в FB-девеле перенести статический массив с названиями месяцев из хедера в CPP файл. Бьюсь об заклад - будут два дня мусолить. Потом все останется как прежде. Получи права на запись и сделай сам. :-P -- Хорсун Влад PS нормальные компиляторы сами не допускают размножения идентичных констант
Re: ������ ������
ðÒÅÄÌÏÖÉ × FB-ÄÅ×ÅÌÅ ÐÅÒÅÎÅÓÔÉ ÓÔÁÔÉÞÅÓËÉÊ ÍÁÓÓÉ× Ó ÎÁÚ×ÁÎÉÑÍÉ ÍÅÓÑÃÅ× ÉÚ ÈÅÄÅÒÁ × CPP ÆÁÊÌ. äÏ ËÕÞÉ, ÐÒÅÄÌÏÖÉ ÉÓÐÒÁ×ÉÔØ ÏÂßÑ×ÌÅÎÉÅ ÎÁ const TEXT* const. äÌÑ ÇÁÒÁÎÔÉÉ ËÏÎÅÞÎÏÇÏ ÎÕÌÅ×ÏÇÏ ÒÅÚÕÌØÔÁÔÁ ;) ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: Полный оффтоп
Kovalenko Dmitry пишет: Предложи в FB-девеле перенести статический массив с названиями месяцев из хедера в CPP файл. До кучи, предложи исправить объявление на const TEXT* const. Для гарантии конечного нулевого результата ;) Дима, на обижайся на американцев, им и так уже несладко. -- Кочмин Александр
Re: ������ ������
PS ÎÏÒÍÁÌØÎÙÅ ËÏÍÐÉÌÑÔÏÒÙ ÓÁÍÉ ÎÅ ÄÏÐÕÓËÁÀÔ ÒÁÚÍÎÏÖÅÎÉÑ ÉÄÅÎÔÉÞÎÙÈ ËÏÎÓÔÁÎÔ åÓÌÉ Õ ÎÉÈ ×ÙÓÔÁ×ÌÅÎÙ ÓÏÏÔ×ÅÔÓ×ÅÔÓ×ÕÀÝÉÅ ÏÐÃÉÉ ËÏÍÐÉÌÑÃÉÉ. ðÏ ÕÍÏÌÞÁÎÉÀ ÍÅÒÖÅ ÎÅ ×ÙÐÏÌÎÑÅÔÓÑ (ÞÔÏ Õ VC ÞÔÏ Õ BCB). þÔÏÂÙ ÎÅ ÎÁÐÕÇÁÔØ ÓÔÒÁÎÎÙÍ ÐÏ×ÅÄÅÎÉÅÍ. ðÒÏ GCC ÐÒÉ ×ÏÐÒÏÓÅ ÎÁ ÜÔÕ ÔÅÍÕ (ÐÁÒÕ ÍÅÓÑÃÅ× ÎÁÚÁÄ) ÐÏÖÁÌÉ ÐÌÅÞÁÍÉ - ÔÉÐÁ ÁÈÅÚ ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: distinct и union в 2.1
Dmitry Yemanov пишет: Alexander A. Venikov wrote: А где оно? :) Где обычно. Эм-м, стесняюсь спросить - так где же взять RC2? Или на публику не выносят сообщения о его выходе? С уважением, Тарас Кучер
Re: Полный оффтоп
Kovalenko Dmitry ... Предложи в FB-девеле перенести статический массив с названиями месяцев из хедера в CPP файл. До кучи, предложи исправить объявление на const TEXT* const. Для гарантии конечного нулевого результата ;) Сначала ты поработаешь с кодом IB6 :-D А уже потом, оценив разницу... -- Хорсун Влад
Re: distinct и union в 2.1
Hello, Khorsun! You wrote on Fri, 7 Mar 2008 12:17:13 +0200: KV Выносят, когда он уже вышел. Но никто не отменял KV снапшоты, которые уже не rc1 и практически rc2 Так бы сразу и сказал... (с) -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: ������ ������
óÎÁÞÁÌÁ ÔÙ ÐÏÒÁÂÏÔÁÅÛØ Ó ËÏÄÏÍ IB6 :-D èÁ. á ÕÖÅ ÐÏÔÏÍ, ÏÃÅÎÉ× ÒÁÚÎÉÃÕ... ÷ÅÒÎÕÔØÓÑ Ë Ó×ÏÉÍ ÐÒÏÅËÔÁÍ ÎÁ C++? üÔÏ ÍÙÓÌØ ÍÅÎÑ ×ÓÅ ÞÁÝÅ ÐÏÓÅÝÁÅÔ. ëÏ×ÁÌÅÎËÏ äÍÉÔÒÉÊ.
Re: Переход на 2.1 (CORE-1776)
Hello, Леонид! Леонид Агафонов wrote: I'd said its not an Firebird problem as nobody guaranteed compatibility with Yaffil at BLR level читать надо. никто не гарантирует совместимости с чужим BLR. Это касается как blr Yaffil так и blr ib 6.5/7.0/7.5/2007. как бы, всегда было известно, что blr не перекомпилируется при ресторе. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Переход на 2.1 (CORE-1776)
Dmitri Kuzmenko wrote: читать надо. никто не гарантирует совместимости с чужим BLR. Это касается как blr Yaffil так и blr ib 6.5/7.0/7.5/2007. как бы, всегда было известно, что blr не перекомпилируется при ресторе. Прямо напрашивается ключик в GBAK: Перекомпиляция объектов :-) PS. Я знаю куда... :-)
Re: Переход на 2.1 (CORE-1776)
Леонид Агафонов ... Добрый день! Может я что-то пропустил, но всегда считал что достаточно бэкап/ ресторе (ну для 2.1 + обновление метаданых), а оказывается надо вычисляемые поля пересоздавать ? http://tracker.firebirdsql.org/browse/CORE-1776 Vlad Khorsun - Recreating computed column USR$BALANCE COMPUTED BY (IIF(USR$ENDSALDO = 0, USR$ENDSALDO, 0)) solved the issue I'd said its not an Firebird problem as nobody guaranteed compatibility with Yaffil at BLR level Всегда и везде для перехода между разными серверами (а не версиями одного сервера) рекомендуют делать это через скрипт + заливку данных. -- Хорсун Влад
Re: Переход на 2.1 (CORE-1776)
On Fri, 07 Mar 2008 16:23:51 +0300, Konstantin R. Beliaev [EMAIL PROTECTED] wrote: Прямо напрашивается ключик в GBAK: Перекомпиляция объектов Нет уж, нафиг-нафиг. Хорошо, что наоборот сделали, рестор без проверки validity. У нас мОлодцы уже начудили. Перекомпилить и из Эксперта можно. С гораздо более продуктивным результатом. Кстати, хорошая идея по поводу пересоздания COMPUTED FIELDS. Надо у Хвастунова спросить. -- Сергей Смирнов.
Re: Полный оффтоп
Мадорский Г.В. пишет: Случайно наткнулся - в fbclient.dll (2.0.3.12981) ровно 50 раз повторяются названия месяцев. Просто любопытно: они там сами размножаются или так надо? :) Значит он на 50 лет работы рассчитан... :) А зачем тогда в 2.1 поправили?
Re: Universal tirggers
ÏÎ ÕÛÅÌ × ÉÓÔÏÒÉÀ É ÉÚÍÅÎÅÎÉÀ ÎÅ ÐÏÄÌÅÖÉÔ. ÷ ÏÓÔÁÌØÎÙÈ ÖÕÒÎÁÌÁÈ ÐÒÉÈÏÄÉÔØÓÑ ËÏÌÏÔÉÔØ ËÕÞÕ ÔÒÉÇÇÅÒÏ×, ÚÁÐÒÅÝÁÀÝÉÈ ÒÅÄÁËÔÉÒÏ×ÁÎÉÅ. ðÒÉ ÜÔÏÍ ÅÓÔØ ×ÏÚÍÏÖÎÏÓÔØ ÐÏÔÒÅÂÉÔÅÌÀ ðï ÓÏÚÄÁ×ÁÔØ Ó×ÏÊ ÔÉÐ ÄÏËÕÍÅÎÔÏ×, ÒÁÓÐÉÓÙ×ÁÔØ ÄÌÑ ÎÅÇÏ ÐÒÏ×ÏÄËÉ, ÞÔÏ ÇÏ×ÏÒÉÔ Ï ÎÅ ÚÎÁÎÉÉ ÎÁ ÕÒÏ×ÎÅ ÒÁÚÒÁÂÏÔËÉ, ËÁË ÄÏËÕÍÅÎÔÙ ÂÕÄÕÔ ÐÏÔÏÍ ÓÏÚÄÁÎÙ. ðÏÎÑÔÎÏ, ËÏÎÅÞÎÏ, ÞÔÏ Á×ÔÏÇÅÎÅÒÁÔÏÒ ÏÂßÅËÔÏ× ÓÁÍ ×ÔÉÈÁÒÑ ÓÏÚÄÁÅÔ ÔÒÉÇÇÅÒ, ÎÏ ÄÏ ÂÁÚÙ ÍÏÖÎÏ ÄÏÓÔÕÞÁÔØÓÑ ÎÅ ÔÏÌØËÏ ÉÚ ÍÏÅÇÏ ðï, Á ÎÁÐÒÉÍÅÒ ÉÚ ÍÏÄÕÌÅÊ ÎÁ ðÙèðÙÈ, ÉÄÕÝÉÈ × ÓÔÁÎÄÁÒÔÎÏÍ ËÏÍÐÌÅËÔÅ ÐÏÓÔÁ×ËÉ. á ×ÏÔ ÕÎÉ×ÅÒÓÁÌØÎÙÍ ÔÒÉÇÇÅÒÏÍ ÍÏÖÎÏ ÂÙÌÏ ÂÙ ÐÒÏÁÎÁÌÉÚÉÒÏ×ÁÔØ ×ÙÚ×Á×ÛÕÀ ÔÁÂÌÉÃÕ ÎÁ ÐÒÅÄÍÅÔ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÇÌÁ×ÎÏÇÏ ÖÕÒÎÁÌÁ, É ÅÓÌÉ ÄÏËÕÍÅÎÔ ÚÁËÒÙÔ, ÔÏ ×ÙËÉÄÙ×ÁÔØ ÐÏÌØÚÏ×ÁÔÅÌÀ ÏÔÌÕÐ. ôÕÔ ÐÒÏÓÔÏ. äÏÞÅÒÎÑÑ ÔÁÂÌÉÃÁ ×ÓÅÇÄÁ ÄÏÌÖÎÁ ÄÅÌÁÔØ ÈÏÌÏÓÔÏÊ update ÔÏÇÏ ÓÁÍÏÇÏ ÇÌÁ×ÎÏÇÏ ÖÕÒÎÁÌÁ. ÷ÙËÉÄÙ×ÁÊ ÐÏÌØÚÏ×ÁÔÅÌÀ ÏÔÌÕÐ ÏÔÔÕÄÁ, ÅÓÌÉ ÄÏËÕÍÅÎÔ úÁËÒÙÔ.
Re: Коннект к классику
Гарантированно классик не пашет с клиентами проксей WinGate (я проводил эксперименты, плюс проблема у клиента) MS Proxy (у клиента кто-то включил на серваке) какие-то еще. Т.е. есть четких 4 случая которые я наблюдал воочию. Плюс масса сообщений на эту тему была одно время. Так что можно сказать, что и с WinRoute оно работать не будет с 99% вероятностю, если ему негде сказать не трогать конкретный порт или процесс. Запиши сюда ещё NOD32 с включённым INET Monitor - тоже winsock корёжит.
Re: Коннект к классику
Игорь Бигдан ... Гарантированно классик не пашет с клиентами проксей WinGate (я проводил эксперименты, плюс проблема у клиента) MS Proxy (у клиента кто-то включил на серваке) какие-то еще. Т.е. есть четких 4 случая которые я наблюдал воочию. Плюс масса сообщений на эту тему была одно время. Так что можно сказать, что и с WinRoute оно работать не будет с 99% вероятностю, если ему негде сказать не трогать конкретный порт или процесс. Запиши сюда ещё NOD32 с включённым INET Monitor - тоже winsock корёжит. Да, кстати, есть подозрение, что невозможность более 63-х коннектов по TCP - его рук дело. Если есть возможность - проверь и расскажи здесь, плс -- Хорсун Влад
Re: ������� �� 2.1 (CORE-1776)
Hello, WildSery! You wrote on Fri, 07 Mar 2008 17:06:07 +0300: Прямо напрашивается ключик в GBAK: Перекомпиляция объектов W Нет уж, нафиг-нафиг. Хорошо, что наоборот сделали, рестор без проверки W validity. А как ключ, который ведь никто не заставляет указывать, мне кажется, самое то... -- -=Лечил тyт одного то желтyхи, недолечил - помеp он. а как вскpыли - оказалось, китаец..=- With best regards, Nikolay Ponomarenko
Re: Пустая агрегатная функция
+1
Re: Загадка с репликацией...
В скрипте не видно обработки ошибок. Файл не удалился? Запрос вернул пусто и скрипт стал пустым? Как пользователь уведомляется об ошибке? Дмитрий
