Ох щас меня материть будут местные гуру, но все же...
Есть небольшое приложение. Delphi + IBX + Firebird 2.0
в базе 1 таблица, 2 поля ID и NAME
на форме грид и кнопка. по нажатию в таблицу добавляется запись.
Так вот. Запускаю два экземпляра приложения. В одном жму кнопку - запись добавилась. Понятно, что для того чтобы во втором экземпляре изменения появились нужно октрыть НД заново, но как это сделать без участия пользователя? Как отловить событие изменения НД и открыть его заново?
Сразу скажу, что статью здесь я читал....только смысл до меня не дошел. Мне для каждой таблицы создавать триггер и еще дополнительную таблицу для регистрации изменений? Извините, но мне это бредом кажется. А если у меня 1000 рабочих таблиц?
Обновление клиентских наборов данных
Модератор: kdv
рекомендую в несколько попыток поиском найти обсуждения подобных тем здесь и на sql.ru. В общем случае рекомендации сводятся к следующим:
1. представьте, что 20 пользователей тыкают кнопки. сколько раз в секунду у них будет автоматически перерисовываться экран, и зачем?
2. эвенты имеет смысл использовать для редких обновлений. Или когда данные меняются где-то в одном месте, а мониторят их изменения (только!) в другом
3. обычно дешевле для глаз и для сети сделать для пользователя кнопку (или "горячую клавишу") для переоткрытия набора данных. Потому что никаким иным способом кроме перевыполнения запроса обновленные данные увидеть невозможно (еще и нужен уровень изолированности ReadCommitted).
кроме того, обычно при таком переоткрытии запроса текущее положение курсора пользователя, разумеется, "соскакивает". представьте как пользователь будет материть вас, пытаясь встать на запись и отредактировать ее, когда события будут ему перерисовывать грид каждые 5-10 секунд.
1. представьте, что 20 пользователей тыкают кнопки. сколько раз в секунду у них будет автоматически перерисовываться экран, и зачем?
2. эвенты имеет смысл использовать для редких обновлений. Или когда данные меняются где-то в одном месте, а мониторят их изменения (только!) в другом
3. обычно дешевле для глаз и для сети сделать для пользователя кнопку (или "горячую клавишу") для переоткрытия набора данных. Потому что никаким иным способом кроме перевыполнения запроса обновленные данные увидеть невозможно (еще и нужен уровень изолированности ReadCommitted).
кроме того, обычно при таком переоткрытии запроса текущее положение курсора пользователя, разумеется, "соскакивает". представьте как пользователь будет материть вас, пытаясь встать на запись и отредактировать ее, когда события будут ему перерисовывать грид каждые 5-10 секунд.
Ну не совсем так все плохо как вы описали. Пользователей у меня будет 2, ну максимум 3. А вот с таким как быть? Есть справочник. Допустим сотовых телефонов. 1 пользователь добавил туда новую модель, но в другой запущенной копии приложения этой модели нет. Как тогда? тоже вручную переоткрывать набор данных? Боюсь что в ТАКОМ случае меня юзеры убьют, а не за перерисовку грида.
ему это обычно не надо. или область refresh составляет небольшое количество записей.Там что юзер тоже постоянно тычет "Refresh"?
- Маняаааа! Ты новый товар в справочник забила?
- Даааа
- А где он? я уже полчаса листаю, и не вижу его!
собственно, при чем тут автоматический или ручной refresh ?
я собственно не отговариваю - хотите, используйте events.
Кстати. статью Плотникова м.б. Вам еще рано читать. в смысле, Вы events пробовали?
добавлю цитату из первого письма
Вот ЭТО как раз больше похоже на бред. Пользователю нужно будет видеть конкурирующие изменения во всех 1000 таблицах?Извините, но мне это бредом кажется. А если у меня 1000 рабочих таблиц?
Пробовал. Работает вроде. Но такой подход критикуют. Почему? Ну я согласен, что грид будет перерисовываться и указатель возвратится на 1-ю запись, но ведь перед закрытием его можно запомнить и после открытия поставить курсор на ту же запись.я собственно не отговариваю - хотите, используйте events.
Кстати. статью Плотникова м.б. Вам еще рано читать. в смысле, Вы events пробовали?
Может быть. Спорить не осмелюсь.Вот ЭТО как раз больше похоже на бред. Пользователю нужно будет видеть конкурирующие изменения во всех 1000 таблицах?
Спасибо что уделили время моей теме.
Не вижу особой разницы с 20-ю.VitGun писал(а):Ну не совсем так все плохо как вы описали. Пользователей у меня будет 2, ну максимум 3.
Если Васькин нацелился на редактирование записи и уже занёс палец над кнопкой, а в этот момент Петькин уже ткнул - у Васькина произошёл рефреш, но остановить палец он уже не смог - ткнул в другую запись. Внимание вопрос - будет ли Васькин жаловаться на Петькина, или скооперируются и открутят голову тебе?
Когда так говорят, мне всегда представляется эдакая команда гремлинов, в мешочках тащит данные (вручную!) на клиента. Либо юзер с красными глазами, который в екселе пытается JOIN таблиц имитировать. Нажать F5 юзеру ничуть не напряжно, к тому же он контролирует удобное время обновления сам.VitGun писал(а):А вот с таким как быть? Есть справочник. Допустим сотовых телефонов. 1 пользователь добавил туда новую модель, но в другой запущенной копии приложения этой модели нет. Как тогда? тоже вручную переоткрывать набор данных?
Почитай к примеру вот тут, достаточно бурное обсуждение было.
Мы делали на событиях: с десяток пользователей + репликация.
Нормально работало.
Правда фечилось не всё заново, а только изменённые/добавленные/удалённые.
Ну и не напрямую в датасет на грид зацепленный, а в мастер датасет впамять.
В гриде отображались дочерние датасеты, зацепленные на мастер, отфильтрованные и отсортированные.
Использовали EhLib.
P.S. Сейчас придерживаемся подобной же модели, но используем Qt + Python.
Нормально работало.
Правда фечилось не всё заново, а только изменённые/добавленные/удалённые.
Ну и не напрямую в датасет на грид зацепленный, а в мастер датасет впамять.
В гриде отображались дочерние датасеты, зацепленные на мастер, отфильтрованные и отсортированные.
Использовали EhLib.
P.S. Сейчас придерживаемся подобной же модели, но используем Qt + Python.