Использую: Yaffil 884, Delphi7 + IBX.
Программу необходимо наделить следующей функциональностью:
Пример:
Сидит куча пользователей (например, около 100 коннектов), и у каждого пользователя открыто около 10-ти документов, которые они редактируют и сохраняют. Документу соответствует строка в таблице IB, где PK=ID документа.
При этом, у пользователей могут быть открыты одни и те же документы или, например, зависимые между собой (т.е. изменение одного влечет соотв. изменение другого).
Так вот, необходимо при подтвержденном изменении документов сообщать пользователям, у которых открыты соотв. документы, что надо бы их обновить. Причем нужно делать это с сервера, а не с ib-клиентов, т.к. изменения зависимых документов и т.д.
инициирует сервер, также к нему приконнектчен модуль синхронизации с удаленными точками, активно загружающий в него данные по журналу логов.
Вопрос в следующем: Как лучше организовать механизм оповещения об изменении документов?
В голову приходят два варианта, какой лучше организовать?
ВАРИАНТ1:
В таблицу с такими документами добавляется поле, в котором ведется версия документа, и где-то там в тригерах оно инкрементируется из генератора (одного для всех документов), в тех же тригерах посылается общий post_event ib-клиентам. Получив этот event, ib-клиенты запрашивают версии открытых ими документов, тем самым, помечая у себя устаревшие.
Далее, при необходимости, пользователь обновляет такие документы.
Так вот тут, как мне кажется, после каждого такого eventa будет затор, так как все клиенты ринутся проверять на сервере версии документов. Докумены меняются часто и, бывает, каскадно.
ВАРИАНТ2:
Организовать рассылку признаков изменений документов в одном напровлении.
Т.е. сделать псевдо-параметризированный post_event: "общий event" || Cast(ID документа as Varchar(15)).
При этом, ib-клиенты будут реагировать только на те сообщения, которые соответствуют открытым документам.
(придется такие сообщения каждый раз регестрировать в TIBEvents при открытии документов на клиенте).
Что лучше рассылать кучу event-ов на ib-клиентов или выполнять кучу запросов?
Можно, конечно, у клиентов таймеров наставить, чтобы все одновременно запросы не слали, но мне кажется,
это не выход.
И еще, помню где-то проскакивали пожелания о необходимости сделать в IB праметризированные
event-ы типа post_event aaa(n). Что известно по этому вопросу?
Оповещение ib-клиентов об изменении данных
Модератор: kdv
тебе надо внимательно почитать
www.ibase.ru/devinfo/pslock.htm
евенты использовать практически нельзя, т.к. у тебя возникнет туча бесполезных перечитываний. Кстати, параметры в евентах так и не сделали именно потому, что их пытаются использовать в подобных системах, а это неправильно и как минимум приводит к проблемам производительности.
www.ibase.ru/devinfo/pslock.htm
евенты использовать практически нельзя, т.к. у тебя возникнет туча бесполезных перечитываний. Кстати, параметры в евентах так и не сделали именно потому, что их пытаются использовать в подобных системах, а это неправильно и как минимум приводит к проблемам производительности.
Я допускаю теретически, что есть такие задачи, когда требуется одновременная работа с одними документами нескольких пользователей, но интересно было бы увидеть хоть одну на практике. Есть такое волшебное слово - декомозиция. Информационных потоков и функций. Что за характер документов и задач, если не секрет?
Спасибо за статью. У меня что-то уже подобным образом решено.
Но вопрос остается. Так, например, при редактировании документа,
всегда выполняются две пишущие короткие транзакции (как минимум первая).
1. При нажатии пользователем «редактировать документ» - в этот момент можно узнать,
что документ уже кем то редактируется и следовательно, можно заблокировать его от редактирования или хотя бы сообщить об уже имеющему место быть факте редактирования.
2. При нажатии пользователем «Сохранить документ» - тут тоже можно что-то выяснить о сохраненном изменении или начале редактировании этого документа другим пользователем (т.е. выполнялись ли такие же транзакции с этим документом другим пользователем).
Здесь все решается, если вести версии документа, как я писал.
В принципе этим можно обойтись, но остается момент между этими транзакциями, когда пользователь ковыряя в носу что-то там ручками в документе правит и не знает, что кто-то еще хочет начать редактировать тот же документ и не может это сделать (если делать псевдо-блокировку) или уже данные изменены (если другой пользователь ограничивается предупреждением и игнорирует его).
Понятно, что за этим стоит цена вопроса и заказчику можно сказать, что мол извиняйте.
И скорее всего, эта функциональность нужна ему из-за эстетических соображений, хотя он говорит, что на этом может потерять деньги. Поэтому я и вопрос в конфу задал, чтобы уяснить цену вопроса для себя и аргументировать это заказчику.
Так вот еще один теоретический вопрос по поводу event:
Если это касалось перезапросов данных с сервера по event-ам, то мне достаточно в одну сторону предупредить пользователя, что документ начал редактироваться другим – а дальше он сам смотрит, обновлять данные или нет.
В общем спасибо за аргументы, может попробую реализовать оба варианта в свободное время и посмотрю, что получится
Но вопрос остается. Так, например, при редактировании документа,
всегда выполняются две пишущие короткие транзакции (как минимум первая).
1. При нажатии пользователем «редактировать документ» - в этот момент можно узнать,
что документ уже кем то редактируется и следовательно, можно заблокировать его от редактирования или хотя бы сообщить об уже имеющему место быть факте редактирования.
2. При нажатии пользователем «Сохранить документ» - тут тоже можно что-то выяснить о сохраненном изменении или начале редактировании этого документа другим пользователем (т.е. выполнялись ли такие же транзакции с этим документом другим пользователем).
Здесь все решается, если вести версии документа, как я писал.
В принципе этим можно обойтись, но остается момент между этими транзакциями, когда пользователь ковыряя в носу что-то там ручками в документе правит и не знает, что кто-то еще хочет начать редактировать тот же документ и не может это сделать (если делать псевдо-блокировку) или уже данные изменены (если другой пользователь ограничивается предупреждением и игнорирует его).
Документы разные, например накладные - т.е финансовые, касаются учета средств.Merlin писал(а):Я допускаю теретически, что есть такие задачи, когда требуется одновременная работа с одними документами нескольких пользователей, но интересно было бы увидеть хоть одну на практике. Есть такое волшебное слово - декомозиция. Информационных потоков и функций. Что за характер документов и задач, если не секрет?
Понятно, что за этим стоит цена вопроса и заказчику можно сказать, что мол извиняйте.
И скорее всего, эта функциональность нужна ему из-за эстетических соображений, хотя он говорит, что на этом может потерять деньги. Поэтому я и вопрос в конфу задал, чтобы уяснить цену вопроса для себя и аргументировать это заказчику.
Так вот еще один теоретический вопрос по поводу event:
Что подразумевалось под "перечитыванием" - данных при реакции на event-ы или самого списка текущих event-ов. Я не совсем знаю как физически устроен механизм event-ов в IB, поэтому и спрашиваю (прошу не бить). Неужели event-ы широковещательные, а ib-клиент сам разбирает, что для него, а что нет (тогда зачем нужна регистрация сообщений)? Или они адресные по регистрации ib-клиентом их на сервере?kdv писал(а): евенты использовать практически нельзя, т.к. у тебя возникнет туча бесполезных перечитываний
Если это касалось перезапросов данных с сервера по event-ам, то мне достаточно в одну сторону предупредить пользователя, что документ начал редактироваться другим – а дальше он сам смотрит, обновлять данные или нет.
В общем спасибо за аргументы, может попробую реализовать оба варианта в свободное время и посмотрю, что получится
Не ответ. Не вижу причин для того, чтобы два человека одновременно должны были редактировать одну накладную, следственно, действо сие надобно запретить, следственно, через пессимистическую блокировку заголовка. Если от неё или её состава триггерА меняют какие-то хранимые агрегаты, решать вопрос инкрементными апдейтами в read commited транзакции с обработкой конфликтов. С ковырятелеми в носу разбираться организационными средствами, сиречь ловить и учить рублём. Учатся с первого разу, проверено электроникой. То, что ты задумал - от лукавого. Не срастётся.VictorIn писал(а): Документы разные, например накладные - т.е финансовые, касаются учета средств.
Я так пока и сделал. При начале редактирования документ блокируется для редактирования другими. Используется пессимистическая блокировка, еслипользоваться вариантами статьи http://www.ibase.ru/devinfo/plocks.htm , то у меня похоже на второй вариант, но без использования временной таблицы со списком заблокированных документов, т.к. есть проблема с очисткой этой таблицы (например, разрыв коннекта - и записи там будут висеть) - хотя можно этот вариант доработать: либо устроить для работы с этой таблицей транзакции с грязным чтением и их не подтверждать, либо использовать current_connection и при каждом новом коннекте ib-клиент ее очищает по своему current_connection.Merlin писал(а): Не ответ. Не вижу причин для того, чтобы два человека одновременно должны были редактировать одну накладную, следственно, действо сие надобно запретить, следственно, через пессимистическую блокировку заголовка. Если от неё или её состава триггерА меняют какие-то хранимые агрегаты, решать вопрос инкрементными апдейтами в read commited транзакции с обработкой конфликтов
Я использую поле с версией документа – очень удобно.
Все каскадные обновления производятся инкрементными апдейтами в триггерах, все в коротких транзакциях – проблем с целостность не наблюдается. И даже если одновременно редактировать и сохранять одно и тоже, все отрабатывается грамотно – итоги, промежуточные данные и т.д.– все Ок.
Проблема не в этом, а только в удобстве работы пользователей.
Согласен, что это административная проблема и зависит от того, как устроен документооборот на территории заказчика. Дело в том, что у меня в программе документ проходит несколько этапов через разных пользователей и тут возникают проблемы не только с одновременным редактированием.Merlin писал(а): С ковырятелеми в носу разбираться организационными средствами, сиречь ловить и учить рублём. Учатся с первого разу, проверено электроникой. То, что ты задумал - от лукавого. Не срастётся.
Например, кладовщик по накладной набирает товар для отгрузки и ходит (или катается на погрузчике) не с отпечатанной бумажкой, а со сканером штрих кода по огромному складу.
Погрузив все, он идет к компу и скидывает в документ подтверждения об отгрузке определенного количества. Он даже еще не стал редактировать документ – он у него просто висит у него открытым, а менеджер уже там что-то исправил (бывают причины). Т.е. отгрузив тонны и подойдя со сканером к компу для выгрузки данных, весь в поту он узнает, что надо все переделывать – тут уж ни какая пессимистическая блокировка не поможет. Что-то можно решить системой последовательного визирования документов при прохождении последних по всей цепочки исполнителей. Например, передали документ кладовщику – менеджер уже не может в нем ни чего исправить.
Но такие ограничения не всем заказчикам подходят. (Одному я сделал вариант, как в Макдоналдсе – жесткое разграничение прав на редактирование документов и как следствие, бегающий между менеджерами человек «с ключикам» и вводящий пароль на право редактирования. Выдержали только месяц).
И вот такие несостыковки и ограничения бьют по нервам пользователей – они по заказчику – а он по мне. А если кладовщик и менеджер после работы вместе пиво пьют, то всегда будет виновата программа!
Вот и надо что-то делать.
Извиняюсь за беллетристику.
Последний раз редактировалось VictorIn 29 окт 2005, 01:56, всего редактировалось 2 раза.
Забудь про dirty read. Его нет и он вообще не выход, почему - рассказывать долго. Я не понял, что тебе даст current_connection? Оно стабильно только на протяжении жизни соединения. По той ссылке, что дал тебе kdv, расписаны варианты разной сложности, 100% работающие без проблем при любых ситуациях в очаге ядерного взрыва, имеющие единственный недостаток - не определить кто держит запись. Это данность. Либо так, либо проблемы с отвалами.VictorIn писал(а): Я так пока и сделал. При начале редактирования документ блокируется для редактирования другими. Используется пессимистическая блокировка, еслипользоваться вариантами статьи ttp://www.ibase.ru/devinfo/plocks.htm, то у меня похоже на второй вариант, но без использования временной таблицы со списком заблокированных документов, т.к. есть проблема с очисткой этой таблицы (например, разрыв коннекта - и записи там будут висеть) - хотя можно этот вариант доработать: либо устроить для работы с этой таблицей транзакции с грязным чтением и их не подтверждать, либо использовать current_connection и при каждом новом коннекте ib-клиент ее очищает по своему current_connection.
Я использую поле с версией документа – очень удобно.
Он должен висеть не только открытым, но и заблокированным. Как раз для того, чтоб менеджер уже не встрял, во всяком случае без дополнительных внесистемных телодвижений. Скажем, позвонить и попросить открыть ему документ на редактирование (выслушав кучу матов в свой адрес), изменить, позвонить опять и если изменения значительные, послушать ещё. Одновременная работа кладовщика и менеджера с документом - надёжный способ добиться того, чтобы отгружено было не то, что нужно (в read commited, требующемся для триггеров) или получить отлуп при подтверждении отгрузки и начать всё сначала (в concurrency).VictorIn писал(а):
Проблема не в этом, а только в удобстве работы пользователей.
Дело в том, что у меня в программе документ проходит несколько этапов через разных пользователей и тут возникают проблемы не только с одновременным редактированием.
Например, кладовщик по накладной набирает товар для отгрузки и ходит (или катается на погрузчике) не с отпечатанной бумажкой, а со сканером штрих кода по огромному складу.
Погрузив все, он идет к компу и скидывает в документ подтверждения об отгрузке определенного количества. Он даже еще не стал редактировать документ – он у него просто висит у него открытым,
Именно. Что и достигается именно пессимистической блокировкой по-правильному. Без системы визирования и без ограничений на возможность переделки в любой момент, но через маты, и потому стараясь этого избегать.VictorIn писал(а): а менеджер уже там что-то исправил (бывают причины). Т.е. отгрузив тонны и подойдя со сканером к компу для выгрузки данных, весь в поту он узнает, что надо все переделывать – тут уж ни какая пессимистическая блокировка не поможет. Что-то можно решить системой последовательного визирования документов при прохождении последних по всей цепочки исполнителей. Например, передали документ кладовщику – менеджер уже не может в нем ни чего исправить.
Но такие ограничения не всем заказчикам подходят.
Голубчик, да ты ещё совсем не разобрался в этой жизниVictorIn писал(а): А если кладовщик и менеджер после работы вместе пиво пьют, то всегда будет виновата программа!
Вот и надо что-то делать.
Программа и программист будут виноваты всегда и во всём, независимо от пива, её настоящего качества и фазы Луны. Это крест профессии. Делать надо вот что. Надо организовывать регламент и конвейер информационных функций так, чтобы каждый последующий зависел от действий предыдущего и _знал_ это. Они по любому будут вместе мативировать программиста, который должен выработать к этому психологический иммунитет, но, независимо от этого, каждый будет знать кого пинать, чтоб, невзирая на гада проограммиста, выполнить свою задачу и не получить по жопе самому. Вот так весь мир вертИтся (С). А автоматизировать хаос - это дорога к тому, чтоб действительно стать виноватым.По поводу блокировки: Сперва извиняюсь, что не уточнял, как устроен у меня документ. Устроен он в общем стандартно: таблица c заголовками(шапками) документов с PK=ID документа и кучей связанных с ней таблиц с составами, атрибутами, доп. справочниками и т.д. В контексте пессимистической блокировки мне достаточно следить только за таблицей с заголовками, а остальное в упрощении не интересует.
Поэтому для меня приемлемо что-то вроде второго варианта из статьи http://www.ibase.ru/devinfo/plocks.htm без использования транзакционного механизма блокировок самого сервера
У меня пока реализован механизм, когда блокировка записей происходит в самой таблице заголовков документов через дополнительные поля. Но если приложение вылетает, то блокировка остается висеть. Т.е. вариант с возможным отвалом. Лучше не придумал, если не опять через все те же event-ы.
Конечно, все это более или менее решается – по крайне мере я этот режим сделал опционально, можно отключить в любой момент. Если заказчик хочет то, что только через жопу можно сделать, то выхода два - или делать, или послать. Опять же - цена вопроса.
Если припрет, всегда можно их на место поставить. Для нас что важно? Что бы директор канители был доволен, а остальные это уже следствие, кусающее локти. Вот так - пренебрежительно!
В этой статье только о методах с использованием транзакционного механизма блокировок самого сервера. Вариант длительной транзакции с «холостым update» вначале и последующим ожиданием, когда пользователь соблаговолит вызвать commit мне не подходит, т.к. к базе прицеплен модуль загружающий в нее данные из удаленных точек и его dead lock-ом кормить нежелательно, плюс возможны каскадные обновления документов, не связанные с явным редактированием пользователя. Кстати, я использую вариант с «холостым update» в нескольких местах, но все это в коротких транзакциях, когда после холостого update идет обработка данных на клиенте без участия пользователя, но с запросами на сервер или даже промежуточными апдейтами, когда критично, чтоб другие пишущие транзакции в этот короткий момент не вклинились. Причем холостой update работает по специальному полю с версией записи. Такое поле у меня в каждой таблице для обхода триггеров, т.к. в них помимо всего ведутся логи для выгрузки данных на удаленные точки.Merlin писал(а):... По той ссылке, что дал тебе kdv, расписаны варианты разной сложности, 100% работающие без проблем при любых ситуациях в очаге ядерного взрыва, имеющие единственный недостаток - не определить кто держит запись. Это данность. Либо так, либо проблемы с отвалами.
Поэтому для меня приемлемо что-то вроде второго варианта из статьи http://www.ibase.ru/devinfo/plocks.htm без использования транзакционного механизма блокировок самого сервера
У меня пока реализован механизм, когда блокировка записей происходит в самой таблице заголовков документов через дополнительные поля. Но если приложение вылетает, то блокировка остается висеть. Т.е. вариант с возможным отвалом. Лучше не придумал, если не опять через все те же event-ы.
Конечно, все это более или менее решается – по крайне мере я этот режим сделал опционально, можно отключить в любой момент. Если заказчик хочет то, что только через жопу можно сделать, то выхода два - или делать, или послать. Опять же - цена вопроса.
Это ссори.. забыл, что dirty read в IB нет, а помогло бы, если реализовать блокировки через отдельную таблицу. Dirty read использовать только с этой таблицей. Плюс в том, что dirty read транзакцию не надо подтверждать и при обрыве соединения она отвалится, а в месте с ней и все добавленные ею записи – Пользователь закончил редактирование!Merlin писал(а):Забудь про dirty read. Его нет и он вообще не выход, почему - рассказывать долго.
Это я имел ввиду current_user_id - это моя переменная, в смысле пользователь. Я просто в чем-то схожей задаче с временными таблицами curren_connection использую, вот и опечатка вышла...Merlin писал(а):... Я не понял, что тебе даст current_connection?
Это все понятно, еще бы, какой-то там манагер или складун нам программистам указывал.Merlin писал(а):... Они по любому будут вместе мативировать программиста, который должен выработать к этому психологический иммунитет, но, независимо от этого, каждый будет знать кого пинать, чтоб, невзирая на гада проограммиста, выполнить свою задачу и не получить по жопе самому.
Если припрет, всегда можно их на место поставить. Для нас что важно? Что бы директор канители был доволен, а остальные это уже следствие, кусающее локти. Вот так - пренебрежительно!
заказчику можно просто культурно объяснить, в чем он неправ.Если заказчик хочет то, что только через жопу можно сделать, то выхода два - или делать, или послать. Опять же - цена вопроса.
Ведь до внедрения автоматизации что то там как то работает, правда? Например, банально при помощи бумажек. Собственно, большей свободы, чем в этом случае, заказчику лучше не давать.
Если таки призадуматься то dirty read есть - в PK\UK\FK, нужно только уметь его готовитьVictorIn писал(а):Это ссори.. забыл, что dirty read в IB нет, а помогло бы, если реализовать блокировки через отдельную таблицу. Dirty read использовать только с этой таблицей. Плюс в том, что dirty read транзакцию не надо подтверждать и при обрыве соединения она отвалится, а в месте с ней и все добавленные ею записи – Пользователь закончил редактирование!Merlin писал(а):Забудь про dirty read. Его нет и он вообще не выход, почему - рассказывать долго.
Заводим табличку с одним полем и PK на нём.
Перед началом редактирования док-та вставляем туда запись с PK док-та в отдельной тр-ции, которую не коммитим.
Это всё.
Re: Оповещение ib-клиентов об изменении данных
Не вижу криминала.VictorIn писал(а):ВАРИАНТ2:
Организовать рассылку признаков изменений документов в одном напровлении.
Т.е. сделать псевдо-параметризированный post_event: "общий event" || Cast(ID документа as Varchar(15)).
При этом, ib-клиенты будут реагировать только на те сообщения, которые соответствуют открытым документам.
(придется такие сообщения каждый раз регестрировать в TIBEvents при открытии документов на клиенте)
Спасибо за совет! Идея хорошая если еще добавить одну табличку без PK, куда записывать ID документа и информацию о редактирующем и ее коммитить. Тогда решается проблема связанная с извлечением информации о редактирующем.hvlad писал(а): Если таки призадуматься то dirty read есть - в PK\UK\FK, нужно только уметь его готовить
Заводим табличку с одним полем и PK на нём.
Перед началом редактирования док-та вставляем туда запись с PK док-та в отдельной тр-ции, которую не коммитим.
Это всё.
-
MuirsheenDurkin
- Сообщения: 44
- Зарегистрирован: 21 янв 2005, 10:18
Извините за дурацкий вопрос, но может, так, как у меня сделано, нельзя, а мужики-то не знают?
В общем, открывается документ и регистрируется ожидание event'а. Сам event вызывается из триггеров, из триггеров detail вызывается event мастера. Форма, по получении своего event'a зажигает лампочку, что с этим документом не все пока ясно. Когда пользователь закрывает форму редактирования документа с зажженной лампочкой, его спрашивают три варианта:
1. Ходи все конем, я буду последний отец.
2. Все, что я сделал, было неправильно, ничего не сохранять.
3. Будем мёржить. И здесь происходит перечитывание и все самое плохое.
Этот путь чреват граблями?
В общем, открывается документ и регистрируется ожидание event'а. Сам event вызывается из триггеров, из триггеров detail вызывается event мастера. Форма, по получении своего event'a зажигает лампочку, что с этим документом не все пока ясно. Когда пользователь закрывает форму редактирования документа с зажженной лампочкой, его спрашивают три варианта:
1. Ходи все конем, я буду последний отец.
2. Все, что я сделал, было неправильно, ничего не сохранять.
3. Будем мёржить. И здесь происходит перечитывание и все самое плохое.
Этот путь чреват граблями?
Влад, это http://www.ibase.ru/devinfo/pslock.htm вариант 6. Отличаются тем, что там вставка идёт вместе с созданием основной записи и для блокировки в дальнейшем используется апдейт. Преимущество - этот апдейт можно всегда коммитить, а в технологии инсёрта при каждом редактировании придётся роллбачить. Насчёт dirty read - правильно я понимаю, что откаченная версия останется в таблице до уборки и потому использовать её наличие грязным чтением нельзя даже если бы оно было? Из концептуальной дискуссии ухожу - всё уже сказал, бодаться и наставлять нет времени.hvlad писал(а): Заводим табличку с одним полем и PK на нём.
Перед началом редактирования док-та вставляем туда запись с PK док-та в отдельной тр-ции, которую не коммитим.
Дык я и не претендую на новые велосипеды.Merlin писал(а):Влад, это http://www.ibase.ru/devinfo/pslock.htm вариант 6.hvlad писал(а): Заводим табличку с одним полем и PK на нём.
Перед началом редактирования док-та вставляем туда запись с PK док-та в отдельной тр-ции, которую не коммитим.
Я описал предельно простой способ создания custom-блокировок, очень дешёвый
Т.к. в этой отдельной тр-ции не предполагается никаких других действий, то роллбэк уберёт за собой сам с помощью анду-лога. Т.е. мусор возможет только при падениях сервераMerlin писал(а):Насчёт dirty read - правильно я понимаю, что откаченная версия останется в таблице до уборки и потому использовать её наличие грязным чтением нельзя даже если бы оно было?
Ты слишком строг к людЯм в последнее времяMerlin писал(а):Из концептуальной дискуссии ухожу - всё уже сказал, бодаться и наставлять нет времени.
imhoНе в данном конкретном случае. Вопрошающий адекватен, ищет своё решение. Концептуально я сказал всё что мог, поднимать историю с ответами на все вопросы почему оно так и как оно выстрадано, с детальной критикой уже предложенного и ещё не высказанного, но ожидаемого...hvlad писал(а):Ты слишком строг к людЯм в последнее время
Ну и потом, мож чего и придумает новенького, мож вы там уже в кишках чего-то придумали такого, о чём я не в курсе. А вообще-то, да, есть такое дело, строг, особенно к ламерам. Зае...мелся по всем фронтам. И по работе и дома и в плане здоровья. И времени действительно хватает только на похихикать в порядке перекура да изречь квинтэссенцию опыта, умному поможет, а разжёвывать и спорить... В сердце немного света
Лампочка в тридцать ватт
Перегорит и эта
За новой спускаться в ад... (С)
-
freemanzav
- Сообщения: 14
- Зарегистрирован: 01 ноя 2005, 14:32
А можно поподробнее, чем поможет поле COMPUTED BY (CURRENT_CONNECTION) в рамках заданного выше вопроса?freemanzav писал(а):Для классика проблему с обрывом коннекта можно решить в легкую.
Делаем доп. таблицу, в ней вычисляемое поле, показывающее жив ли этот коннект, ну и триггер. Вроде все.
Или я не так понял, что имелось ввиду под "вычисляемое поле, показывающее жив ли этот коннект".
-
freemanzav
- Сообщения: 14
- Зарегистрирован: 01 ноя 2005, 14:32