Первое приложение - служба, создает, открывает, пишет данные в БД (mdf) средствами DAO, второе приложение - консоль управления для этой службы... Возможно ли из консоли (второе приложение) подцепить DBGrid к открытому RecordSet в первом приложении (т.е. службе)? Нужно хотябы направление как это сделать или что-то подобное. Это необходимо, т.к. обновлять рекордсет по уведомлению от службы получается, но не очень корректно, уведомления приходят а в результатах ADOQuery.Requery нет последних записанных данных, т.е. обновление происходит слишком медленно... И еще минус - второму приложению нужен прямой доступ к x.mdf файлу от чего тоже хотелось бы избавиться...

> уведомления приходят а в результатах ADOQuery.Requery нет
> последних записанных данных


Можно подумать, что если ты таки умудришься "по TCP\IP подключиться к RecordSet Другого приложения", то данные от этого станут записываться быстрее)

> то данные от этого станут записываться быстрее)

не записываться, а передаваться клиенту на отображение без задерки, т.е. сначала отобразились а потом записались, это мое предположение и вот почему...
если из второго приложения которое подключено к БД через ADOConnection и выводит данные в DBGrid которые формирует ADOQuery выполнить следующий код:


... то данные в DbGrid отображаются мгновенно, из чего я и предположил что новые данные первом делом поступают в DataSource откуда уже в DbGrid и далее уже пишутся непосредственно в БД на диск что занимает некоторое время.

сохранить рекордсет в xml пакет и передать второму приложению.
в нем загрузить датасет из пакета и показать его в гриде.

Подозревю, что дело всего лишь в незнании и/или непонимании работы механизма транзакций.

> [2] d@vinchi ©   (23.09.09 12:31)
> не записываться, а передаваться клиенту на отображение без задерки
Не боищься, что отображаться начнет то чего нет в базе и возможно не будет никогда?

> если из второго приложения
Возможно, если выполнить все тоже самое, но через второй комплект компонент ADOConnection и ADOQuery и "мгновенность" будет слабее.

>     ADOQuery1.Append;
Если подобными методами работает и пишущий сервис, то я не удивлюсь плохому быстродействию этой пары.
Кстати твои приложения работают на одной машине? Где лежит база и каков запрос в твоем ADOQuery1?

И главное - чего хочется в идеале? Чтоб записи показывались в реальном времени?

> Сергей М. ©   (23.09.09 12:34) [4]
> Подозревю, что дело всего лишь в незнании и/или непонимании
> работы механизма транзакций.

согласен, я затем сюда и обратился, чтобы грамотные люди подсказали или направили на нужный материал...


> Sergey13 ©   (23.09.09 13:01) [5]
>     ADOQuery1.Append;
Если подобными методами работает и пишущий сервис...
я показал чтобы понятно было о чем речь, в службе вообще DAO используется и пишется напрямую через рекордсет.

Приложения тестирую на одной машие, в последствии будут на разных, запрос просто на выборку всего что есть в нужной таблице без всяких условий, использовал такой метод т.к. тут же на форуме кто-то рекомендовал делать именно так потомучто ADOQuery работает быстрее чем ADOTable...

И идеале отображение того что пишется в БД на втором приложении в реальном времени...

> в службе вообще DAO используется


Так а зачем такая солянка сборная ?
Что мешает приложению-монитору работать с базой через тот же DAO ?

> [6] d@vinchi ©   (23.09.09 13:21)
> И идеале отображение того что пишется в БД на втором приложении в реальном времени...

А примерные объемы записываемого можно узнать?

> запрос просто на выборку всего что есть в нужной таблице без всяких условий
И сколько в ней нужного?

спросто в службе вообще не использую VCL компоненты и в случае с службой DAO "компактнее", в приложении-мониторе VLC компонеты, т.к. это обычное приложение и компактность тут не так важна на мой взгляд...

а почему солянка, какая разница каким образом происходит взаимодействие с БД или есть разница?

Вообще складывается впечатление что DAO работает медтенне т.к. происходит гораздо больше вызовов чем у ADO...

> d@vinchi ©   (23.09.09 14:00) [9]


А чем обоснован выбор именно MDF-формат в кач-ве контейнерного формата ?

> Sergey13 ©   (23.09.09 13:56) [8]

О примерных объемах тяжело сказать - все зависит от количества клиентов работающих со службой и генерирующих события для лога и от интенсивности работы этих клиентов, поэтому от 10-50 сторк в час до 100-500 от одного клиента...


> И сколько в ней нужного?

при начале мониторнга нужно все начиная с того как мониторинг начался, далее критерии нужного могут измениться...

Отвечая на вопрос об объемах записываемого и думая об отображении в реальном времени представил как будет отображаться даже 100 сток в минуту (10 клиентов)...

