> Есть COM-сервер, который загружает таблицы данных через > Internet. Он предоставляет доступ к этим таблицам через так > называемые «sfx-объекты».С помощью этих sfx-объектов можно > читать из таблиц по одной строке. Способ чтения такой: > сначала задаются ключевые поля, потом вызывается метод > Load, который читает данные из таблицы. Данные в таблицах > обновляются несколько раз в секунду. > > Мне нужно в своём приложении получать доступ к этим > таблицам. Для простоты работы с COM пишу программу на > Delphi. Хотелось бы, чтобы эти таблицы можно было легко > подключать через «DataSource» компонента TDBGrid. Можно попробовать различные таблицы в оперативной памяти если база не большая, например TMemTable из TEhDBGrid компонентов или поискать какой либо аналог.
Com компонент уведомляет какие данные надо прочитать или надо каждый раз читать все данные по ключевым полям и проверять что изменилось или меняются данные сразу всей таблицы
> > Свои идеи по этому поводу такие: > 1. Создать в Access аналогичные таблицы. > 2. Заполнить их ключевые поля > 3. Построчно считывать с COM-сервера таблицы и сохранить их считывать каждый раз всю базу по несколько раз в секунду это как то
кхм не производительно
> в БД Access каждый раз, когда они обновляются. > 4. Подключить БД Access к TDBGrd. > > Смущает то, что это может привести к высоким накладным > расходами, и нужно будет синхронизацию данных производить если все данные меняются несколько раз в секунду, то по любому
от высоких накладных расходов никуда не деться
> (чтобы не получилось, что клиент прочитает пол таблицы > старые, а пол новые). я не пойму, таблица обновляется полностью или только некоторые записи
> > Может быть, кто-нибудь сталкивался с подобной задачей? > Подскажите лучший вариант.
Есть COM-сервер, который загружает таблицы данных через Internet. Он предоставляет доступ к этим таблицам через так называемые «sfx-объекты».С помощью этих sfx-объектов можно читать из таблиц по одной строке. Способ чтения такой: сначала задаются ключевые поля, потом вызывается метод Load, который читает данные из таблицы. Данные в таблицах обновляются несколько раз в секунду.
Мне нужно в своём приложении получать доступ к этим таблицам. Для простоты работы с COM пишу программу на Delphi. Хотелось бы, чтобы эти таблицы можно было легко подключать через «DataSource» компонента TDBGrid.
Свои идеи по этому поводу такие:
1. Создать в Access аналогичные таблицы.
2. Заполнить их ключевые поля
3. Построчно считывать с COM-сервера таблицы и сохранить их в БД Access каждый раз, когда они обновляются.
4. Подключить БД Access к TDBGrd.
Смущает то, что это может привести к высоким накладным расходами, и нужно будет синхронизацию данных производить (чтобы не получилось, что клиент прочитает пол таблицы старые, а пол новые).
Может быть, кто-нибудь сталкивался с подобной задачей? Подскажите лучший вариант.
В общем задачу решил. Храню данные в...31.05.08 14:15 Автор: Vedrus <Serokhvostov Anton> Статус: Member
> Есть COM-сервер, который загружает таблицы данных через > Internet. Он предоставляет доступ к этим таблицам через так > называемые «sfx-объекты».С помощью этих sfx-объектов можно > читать из таблиц по одной строке. Способ чтения такой: > сначала задаются ключевые поля, потом вызывается метод > Load, который читает данные из таблицы. Данные в таблицах > обновляются несколько раз в секунду. > > Мне нужно в своём приложении получать доступ к этим > таблицам. Для простоты работы с COM пишу программу на > Delphi. Хотелось бы, чтобы эти таблицы можно было легко > подключать через «DataSource» компонента TDBGrid. Можно попробовать различные таблицы в оперативной памяти если база не большая, например TMemTable из TEhDBGrid компонентов или поискать какой либо аналог.
Com компонент уведомляет какие данные надо прочитать или надо каждый раз читать все данные по ключевым полям и проверять что изменилось или меняются данные сразу всей таблицы
> > Свои идеи по этому поводу такие: > 1. Создать в Access аналогичные таблицы. > 2. Заполнить их ключевые поля > 3. Построчно считывать с COM-сервера таблицы и сохранить их считывать каждый раз всю базу по несколько раз в секунду это как то
кхм не производительно
> в БД Access каждый раз, когда они обновляются. > 4. Подключить БД Access к TDBGrd. > > Смущает то, что это может привести к высоким накладным > расходами, и нужно будет синхронизацию данных производить если все данные меняются несколько раз в секунду, то по любому
от высоких накладных расходов никуда не деться
> (чтобы не получилось, что клиент прочитает пол таблицы > старые, а пол новые). я не пойму, таблица обновляется полностью или только некоторые записи
> > Может быть, кто-нибудь сталкивался с подобной задачей? > Подскажите лучший вариант.
а что в памяти держать эти данные проблема что ли?28.05.08 01:05 Автор: + <Mikhail> Статус: Elderman
> Есть COM-сервер, который загружает таблицы данных через > Internet. Он предоставляет доступ к этим таблицам через так > называемые «sfx-объекты».С помощью этих sfx-объектов можно
а что в памяти держать эти данные проблема что ли?
Я так понял у тебя есть доступ к данным через СОМ интерфейс, вот и читай их и храни в памяти
> читать из таблиц по одной строке. Способ чтения такой: > сначала задаются ключевые поля, потом вызывается метод > Load, который читает данные из таблицы. Данные в таблицах > обновляются несколько раз в секунду. > > Мне нужно в своём приложении получать доступ к этим > таблицам. Для простоты работы с COM пишу программу на > Delphi. Хотелось бы, чтобы эти таблицы можно было легко > подключать через «DataSource» компонента TDBGrid. > > Свои идеи по этому поводу такие: > 1. Создать в Access аналогичные таблицы. > 2. Заполнить их ключевые поля > 3. Построчно считывать с COM-сервера таблицы и сохранить их > в БД Access каждый раз, когда они обновляются. > 4. Подключить БД Access к TDBGrd. > > Смущает то, что это может привести к высоким накладным > расходами, и нужно будет синхронизацию данных производить > (чтобы не получилось, что клиент прочитает пол таблицы > старые, а пол новые). > > Может быть, кто-нибудь сталкивался с подобной задачей? > Подскажите лучший вариант.
Часто схожие B2B/ETL задачи решают так:24.05.08 20:11 Автор: void <Grebnev Valery> Статус: Elderman
Часто схожие B2B/ETL задачи решают так:
1) создают приложения, которые переодически или "реал-тайм" (постоянно слушают удалённый источник данных) обновляют свои структуры даных. Пусть это "DOWNLOADER" (в вашем случае - часть кода в составе вашего COM)
2) в составе "DOWNLOADER" или отдельно от него создают ETL модуль ("ETL parser"), который преодразует данные в удобном виде и записывает эти данные в DBMS (в вашем случае это что нибудь free - *.mdb или MySQL, или MSSQL2005 Express, ....)
Синхронизация "DOWNLOADER" и "ETL parser" - особенно простая, если "ETL parser" есть часть "DOWNLOADER". Самое простое в этом случае - "ETL parser" обрабатывает сообщения DOWNLOADER-а синхронно, или асинхронно, выбирая их из очереди. Если "DOWNLOADER" и "ETL parser" в разных процессах - можно использовать именованые event/mutex для синхронизации. Для организации IPC в этом случае - COM самое простое решение. Можно и shared memory/pipe/socket, что гораздо более многодельно.
Таким образом вы сможете обрабатывать следующую цепочку: [Internet soure]->[DOWNLOADER]->[ETL parser]->DBMS.
3) Как вы и хотели, на Delphi пишите клиента своего BackOffice, "CLIENT".
Для синхронизации "CLIENT" можно сделать одно из следующего:
3.1) "CLIENT" "висит" на именованном объекте ядра. Когда "ETL parser" закончил очередное обновление - он "поджигает" event\mutex.
3.2) "ETL parser" снабжает свои данные timestamp и записывает их в DBMS. В этом случае, "CLIENT" может периодически (если это допустимо в бизнес логике) читать последние обновления, сравнивая timestamp.
Как-то так.
Люди, спасибо за внимание. Но в ваших постах много...25.05.08 05:25 Автор: Vedrus <Serokhvostov Anton> Статус: Member
Люди, спасибо за внимание. Но в ваших постах много технологий, которые не знакомы для меня. Для данной задачи я не готов тратить дополнительное время на изучение дополнительных технологий.
Мне не нужно вести БД в своей программе. Access я хотел использовать для временного хранения данных. Сейчас решил остановиться на динамической генерации таблиц, с целью подключить ей к полю DataSource в DBGrid’е. Буду благодарен, за советы в этой области.
Ustin, void, ещё раз спасибо за развёрнутые ответы.
Сужаю вопрос24.05.08 10:53 Автор: Vedrus <Serokhvostov Anton> Статус: Member
Можно ли как-нибудь «вручную» не через ADO, DAO, ODBC и др. создать таблицу? Т.е. не к существующей таблице подключиться, а динамически её создать, и в компонент TDataSource эту таблицу засунуть.
> Сужаю вопрос > > Можно ли как-нибудь «вручную» не через ADO, DAO, ODBC и др. > создать таблицу? Т.е. не к существующей таблице > подключиться, а динамически её создать, и в компонент > TDataSource эту таблицу засунуть.
Давно этим занимался... но посмотрел бы TJvMemoryDataset с jvcl.sourceforge.net
Или из стандартных компонентов TClientDataset
Сужаю вопрос26.05.08 15:56 Автор: Vedrus <Serokhvostov Anton> Статус: Member
А разве TClientDataset может работать без внешней таблицы?
У него ведь есть поле MasterFields, к которому внешняя таблица подключается, или оно не обязательное?
Сейчас в качестве временного решения использую массивы, структуры и TStringGrid. Криво, но работает. Продолжаю искать оптимальное для себя решение.
> А разве TClientDataset может работать без внешней таблицы? > У него ведь есть поле MasterFields, к которому внешняя > таблица подключается, или оно не обязательное? > > Сейчас в качестве временного решения использую массивы, > структуры и TStringGrid. Криво, но работает. Продолжаю > искать оптимальное для себя решение.
> Есть COM-сервер, который загружает таблицы данных через > Internet. Он предоставляет доступ к этим таблицам через так > называемые «sfx-объекты».С помощью этих sfx-объектов можно > читать из таблиц по одной строке. Способ чтения такой: > сначала задаются ключевые поля, потом вызывается метод > Load, который читает данные из таблицы. Данные в таблицах > обновляются несколько раз в секунду. Для этого я бы написал отдельный сервис - репликатор, который отслеживает изменения и вливает их в локальную копию БД - 1 на весь офис, а не своя у каждого приложения.
> Свои идеи по этому поводу такие: ...
> Смущает то, что это может привести к высоким накладным > расходами, и нужно будет синхронизацию данных производить > (чтобы не получилось, что клиент прочитает пол таблицы > старые, а пол новые). Access не поддерживает многоверсионность и не является хорошим решением для какого бы то ни было серьёзного проекта, лучше воспользоваться нормальной БД типа FireBird - ничего сложного в установке нет, freeware, работает отлично. К нему для delphi есть интерфейсные компоненты, полностью совместимые с архитектурой TDataSet. И изменением уровня изоляции пользовательской транзакции добиться нужного эффекта.
> Может быть, кто-нибудь сталкивался с подобной задачей? > Подскажите лучший вариант. И ещё: всё-таки, если данных достаточно много, возможно есть смысл поискать способ напрямую переливать данные из ЦБ в свою копию
Спасибо, но как-то всё это сложно выглядит. Хотелось бы проще реализовать. К ЦБ доступ получить возможности нет.24.05.08 10:52 Автор: Vedrus <Serokhvostov Anton> Статус: Member
Если пользователей много и не хочется иметь "грязные данные" (полтаблицы старые, полтаблицы новые) - надо использовать СУБД с поддержкой многоверсионности24.05.08 11:54 Автор: Ustin <Ustin> Статус: Elderman Отредактировано 24.05.08 12:16 Количество правок: 1
Почему FireBird - потому что я сам с этим столкнулся и работаю.
Установка - простая совсем, ставим на выделенный сервер и ходим по сети через native-клиента, что в несколько раз быстрее чем через АДО. Чтобы так ходить на клиенте должна быть одна dll в \system32
Настройка - в зависимости от сложности задачи :) - как правило поставил, сменил пароль sysdba, завёл одного юзера для всех баз и закрыл.
Мэнэджмент - достаточно интуитивен, есть софтина "IBExpert"
Документации - вагон: решается задача по репликации данных из центра в регионы (2 центра - ~100 регионов) - всё быстро, просто, адекватно, причём это первый опыт работы с БД в принципе - реализовано меньше чем за месяц - документировано всё очень доходчиво, и на русском :) - одно удовольствие
Тут примерно то же самое, как я понял, что происходит в моей задаче на регионе - надо всосать "левые" данные и влить их так, чтобы никто ничего не почувствовал, а при следующем обновлении всё увиделось хорошо
ИМХО есть смысл потратить пару дней на установку\создание баз\написание тестовой софтины чем потом муздыкаться с аксессом если проект вдруг хоть чуть вырастет. Если будут конкретные вопросы (хотя, ещё раз повторюсь, там всё ОЧЕНЬ доходчиво описано) - будем постараться подсказать по мере сил
А по поводу таблицы там - выполняешь последовательно 2 запроса
CREATE TABLE PARAMS (
ID INTEGER NOT NULL,
PARAMNAME VARCHAR(256),
PARAMVALUE VARCHAR(256)
);
ALTER TABLE PARAMS ADD PRIMARY KEY (ID);
А что за база-исходник? com-сервер к ней цепляется - что у него на входе? Возможно проще будет подцепиться к исходной базе через хоть ADO и, регулируя уровень изоляции транзакций, получать адекватные данные на тек момент?
Что получает COM-сервер на входе неизвестно, формат обмена с БД через Интернет тоже неизвестен, так что ADO отпадает.24.05.08 05:19 Автор: Vedrus <Serokhvostov Anton> Статус: Member
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
