Помогите чайнику !!!
От: Liss  
Дата: 31.07.01 07:02
Оценка:
Помогите чайнику !!! :)
Есть задача реализовать сетевое взаимодействие между сервером и клиентами
расположенными в нескольких сотнях киллометрах с помощью выделенных линий
посредством DCOM.
Сервер должен подключаться к Акцесовской базе с которой должен возвращать
рекордсеты клиентам и делать обновление данных акцессовской таблицы от
клиентов. Возникают вопросы:
1. Каким образом лучше подключаться к базе данных акцесса через ADO,
OLEDB, или через ODBC???
2. Какой тип (dll, exe) и потоковую модель выбрать для сервера???
3. Стоит ли делать в одном интерфейсе подключение к базе данных (если в
будующем светит менять источник данных на SQL) а в других реализацию получения
и обновления данных??
4. Каким образом лучше передавать клиентам рекордсеты (коллекциями, (указателями на массивы)
массивами или просто стройкой)??
5. Стоит ли делать дуальные интерфейсы вместо пользовательских??

Мож будут какие нибудь соображения??
Re: Помогите чайнику !!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.07.01 22:07
Оценка:
Здравствуйте Liss, вы писали:

L>Помогите чайнику !!! :)

L>Есть задача реализовать сетевое взаимодействие между сервером и клиентами
L>расположенными в нескольких сотнях киллометрах с помощью выделенных линий
L>посредством DCOM.
L>Сервер должен подключаться к Акцесовской базе с которой должен возвращать
L>рекордсеты клиентам и делать обновление данных акцессовской таблицы от
L>клиентов. Возникают вопросы:
L>1. Каким образом лучше подключаться к базе данных акцесса через ADO,
L>OLEDB, или через ODBC???

Однозначно ADO или через http://www.optim.ru/cs/1999/4/ASCDB/ascdb3.asp, но
это гдето через недельку (когда мы выложим тестовую версию).

L>2. Какой тип (dll, exe) и потоковую модель выбрать для сервера???


dll + COM+

потоковую модель? Если хочеш меньше гемороя, однозначно appartment.

L>3. Стоит ли делать в одном интерфейсе подключение к базе данных (если в

L>будующем светит менять источник данных на SQL) а в других реализацию получения
L>и обновления данных??

Как это? Может не интерфейсе, а объекте? Тогда, пофигу (если сделаеш как я сказал в п. 1)

L>4. Каким образом лучше передавать клиентам рекордсеты (коллекциями, (указателями на массивы)

L>массивами или просто стройкой)??

ADO — disconnected recordset (и рукопашная запись)
ascDB — напрямую с поддержкой автоматической записи.

L>5. Стоит ли делать дуальные интерфейсы вместо пользовательских??


пользовательских — звучит Ооочень криво. :(

В лчбом случае дуальные лучше.

L>Мож будут какие нибудь соображения??


Ну-ууу..., может станеш нашим первым открытым бета тестером?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Помогите чайнику !!!
От: Liss  
Дата: 01.08.01 06:23
Оценка:
Здравствуйте VladD2, вы писали:

VD>Здравствуйте Liss, вы писали:


L>>Помогите чайнику !!! :)

L>>Есть задача реализовать сетевое взаимодействие между сервером и клиентами
L>>расположенными в нескольких сотнях киллометрах с помощью выделенных линий
L>>посредством DCOM.
L>>Сервер должен подключаться к Акцесовской базе с которой должен возвращать
L>>рекордсеты клиентам и делать обновление данных акцессовской таблицы от
L>>клиентов. Возникают вопросы:
L>>1. Каким образом лучше подключаться к базе данных акцесса через ADO,
L>>OLEDB, или через ODBC???

VD>Однозначно ADO или через http://www.optim.ru/cs/1999/4/ASCDB/ascdb3.asp, но

VD>это гдето через недельку (когда мы выложим тестовую версию).

L>>2. Какой тип (dll, exe) и потоковую модель выбрать для сервера???


VD>dll + COM+


А почему именно СОМ+?? В чем состоит его преимущество перед DCOM??

VD>потоковую модель? Если хочеш меньше гемороя, однозначно appartment.


