xroot
Дата: 14.10.2003 14:04:28
Привет ALL!
Использую C++Builder ADOTable<->ADOConnection<->MSSQL
Запускаю две копии одной програмки и изменяю в одной какую-то запись.
В другой, ничего не видно.
Поделитесь опытом как кто делает, чтобы сразу в других копиях были видны изменения...
Конечно можно делать Refresh по таймеру, но что-то такой вариант мне совсем не нравится. Может можно как-то с помощью настроек компонентов?
С уважением Роман
Sazabis
Дата: 15.10.2003 10:22:56
Обычно это делает клиент-сервер. То что у тебя это назовем клиент, доделываешь сервер. Он будет иметь список приложений прослушивающих таблицу, когда эта таблица будет изменена, он посылает уведомление всем прослушивающим приложениям, о том что данные устарели( ну или сразу запускает их рефреш или т.д. )
Glory
Дата: 15.10.2003 10:24:27
_Обновляют_ данные думаю все таки путем повторного выполнения запроса в явном или неявном виде.
А вот _оповещают_ клиентов о том, что данные нужно обновить каждый по-своему.
Кто-то вообще не оповещает, а оставляет это на усмотрение клиента
Кто-то делает это автоматически через определенный промежуток времени.
Кто-то "мастерит" для удобства еще дополнительные таблицы на сервере с семафорами и перед запросом данных анализирует ее.
Кто-то вешает триггер на таблицу и далее либо отсылка сообщения через стандартные net send или почту либо работа через какую-либо самописную расширенную хранимую процедуру
Berg
Дата: 15.10.2003 10:26:25
Меня тоже интересует эта проблема, вот тебе то, что я нарыл на этом форуме по вопросу оповещения клиентов об обновлении:
1) SQLServerNotificationServices
http://www.sql.ru/articles/mssql/03011001NotificationServices.shtml#5-0
http://www.microsoft.com/rus/msdn/magazine/archive/2002-11/sql_server.asp
2)
Всем заинтересовавшимся системой событий SQL Server могу рассказать следующее.
Её несложно изучить, включив два SQL Profiler, чтобы посмотреть одним что делает другой. Эта прога работает именно на базе этой системы событий.
Мною разработана система клиентов к одной БД, которые автоматически обновляют данные, посредством данной системы, помимо этого данная система ещё используется просто для обмена данными между клиентами в реальном времени. Для автоматического обновления достаточно передавать идентификатор - что обновилось и, например, первичный ключ обновляемой записи. На другом клиенте имея идентификатор можно обновлять не весь запрос, а только одну строку - но это в зависимости от ситуации, тут реализаций может быть множество.
Для использования системы событий изучите ряд хранимых процедур серии sp_trace_xxxxx. В доке к серву они все описаны кроме sp_trace_getdata. Данная функция ждёт, пока не появится событие (причём ресурсы процессора на ожидание не тратятся), после этого она возвращает набор данных, с информацией о событии. Только есть одна особенность, всем этим процедурам нужны права sysadmin на сервер БД для запуска.
Последовательность следующая:
1. Создаётся и конфигурируется trace.
2. Запускается sp_trace_getdata. Причём на запросе надо поставить бесконечный таймоут.
3. Обрабатываем данные, полученные из этой процедуры, генерируем событие и переходим к пункту 2.
Данные операции необходимо запускать в отдельном потоке, т. е. будет отдельный коннект к БД, причём с правами админа.
Что касается посылки сообщения - надо вызвать процедуру sp_trace_generateevent
PS: Если кто-нибудь найдёт описание sp_trace_getdata - буду очень рад.
PS2: Если я правильно понял sp_trace_getdata вызывается следующим образом:
exec sp_trace_getdata @TraceID, @RowCount
-- где @TraceID - идентификатор trace-а, @RowCount - одидаемое число записей для завершения работы и передачи данных на клиент
3) Делается расширенная хранимая процедура, которая с использованием DCOM оповещает всех клиентов о всех шевелениях, происходящих в базе данных. Эту ХП должны вызывать триггеры, прицепленные ко всем таблицам, по которым требуется синхронизация. Клиенты делаются с автономными рекордсетами, в которые информация изначально заливается из отдельного рекордсета, завязанного на источник в БД, после чего связь с источником разрывается. Впоследствии все операции производятся только по одной записи (лучше асинхронно, с использованием многопоточности). По DCOM с сервера получаются сообщения о том, кто что вставил, модифицировал или удалил (только ID-шники таблиц БД и ID-шники записей). Клиент в отдельном потоке генерит скрипты на запрос содержимого тех записей, которые в данный момент у него должны синхронизироваться на экране, остальные пропускает "мимо ушей", и исправляет содержимое автономного рекордсета. Модификации в данном рекордсете должны преобразовываться в SQL-запросы, оперирующие одной записью, которые отправляются на сервер. Нюансов куча, реализация - за минуту не сделаешь. Но в принципе, реализуемо.
4) Для каждой таблицы или для всех таблиц сразу заводится вспомогательная таблица, в которую триггерами на вставку/удаление/обновление из базовых таблиц помещается информация о новых операциях с фиксированием времени этой операции. Смысл вспомогательной таблицы - отображение ИЗМЕНЕНИЙ. То есть, Requery делается не по всей базовой таблице, в которой могут быть миллионы записей, а только по вспомогательной таблице. К самОй вспомогательной таблице цепляется триггер, основная задача которого - очистка вспомогательной таблицы от старых записей. При каждом добавлении новой информации в эту таблицу этот триггер удаляет из нее записи, к примеру, 10-минутной давности. В этой реализации отпадает необходимость мудрить с расширенной ХП и DCOM, но вопрос автономности рекордсета остается актуальным, как и все остальные приплясы вокруг этого, а именно:
а) Первоначальная заливка этого рекордсета через вспомогательный рекордсет, подключенный к первоисточнику
б) Асинхронная синхронизация этого рекордсета с отдельно поступающей информацией об изменениях
в) Рукопашная генерация команд на модификацию источника данных, поскольку автономный рекордсет (не привязанный к источнику) таких команд сам генерить уже не будет.
4) Опрос по таймеру;
5) Шлем из триггера по IP из таблицы;
6) MS Message Queue
http://marbio-www.dvgu.ru/download/PWSSetupFiles/msmqread.htm