добавлю к 11, т.е. догадываюсь к чему спрашивал Sergey13 об объемах отображаемого в реальном времени - большие обемы будут неинформативны, тут наверное имеет смысл таймер, а не уведомления...


> А чем обоснован выбор именно MDF-формат в кач-ве контейнерного
> формата ?

удобный формат - все таблицы, индексы, обекты и т.д. все в одном файле...

> d@vinchi ©   (23.09.09 14:23) [12]


Понятно.
Я-то подумал, то это безусловное требование Заказчика)
Ну, положим, аналогичными "удобствами" обладаеет далеко не одна СУБД.

В моем случае самым идеальным и правильным использовать на стороне приложения монитора RDSConnection1 -> TADODataSet -> TDataSource -> TDbGrid, а на стороне службы реализовывать COM объект для предоставления доступа RDSConnection к локальному рекордсету...

> [12] d@vinchi ©   (23.09.09 14:23)
> тут наверное имеет смысл таймер, а не уведомления...

Раз эти данные смотрит человек, то имеет смысл кнопка "Обновить". Таймер это тоже знаете ли....

> [11] d@vinchi ©   (23.09.09 14:18)
> все зависит от количества клиентов

Так клиентов еще и не один! Тогда имеет смысл выбрать все таки серверную СУБД. Есть масса неплохих и при этом даже бесплатных.

> Тогда имеет смысл выбрать все таки серверную СУБД

не очень хочется обязывать конечного пользователя иметь серверную СУБД для ведения логов моей проги, к томуже ведение логов опционально и тебуется только на этапе первоначальной настройки проги или при возникновении проблем, с другой стороны при использовании MDF на компе обязательно должен быть установлен MS Access или я ошибаюсь?

Есть ли возможность выполнить обновление ADOQuery таким образом, чтобы в него вошли только новые данные с момента последнего запроса при условии что критерии запроса не менялись?

ну пусть лог.
пусть даже в бд.
почему из этого следует, что смотреть эти логи надо обязательно в гриде?

> [16] d@vinchi ©   (23.09.09 16:19)
> не очень хочется обязывать конечного пользователя иметь
> серверную СУБД для ведения логов моей проги

Не надо думать, что серверная СУБД это здоровый шкаф с лампочками. Например firebird - это просто запущеный сервис на любой (практически) машине.

ставить сервер или просто использовать мдб для логов, тем более временных, для периода отладки и внедрения - это круто.

еще и программу написать для их чтения.

воистину дурная голова рукам покоя не дает.
текстовый лог - чего еще больше то?

> Медвежонок Пятачок ©   (23.09.09 16:33) [19]
> ставить сервер или просто использовать мдб для логов, тем
> более временных, для периода отладки и внедрения - это круто.
>

не только для логов, в этой БД еще куча других таблиц, которые хранят совсем другие данные...

> еще и программу написать для их чтения.

программа не только читает логи, просмотр логов это одна из многочисленных ее функций...

> воистину дурная голова рукам покоя не дает.

не стоит так говорить когда не знаешь всей сути, ты же даже о 99% не в курсе о чем речь...

> текстовый лог - чего еще больше то?

не просто тестовый, для нормальной отладки надо в реальном времени видеть какие события происходит после выполнения человеком конкретных действий над аппаратным обеспечением, просто просмотреть лов в текстовом виде не даст никакой информации...

to [ALL]
всем спасибо, решение в итоге нашел благодаря изложенным тут мыслям!
еще раз всем спасибо!

не стоит так говорить когда не знаешь всей сути, ты же даже о 99% не в курсе о чем речь...

Здесь обсуждается конкретный вопрос, а не то, что там у тебя за кадром подразумевается.

не просто тестовый, для нормальной отладки надо в реальном времени видеть какие события происходит после выполнения человеком конкретных действий над аппаратным обеспечением, просто просмотреть лов в текстовом виде не даст никакой информации...

Я текстовые логи вижу в онлайне в реальном режиме времени с прокруткой окна. (F3 в фаре) - и чего?

> всем спасибо, решение в итоге нашел благодаря изложенным тут мыслям!
наверняка кривое такое же как действия после другого совета с форума ->

> т.к. тут же на форуме кто-то рекомендовал делать именно так
скорее всего рекомендация была несколько иная...
> потомучто ADOQuery работает быстрее чем ADOTable...
ничего подобного, работают они ОДИНАКОВО быстро, просто ADOTable идеологически НЕВЕРНО и потому медленно (много лишних действий/данных делается/перемещается)... вот,  но если туже идеологию использовать у других компонентов (как ты похоже и сделал судя по обрывку кода) то получится ТОЖЕ САМОЕ.