L>>3. Стоит ли делать в одном интерфейсе подключение к базе данных (если в

L>>будующем светит менять источник данных на SQL) а в других реализацию получения
L>>и обновления данных??

VD>Как это? Может не интерфейсе, а объекте? Тогда, пофигу (если сделаеш как я сказал в п. 1)


L>>4. Каким образом лучше передавать клиентам рекордсеты (коллекциями, (указателями на массивы)

L>>массивами или просто стройкой)??

VD>ADO — disconnected recordset (и рукопашная запись)

VD>ascDB — напрямую с поддержкой автоматической записи.

L>>5. Стоит ли делать дуальные интерфейсы вместо пользовательских??


VD>пользовательских — звучит Ооочень криво. :(


VD>В лчбом случае дуальные лучше.


L>>Мож будут какие нибудь соображения??


VD>Ну-ууу..., может станеш нашим первым открытым бета тестером?

Ну при соответствующей документации к ascDB можно попробовать :)
Re[3]: Помогите чайнику !!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.08.01 15:36
Оценка:
Здравствуйте Liss, вы писали:

L>А почему именно СОМ+?? В чем состоит его преимущество перед DCOM??


Да, просто СОМ+ — это следующая ветсия DCOM (образно говоря). СОМ+ основан на DCOM, но дает много дополнительных сервисов и средств администрирования. Поднобенй можно прочесть на этом сайте в разделе COM/DCOM/COM+ или у меня (http://www.optim.ru/cs/Topics/TopicCom.asp).

Лично я, после появления COM+-а читсый DCOM забросил.

VD>>Ну-ууу..., может станеш нашим первым открытым бета тестером?

L>Ну при соответствующей документации к ascDB можно попробовать :)

Документация есть. Правда пока она мене не очень нравится, но есть же мы! Если, что — поможем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Помогите чайнику !!!
От: ZORK Россия www.zorkaltsev.com
Дата: 21.08.01 22:59
Оценка:
Здравствуйте Liss, вы писали:

L>Помогите чайнику !!! :)

L>Есть задача реализовать сетевое взаимодействие между сервером и клиентами
L>расположенными в нескольких сотнях киллометрах с помощью выделенных линий
L>посредством DCOM.
L>Сервер должен подключаться к Акцесовской базе с которой должен возвращать
L>рекордсеты клиентам и делать обновление данных акцессовской таблицы от
L>клиентов. Возникают вопросы:
L>1. Каким образом лучше подключаться к базе данных акцесса через ADO,
L>OLEDB, или через ODBC???
L>2. Какой тип (dll, exe) и потоковую модель выбрать для сервера???
L>3. Стоит ли делать в одном интерфейсе подключение к базе данных (если в
L>будующем светит менять источник данных на SQL) а в других реализацию получения
L>и обновления данных??
L>4. Каким образом лучше передавать клиентам рекордсеты (коллекциями, (указателями на массивы)
L>массивами или просто стройкой)??
L>5. Стоит ли делать дуальные интерфейсы вместо пользовательских??

L>Мож будут какие нибудь соображения??



1. RDS — одназначно :) Это сделанно специально для такого типа задач. RDS — это будет клиент, который может цепляться к ODBC, через разные транспортные протоколы.

2. Так надо к серверу или к БД подключиться. Если просто к БД — то свой сервер вроде как писать не надо. Иначе только COM+, ну а еще лучше на Java и EJB, но к теме этого форму это не относится.

3. RDS — и SQL унифицирует, и данные выдаст в виде локальный recordset'ов ...и еще обеспечит оптимальное использование сети, с кэшированием данных на клиентской стороне

4. Recordset'ы — зачем что-то еще

5. Не стоит — каждый вызов к удаленному интерфейсу, это как миниму два пакета посланных в обе стороны, то есть задержка между клиентом и сервером, умноженная на два. Для Интерент соединения DCOM очень плохой выбор — если уж хочется попрограммироват, то лучше все сокетах. Ну если взять RDS, то похоже в этой задаче этого не потребются.

6. Для оптимизации интеренет трафика, возможно будет полезно создать бизнес объекты, на стороне сервера — для этого надо использьвать COM+
Думать надо ...головой :)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.