| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как по TCP\IP подключиться к RecordSet Другого приложения?
d@vinchi © (2009-09-22 13:59:00)Первое приложение - служба, создает, открывает, пишет данные в БД (mdf) средствами DAO, второе приложение - консоль управления для этой службы... Возможно ли из консоли (второе приложение) подцепить DBGrid к открытому RecordSet в первом приложении (т.е. службе)? Нужно хотябы направление как это сделать или что-то подобное. Это необходимо, т.к. обновлять рекордсет по уведомлению от службы получается, но не очень корректно, уведомления приходят а в результатах ADOQuery.Requery нет последних записанных данных, т.е. обновление происходит слишком медленно... И еще минус - второму приложению нужен прямой доступ к x.mdf файлу от чего тоже хотелось бы избавиться...
sniknik (2009-09-24 10:42:00) [1]> всем спасибо, решение в итоге нашел благодаря изложенным тут мыслям!
наверняка кривое такое же как действия после другого совета с форума ->
> т.к. тут же на форуме кто-то рекомендовал делать именно так
скорее всего рекомендация была несколько иная...
> потомучто ADOQuery работает быстрее чем ADOTable...
ничего подобного, работают они ОДИНАКОВО быстро, просто ADOTable идеологически НЕВЕРНО и потому медленно (много лишних действий/данных делается/перемещается)... вот, но если туже идеологию использовать у других компонентов (как ты похоже и сделал судя по обрывку кода) то получится ТОЖЕ САМОЕ.
Медвежонок Пятачок (2009-09-24 10:24:00) [2]не стоит так говорить когда не знаешь всей сути, ты же даже о 99% не в курсе о чем речь...
Здесь обсуждается конкретный вопрос, а не то, что там у тебя за кадром подразумевается.
не просто тестовый, для нормальной отладки надо в реальном времени видеть какие события происходит после выполнения человеком конкретных действий над аппаратным обеспечением, просто просмотреть лов в текстовом виде не даст никакой информации...
Я текстовые логи вижу в онлайне в реальном режиме времени с прокруткой окна. (F3 в фаре) - и чего?
d@vinchi (2009-09-24 09:56:00) [3]
> Медвежонок Пятачок © (23.09.09 16:33) [19]
> ставить сервер или просто использовать мдб для логов, тем
> более временных, для периода отладки и внедрения - это круто.
>
не только для логов, в этой БД еще куча других таблиц, которые хранят совсем другие данные...
> еще и программу написать для их чтения.
программа не только читает логи, просмотр логов это одна из многочисленных ее функций...
> воистину дурная голова рукам покоя не дает.
не стоит так говорить когда не знаешь всей сути, ты же даже о 99% не в курсе о чем речь...
> текстовый лог - чего еще больше то?
не просто тестовый, для нормальной отладки надо в реальном времени видеть какие события происходит после выполнения человеком конкретных действий над аппаратным обеспечением, просто просмотреть лов в текстовом виде не даст никакой информации...
to [ALL]
всем спасибо, решение в итоге нашел благодаря изложенным тут мыслям!
еще раз всем спасибо!
Медвежонок Пятачок (2009-09-23 16:33:00) [4]ставить сервер или просто использовать мдб для логов, тем более временных, для периода отладки и внедрения - это круто.
еще и программу написать для их чтения.
воистину дурная голова рукам покоя не дает.
текстовый лог - чего еще больше то?
Sergey13 (2009-09-23 16:28:00) [5]> [16] d@vinchi © (23.09.09 16:19)
> не очень хочется обязывать конечного пользователя иметь
> серверную СУБД для ведения логов моей проги
Не надо думать, что серверная СУБД это здоровый шкаф с лампочками. Например firebird - это просто запущеный сервис на любой (практически) машине.
Медвежонок Пятачок (2009-09-23 16:25:00) [6]ну пусть лог.
пусть даже в бд.
почему из этого следует, что смотреть эти логи надо обязательно в гриде?
d@vinchi (2009-09-23 16:19:00) [7]
> Тогда имеет смысл выбрать все таки серверную СУБД
не очень хочется обязывать конечного пользователя иметь серверную СУБД для ведения логов моей проги, к томуже ведение логов опционально и тебуется только на этапе первоначальной настройки проги или при возникновении проблем, с другой стороны при использовании MDF на компе обязательно должен быть установлен MS Access или я ошибаюсь?
Есть ли возможность выполнить обновление ADOQuery таким образом, чтобы в него вошли только новые данные с момента последнего запроса при условии что критерии запроса не менялись?
Sergey13 (2009-09-23 16:05:00) [8]> [12] d@vinchi © (23.09.09 14:23)
> тут наверное имеет смысл таймер, а не уведомления...
Раз эти данные смотрит человек, то имеет смысл кнопка "Обновить". Таймер это тоже знаете ли....
> [11] d@vinchi © (23.09.09 14:18)
> все зависит от количества клиентов
Так клиентов еще и не один! Тогда имеет смысл выбрать все таки серверную СУБД. Есть масса неплохих и при этом даже бесплатных.
d@vinchi (2009-09-23 15:02:00) [9]В моем случае самым идеальным и правильным использовать на стороне приложения монитора RDSConnection1 -> TADODataSet -> TDataSource -> TDbGrid, а на стороне службы реализовывать COM объект для предоставления доступа RDSConnection к локальному рекордсету...
Сергей М. (2009-09-23 14:31:00) [10]
> d@vinchi © (23.09.09 14:23) [12]
Понятно.
Я-то подумал, то это безусловное требование Заказчика)
Ну, положим, аналогичными "удобствами" обладаеет далеко не одна СУБД.
d@vinchi (2009-09-23 14:23:00) [11]добавлю к 11, т.е. догадываюсь к чему спрашивал Sergey13 об объемах отображаемого в реальном времени - большие обемы будут неинформативны, тут наверное имеет смысл таймер, а не уведомления...
> А чем обоснован выбор именно MDF-формат в кач-ве контейнерного
> формата ?
удобный формат - все таблицы, индексы, обекты и т.д. все в одном файле...
d@vinchi (2009-09-23 14:18:00) [12]
> Sergey13 © (23.09.09 13:56) [8]
О примерных объемах тяжело сказать - все зависит от количества клиентов работающих со службой и генерирующих события для лога и от интенсивности работы этих клиентов, поэтому от 10-50 сторк в час до 100-500 от одного клиента...
> И сколько в ней нужного?
при начале мониторнга нужно все начиная с того как мониторинг начался, далее критерии нужного могут измениться...
Отвечая на вопрос об объемах записываемого и думая об отображении в реальном времени представил как будет отображаться даже 100 сток в минуту (10 клиентов)...
Сергей М. (2009-09-23 14:15:00) [13]
> d@vinchi © (23.09.09 14:00) [9]
А чем обоснован выбор именно MDF-формат в кач-ве контейнерного формата ?
d@vinchi (2009-09-23 14:00:00) [14]спросто в службе вообще не использую VCL компоненты и в случае с службой DAO "компактнее", в приложении-мониторе VLC компонеты, т.к. это обычное приложение и компактность тут не так важна на мой взгляд...
а почему солянка, какая разница каким образом происходит взаимодействие с БД или есть разница?
Вообще складывается впечатление что DAO работает медтенне т.к. происходит гораздо больше вызовов чем у ADO...
Sergey13 (2009-09-23 13:56:00) [15]> [6] d@vinchi © (23.09.09 13:21)
> И идеале отображение того что пишется в БД на втором приложении в реальном времени...
А примерные объемы записываемого можно узнать?
> запрос просто на выборку всего что есть в нужной таблице без всяких условий
И сколько в ней нужного?
Сергей М. (2009-09-23 13:48:00) [16]
> в службе вообще DAO используется
Так а зачем такая солянка сборная ?
Что мешает приложению-монитору работать с базой через тот же DAO ?
d@vinchi (2009-09-23 13:21:00) [17]
> Сергей М. © (23.09.09 12:34) [4]
> Подозревю, что дело всего лишь в незнании и/или непонимании
> работы механизма транзакций.
согласен, я затем сюда и обратился, чтобы грамотные люди подсказали или направили на нужный материал...
> Sergey13 © (23.09.09 13:01) [5]
> ADOQuery1.Append;
Если подобными методами работает и пишущий сервис...
я показал чтобы понятно было о чем речь, в службе вообще DAO используется и пишется напрямую через рекордсет.
Приложения тестирую на одной машие, в последствии будут на разных, запрос просто на выборку всего что есть в нужной таблице без всяких условий, использовал такой метод т.к. тут же на форуме кто-то рекомендовал делать именно так потомучто ADOQuery работает быстрее чем ADOTable...
И идеале отображение того что пишется в БД на втором приложении в реальном времени...
Sergey13 (2009-09-23 13:01:00) [18]> [2] d@vinchi © (23.09.09 12:31)
> не записываться, а передаваться клиенту на отображение без задерки
Не боищься, что отображаться начнет то чего нет в базе и возможно не будет никогда?
> если из второго приложения
Возможно, если выполнить все тоже самое, но через второй комплект компонент ADOConnection и ADOQuery и "мгновенность" будет слабее.
> ADOQuery1.Append;
Если подобными методами работает и пишущий сервис, то я не удивлюсь плохому быстродействию этой пары.
Кстати твои приложения работают на одной машине? Где лежит база и каков запрос в твоем ADOQuery1?
И главное - чего хочется в идеале? Чтоб записи показывались в реальном времени?
Сергей М. (2009-09-23 12:34:00) [19]Подозревю, что дело всего лишь в незнании и/или непонимании работы механизма транзакций.
Медвежонок Пятачок (2009-09-23 12:34:00) [20]сохранить рекордсет в xml пакет и передать второму приложению.
в нем загрузить датасет из пакета и показать его в гриде.
| |
Страницы: 