Как по TCP IP подключиться к RecordSet Другого приложения?

← →
d@vinchi © (2009-09-22 13:59) [0]

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

← →
Сергей М. © (2009-09-22 14:11) [1]

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

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

← →
d@vinchi © (2009-09-23 12:31) [2]

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

не записываться, а передаваться клиенту на отображение без задерки, т.е. сначала отобразились а потом записались, это мое предположение и вот почему...
если из второго приложения которое подключено к БД через ADOConnection и выводит данные в DBGrid которые формирует ADOQuery выполнить следующий код:
procedure TForm1.Button1Click(Sender: TObject); var I: Integer; begin for I:=0 to 9 do begin ADOQuery1.Append; ADOQuery1.FieldByName("FieldName").AsString:="Test "+IntToStr(I); ADOQuery1.Post; end; end;
... то данные в DbGrid отображаются мгновенно, из чего я и предположил что новые данные первом делом поступают в DataSource откуда уже в DbGrid и далее уже пишутся непосредственно в БД на диск что занимает некоторое время.

← →
Медвежонок Пятачок © (2009-09-23 12:34) [3]

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

← →
Сергей М. © (2009-09-23 12:34) [4]

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

← →
Sergey13 © (2009-09-23 13:01) [5]

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

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

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

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

← →
d@vinchi © (2009-09-23 13:21) [6]

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

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

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

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

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

← →
Сергей М. © (2009-09-23 13:48) [7]

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

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

← →
Sergey13 © (2009-09-23 13:56) [8]

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

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

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

← →
d@vinchi © (2009-09-23 14:00) [9]

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

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

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

← →
Сергей М. © (2009-09-23 14:15) [10]

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

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

← →
d@vinchi © (2009-09-23 14:18) [11]

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

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

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

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

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

← →
d@vinchi © (2009-09-23 14:23) [12]

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

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

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

← →
Сергей М. © (2009-09-23 14:31) [13]

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

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

← →
d@vinchi © (2009-09-23 15:02) [14]

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

← →
Sergey13 © (2009-09-23 16:05) [15]

> [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 идеологически НЕВЕРНО и потому медленно (много лишних действий/данных делается/перемещается)... вот, но если туже идеологию использовать у других компонентов (как ты похоже и сделал судя по обрывку кода) то получится ТОЖЕ САМОЕ.

Как по TCP IP подключиться к RecordSet Другого приложения? Найти похожие ветки