Тут я когда-то задался следующим вопросом. Привожу текст (чтобы не лезть по ссылке)
___________________________________________________________________
Лирическое отступление:
Со временем базы мдб растут вместе с числом пользователей, и многие операции замедляются до неприемлемого уровня. Решить (снизить остроту) проблему можно разными способами: пересмотр схемы данных, архивация, репликация, переход на клиент-серверную архитектуру, терминальный доступ и т.д. Все они требуют значительных временнЫх или(и) денежных затрат. Где-то читал, что народ умудряется использовать даже MSSQL сервер как прослойку для имитации клиент-серверной технологии в Access (mdb-mssql-mdb).
А теперь по делу:
Решил реализовать такую штуку. На сервере запускается Форма из mdb которая на основе Winsock контрола «слушает» определенный порт и обрабатывает текстовые сообщения (запросы) приходящие через от клиентов. На клиентах юзается тот-же контрол.
В сообщениях клиент, например, может указывать чистый SQL код, или просто команду типа «выполнить процедуру «проц1» с параметрами а1,а2,а3».

Внимание вопросы:
1. Юзал несколько примеров (из инета и MSDN) — во всех у меня зависает Access после того как пытаюсь закрыть соединение (Close) или просто форму. Причем в Access начинает жрать 99% процессорного времени. (Глюк наблюдается для протокола TSP, примеры для UDP вроде не глючат)
2. Кто ковырялся в этом направлении, если смысл в такой идее или оно будет глючить по жизни и сможет ли работать несколько юзеров одновременно (как реализовать)?
И вообще у кого есть полный рабочий код (пример) с этими Winsock controls в Access?
п.с.
DoEvens-ы вставлял через строчку – не помогает.
________________________________________________________
С того момента накачал кучу примеров и на VB и на C++,но многие глючат (особенно VB), либо слишком сложны и перегружены ненужной функциональностью. Я так и не определился с технологией, а опыта нет, да и С++ хромает. Читал тут статью про сокеты, но она для крутых начинающих.
Не подумайте, что я ленивый или тупой, просто время, потраченное на изучение для меня очень дорого, и я хочу начать тратить его в нежном направлении, поэтому прошу оценить моё текущее виденье дел.

1. Писать качественный сервер на VB геморно, ибо проблемы с потоками и скоростью работы.
3. Использовать Winsock control тоже уже не хочу.
2. Писать решил на C++ (не очень удобно работать с базой Access, но попробую)
3. Не решил, как в моем случае правильнее обрабатывать несколько клиентов.
Пока думаю так:
Создаю сокет для "слушанья" клиентов, при "подключении" нового клиента создаю новый поток, который "работает" с этим клиентом.
Потоки принимают запросы от клиентов и записывают их в общую очередь (для корректного разделения общей очереди между потоками предполагаю использовать какие-нибудь критические секции или объекты ядра (почитаю в толстой книжке Виндовс для профессионалов)).
Очередь запросов обрабатывает поток, который читает и исполняет команды из этой очереди через ADO (или DAO) подключение к базе (посмотрю пример в инете).
Об окончании выполнения очередного запроса как-то должен узнать соответствующий поток (пока не думал как), и отправить результат клиенту.

Клиенты будут на MS Access.

Если все выше написанное считаете бредом – так и напишите, а если нет, то укажите на ошибки и дайте рекомендации. Про эти сокеты так дофига написано, что я и не знаю точно в каком «режиме» и какими библиотеками лучше пользоваться в моём случае. Если можно, дайте ссылку на подходящий пример и советы, что в него надо добавить, чтобы разрулить до описанного уровня.

Буду благодарен за любые комментарии.

Здравствуйте, N_A, Вы писали:

N_A>Тут я когда-то задался следующим вопросом. Привожу текст (чтобы не лезть по ссылке)
N_A>___________________________________________________________________
N_A>Лирическое отступление:
N_A>Со временем базы мдб растут вместе с числом пользователей, и многие операции замедляются до неприемлемого уровня. Решить (снизить остроту) проблему можно разными способами: пересмотр схемы данных, архивация, репликация, переход на клиент-серверную архитектуру, терминальный доступ и т.д. Все они требуют значительных временнЫх или(и) денежных затрат. Где-то читал, что народ умудряется использовать даже MSSQL сервер как прослойку для имитации клиент-серверной технологии в Access (mdb-mssql-mdb).
N_A>А теперь по делу:
N_A>Решил реализовать такую штуку. На сервере запускается Форма из mdb которая на основе Winsock контрола «слушает» определенный порт и обрабатывает текстовые сообщения (запросы) приходящие через от клиентов. На клиентах юзается тот-же контрол.
N_A>В сообщениях клиент, например, может указывать чистый SQL код, или просто команду типа «выполнить процедуру «проц1» с параметрами а1,а2,а3».

N_A>Внимание вопросы:
N_A>1. Юзал несколько примеров (из инета и MSDN) — во всех у меня зависает Access после того как пытаюсь закрыть соединение (Close) или просто форму. Причем в Access начинает жрать 99% процессорного времени. (Глюк наблюдается для протокола TSP, примеры для UDP вроде не глючат)
N_A>2. Кто ковырялся в этом направлении, если смысл в такой идее или оно будет глючить по жизни и сможет ли работать несколько юзеров одновременно (как реализовать)?
N_A>И вообще у кого есть полный рабочий код (пример) с этими Winsock controls в Access?
N_A>п.с.
N_A>DoEvens-ы вставлял через строчку – не помогает.
N_A>________________________________________________________
N_A>С того момента накачал кучу примеров и на VB и на C++,но многие глючат (особенно VB), либо слишком сложны и перегружены ненужной функциональностью. Я так и не определился с технологией, а опыта нет, да и С++ хромает. Читал тут статью про сокеты, но она для крутых начинающих.
N_A>Не подумайте, что я ленивый или тупой, просто время, потраченное на изучение для меня очень дорого, и я хочу начать тратить его в нежном направлении, поэтому прошу оценить моё текущее виденье дел.

N_A>1. Писать качественный сервер на VB геморно, ибо проблемы с потоками и скоростью работы.
N_A>3. Использовать Winsock control тоже уже не хочу.
N_A>2. Писать решил на C++ (не очень удобно работать с базой Access, но попробую)
N_A>3. Не решил, как в моем случае правильнее обрабатывать несколько клиентов.
N_A>Пока думаю так:
N_A>Создаю сокет для "слушанья" клиентов, при "подключении" нового клиента создаю новый поток, который "работает" с этим клиентом.
N_A>Потоки принимают запросы от клиентов и записывают их в общую очередь (для корректного разделения общей очереди между потоками предполагаю использовать какие-нибудь критические секции или объекты ядра (почитаю в толстой книжке Виндовс для профессионалов)).
N_A>Очередь запросов обрабатывает поток, который читает и исполняет команды из этой очереди через ADO (или DAO) подключение к базе (посмотрю пример в инете).
N_A>Об окончании выполнения очередного запроса как-то должен узнать соответствующий поток (пока не думал как), и отправить результат клиенту.

N_A>Клиенты будут на MS Access.

N_A>Если все выше написанное считаете бредом – так и напишите, а если нет, то укажите на ошибки и дайте рекомендации. Про эти сокеты так дофига написано, что я и не знаю точно в каком «режиме» и какими библиотеками лучше пользоваться в моём случае. Если можно, дайте ссылку на подходящий пример и советы, что в него надо добавить, чтобы разрулить до описанного уровня.

N_A>Буду благодарен за любые комментарии.

Уточните, вы хотите писать свой сервер базы данных?

Здравствуйте, N_A, Вы писали:
N_A>2. Кто ковырялся в этом направлении, если смысл в такой идее или оно будет глючить по жизни и сможет ли работать несколько юзеров одновременно (как реализовать)?
Работать-то оно возможно и будет, но проблему

N_A>Со временем базы мдб растут вместе с числом пользователей, и многие операции замедляются до неприемлемого уровня.

не решит. ИМХО, нужно пересмотреть требования относительно mdb, и, скорее всего, перейти на другую БД.
Даже мой любимый Янус с некоторого количества записей в базе начинает тормозить. А Янус, как известно, писали лучшие умы rsdn...
N_A>Буду благодарен за любые комментарии.
На мой взгляд, Аccess подходит для создания очень небольших приложений... Если требуется взаимодействие по сети и быстродействие, то лучше писать свое клиен-серверное или трехуровневое приложение...

Спасибо за комменты.
Почему вы считаете, что это не решит проблему скорости работы? Это вроде и есть попытка создать свое клиент-серверное или трехуровневое приложение?
По поводу Януса аргумент не могу принять, ибо не знаком, могу предположить, что и MS Access писался далеко не плохими программерами и не один год.
Косвенным подтверждением жизнеспособности такой идеи считаю существование или попытку разработать аналогичные "надстроеки" над форматом MDB в таких прогах как БЭСТ, ИНФОБУХГАЛТЕР (хотя точных сведений нет). Я почти уверен, что нечто подобное уже кем-то реализовано.
Немаловажным плюсом в создании такого сервера для MS ACCESS считаю возможность решить проблемы падения при работе на "плохих" сетях и главное закрыть пользователям возможность получить прямой доступ к таблицам. Ставить MS SQL Server (и переходить на adp клиент) возможно и проще, но сначала очень хочется набить шишки в написании своего сервера.

А вообще меня больше интересует именно реализациия устойчивого "многоклиентного" (скажем не больше 100 подключений) сервера. Причем, реализация упрощающая работу с одним разделяемым ресурсом (очередь запросов)(Т.е., например, межпроцессорное взаимодействие подойдет не очень, а вот многопотоковоть, наверное, уже ближе). Обратился на RSDN потому как предположил, что здесь больше шансов найти специалистов по стевому программированию на с++, чем в моих "родных" форумах по базам данных.

Здравствуйте, N_A, Вы писали:

N_A>Спасибо за комменты.
N_A>Почему вы считаете, что это не решит проблему скорости работы?
Потому что само ядро Jet не может этого обеспечить, имхо.
N_A>Это вроде и есть попытка создать свое клиент-серверное или трехуровневое приложение?
В какой-то мере "да".

N_A>Косвенным подтверждением жизнеспособности такой идеи считаю существование или попытку разработать аналогичные "надстроеки" над форматом MDB в таких прогах как БЭСТ, ИНФОБУХГАЛТЕР (хотя точных сведений нет). Я почти уверен, что нечто подобное уже кем-то реализовано.
БЭСТ работает по клиент-серверной схема, не по трехзвенке.

N_A>Немаловажным плюсом в создании такого сервера для MS ACCESS считаю возможность решить проблемы падения при работе на "плохих" сетях и главное закрыть пользователям возможность получить прямой доступ к таблицам. Ставить MS SQL Server (и переходить на adp клиент) возможно и проще, но сначала очень хочется набить шишки в написании своего сервера.
Немаловажным минусом можно посчитать то, что придется вручную делать такие вещи, который сделаны в "больших" базах. Пул подключений, кэширование и т.п.
Вся штука в Jet. Оно (ядро) не предоставит нужно производительности. В противном случае, продажи Oracle и MSSQL упали бы до нуля. Можно потратить кучу времени на реализацию сервера приложений средствами Access и потом обнаружить, что бутылочное горлышко как раз в самом ядре. Собственно, эту проблемупризвана решить трехзвенка, абстрагирующая от уровня БД. Не подходит нам БД — меняем относительно безболезненно...
Если уже так хочется что-то делать с Mdb, то порекомендую делать это не средствами Access... Но это уже будет академик Айрапетян, который выиграл в лотерею "Волгу".

Ну хорошо, пусть Jet очень медлительна (в чем я не уверен) и есть самое узкое место. Все равно я не понял почему скорость не увелиится. Грубо говоря, пусть клиент ищет данные о товаре, по его наименованию. Разве скачать всю таблицу товаров (пусть индексов нет) с последующим поиском на клиенте будет быстрее, чем поиск на сервере (пусть и смопальном)? Ведь Jet юзается и там и там.
И если уж нато пошло, фиг с этой Jet, пишу свой сервер, для доступа к данным в своем формате (например txt), мне все равно нужен такой же скелет сервера.
Как Вы правильно заметили: "базу выбираем любую, какая получше". Поэтому суть важно написать именно рабочий сервер с очередью сообщений. О примере которого я и спрашиваю.

Здравствуйте, <Аноним>, Вы писали:

А>Как Вы правильно заметили: "базу выбираем любую, какая получше". Поэтому суть важно написать именно рабочий сервер с очередью сообщений. О примере которого я и спрашиваю.
Так это в корне меняет дело. Потому как в первоначальном посте был упор именно на Аксесс.

Здравствуйте, glyph, Вы писали:

G>Здравствуйте, <Аноним>, Вы писали:

А>>Как Вы правильно заметили: "базу выбираем любую, какая получше". Поэтому суть важно написать именно рабочий сервер с очередью сообщений. О примере которого я и спрашиваю.
G> Так это в корне меняет дело. Потому как в первоначальном посте был упор именно на Аксесс.
Давайте я еще раз расставлю все точки над "ё", чтобы получить понимание от как можно большей аудитории.

1. Нужна инфа (примеры, советы, ссылки и т.п.) по написанию сервера баз данных или приложений (пока не принципиально) на С++.
2. Сервер должен уметь устойчиво держать до сотни подключений и поддерживать общую разделяемую между клиентами (потоками) очередь запросов (текстовые сообщения до 1КБ).
3. Можно не брать во внимание, но для спарвки пишу, что в дальнейшем его предполагается прикрутить к MS Access (люблю я его, хотя возможны варианты).

Здравствуйте, N_A, Вы писали:

N_A>Решил реализовать такую штуку. На сервере запускается Форма из mdb которая на основе Winsock контрола «слушает» определенный порт и обрабатывает текстовые сообщения (запросы) приходящие через от клиентов. На клиентах юзается тот-же контрол.
Я когда-то извращался с DCOM и Access 97 для этих целей Access.Application поднимался на сервере (для каждого клиента -- свой аксес). Так делать не надо

Лучше всего перенести все формы и отчеты в так называемый Access Project (будет .adp файл вместо .mdb). Этот тип файла позволяет работать с MS SQL Server и запросы будут выполнятся на сервере, аксес будет получать только результат запроса.

Здравствуйте, Alexey_ch, Вы писали:

A_>Здравствуйте, N_A, Вы писали:

N_A>>Решил реализовать такую штуку. На сервере запускается Форма из mdb которая на основе Winsock контрола «слушает» определенный порт и обрабатывает текстовые сообщения (запросы) приходящие через от клиентов. На клиентах юзается тот-же контрол.
От такой реализации я уже отказался.

A_>Я когда-то извращался с DCOM и Access 97 для этих целей Access.Application поднимался на сервере (для каждого клиента -- свой аксес). Так делать не надо
Спасибо, что поделились опытом, не буду.

A_>Лучше всего перенести все формы и отчеты в так называемый Access Project (будет .adp файл вместо .mdb). Этот тип файла позволяет работать с MS SQL Server и запросы будут выполнятся на сервере, аксес будет получать только результат запроса.
Да, я знаю и возможно так и сделаю. Но MS SQL Server я знаю хуже, чем Access.
У меня просто какое-то необъяснимое желание поизучать сетевое программирование и сделать серверную надстройку именно над mdb. ИМХО такой популярный и удобный формат просто ДОЛЖЕН иметь серверную реализацию.
п.с.
MS SQL Server — дорого стоит.

Здравствуйте, N_A, Вы писали:
N_A>Да, я знаю и возможно так и сделаю. Но MS SQL Server я знаю хуже, чем Access.
Если пользоваться стандартным SQL92, то отличий не будет совсем.
N_A>У меня просто какое-то необъяснимое желание поизучать сетевое программирование и сделать серверную надстройку именно над mdb. ИМХО такой популярный и удобный формат просто ДОЛЖЕН иметь серверную реализацию.
На самом деле это интересная, но очень трудоемкая задача. Прийдется написать хороший сервер, который будет в состоянии обрабатывать несколько клиентов одновременно. WinSock контрол в этом деле не помощник. Плюс, для того чтобы как-то использовать результаты select запросов на клиенте прийдется реализовать стандартный интерфейс драйвера ODBC, DAO или ADO.
N_A>п.с.
N_A>MS SQL Server — дорого стоит.
Да, но время, потраченное на разработку честного клиент-серверного решения на базе Аксес может оказаться дороже. Если стоимость MS SQL настолько критична -- я бы порекомендовал использовать какой-нибудь MySql или Interbase, они выполняют запросы на сервере. Затем используя возможность создания связанных таблиц (Tables -> New -> Link Table) установить связь данных на сервере и клиентом на Аксесе, при этом Акскс будет видеть серверные таблицы как родные. Хочу сразу предупредить, что будут проблемы вроде отсутствия поддержки всех типов рекордсетов, но их прийдется решать, т.к. бесплатного сыра не бывает

Успехов.

N_A>Решил реализовать такую штуку. На сервере запускается Форма из mdb которая на основе Winsock контрола «слушает» определенный порт и обрабатывает текстовые сообщения (запросы) приходящие через от клиентов. На клиентах юзается тот-же контрол.

N_A>1. Юзал несколько примеров (из инета и MSDN) — во всех у меня зависает Access после того как пытаюсь закрыть соединение (Close) или просто форму. Причем в Access начинает жрать 99% процессорного времени. (Глюк наблюдается для протокола TSP, примеры для UDP вроде не глючат)

Как она это делает?
В большинстве примеров использования WinSock контроля есть грубые ошибки....
Кинь кусок кода, где ты с ней работаешь.

N_A>1. Писать качественный сервер на VB геморно, ибо проблемы с потоками и скоростью работы.
N_A>3. Использовать Winsock control тоже уже не хочу.
Видишь ли, используя винсок контрол, никто тебя не избавляет от необходимости писать качественный сервер. Это — только обертка над сокетом. Причем так себе обертка.

N_A>Пока думаю так:
N_A>Если все выше написанное считаете бредом – так и напишите, а если нет, то укажите на ошибки и

Считаю. Вот хороший совет — была книга Снайдера, называласаь то ли профессиональное программирование TCP/IP, то ли еще как-то очень похоже.
Там разобраны базовые грабли, очень подробно и с примерами.
Там есть примеры сервера и клиента, их использовать не надо. Надо прочитать разбор базовых граблей, все понять, а потом уже можно писать сервер хоть на VB, хоть на C++...
Я писал сервера на том и на другом — сложность примерно одинаковая, первые удобнее отлаживать, вторые быстрее работают... ну а так никакой разницы. В общем, учи матчасть.
Есть еще хорошая книжка — Network programming for w2000
но там та же самая информация размазана по большому объему текста.

Здравствуйте, Аноним, Вы писали:

А>Как она это делает?
А>В большинстве примеров использования WinSock контроля есть грубые ошибки....
А>Кинь кусок кода, где ты с ней работаешь.
Спасибо, тот код был на VBA в Access и мне уже подсказали в чем глюк. Код можно глянуть по ссылке из первого поста.

N_A>>1. Писать качественный сервер на VB геморно, ибо проблемы с потоками и скоростью работы.
N_A>>3. Использовать Winsock control тоже уже не хочу.
А>Видишь ли, используя винсок контрол, никто тебя не избавляет от необходимости писать качественный сервер. Это — только обертка над сокетом. Причем так себе обертка.
Я тоже уже несколько раз натыкался на такоеже мнение (про винсок контрол) и подсознательно стал его разделять.

N_A>>Пока думаю так:
N_A>>Если все выше написанное считаете бредом – так и напишите, а если нет, то укажите на ошибки и

А>Считаю. Вот хороший совет — была книга Снайдера, называласаь то ли профессиональное программирование TCP/IP, то ли еще как-то очень похоже.
А>Там разобраны базовые грабли, очень подробно и с примерами.
А>Там есть примеры сервера и клиента, их использовать не надо. Надо прочитать разбор базовых граблей, все понять, а потом уже можно писать сервер хоть на VB, хоть на C++...
А>Я писал сервера на том и на другом — сложность примерно одинаковая, первые удобнее отлаживать, вторые быстрее работают... ну а так никакой разницы. В общем, учи матчасть.
А>Есть еще хорошая книжка — Network programming for w2000
А>но там та же самая информация размазана по большому объему текста.

А вот за инфу по книгам отдельное спасибо. Кстати мне уже порекомендовали книжку Джонс Э., Оладн Дж. "Программирование в сетях Windows ", начал искать по местным магазам (Калининград) — пока безуспешно, В сети нашел оригинал на англ. с примерами(спасибо g.kostik).
Кстати очень забавно, многие примеры работают с несколькими клиентами без увеличения числа потоков... Как найду книжки, обязательно разрулю в чем секрет.

Alexey_ch писал: Плюс, для того чтобы как-то использовать результаты select запросов на клиенте прийдется реализовать стандартный интерфейс драйвера ODBC, DAO или ADO.

В тестовых примерах сервера (пока на Access VBA) я использую метод GetString библиотеки ADODB.Recordset ,он позволяет отправить клиенту записи из таблицы (запроса) ввиде строки разделенной ";", на клиентах очень удобно использовать такие строки в элементак "типа список" и "поле со списком".
До "честного" сервера мне пока еще очень далеко. Хотя написать драйвер для своего сервера задача тяжелая, зато интересная. Вроде на бейсике довольно несложно реализовать свой класс — источник данных надо только вьехать в детали (и застрелиться .И если у кого есть опыт — я с удовольствием послушаю.

Здравствуйте, N_A, Вы писали:

N_A>Тут я когда-то задался следующим вопросом. Привожу текст (чтобы не лезть по ссылке)
N_A>___________________________________________________________________
N_A>Лирическое отступление:
N_A>Со временем базы мдб растут вместе с числом пользователей, и многие операции замедляются до неприемлемого уровня. Решить (снизить остроту) проблему можно разными способами: пересмотр схемы данных, архивация, репликация, переход на клиент-серверную архитектуру, терминальный доступ и т.д. Все они требуют значительных временнЫх или(и) денежных затрат.

А чем, действительно, плох терминальный доступ? скорость самая максимально возможная. Там проблемма только в рессурсах, но это дешевле чем оплачивать труд программистов.

Если попрежнему не убедил, то напоследок порекомендую поглядеть в сторону C# чем C++. Там и с сокетом проще работать, примеров навалом, да и с базой работать легко.

Здравствуйте, vladserge, Вы писали:

V>А чем, действительно, плох терминальный доступ? скорость самая максимально возможная. Там проблемма только в рессурсах, но это дешевле чем оплачивать труд программистов.

V>Если попрежнему не убедил, то напоследок порекомендую поглядеть в сторону C# чем C++. Там и с сокетом проще работать, примеров навалом, да и с базой работать легко.

1. Хорошие терминальные службы сильно не бесплатные. (требуется работа на клиентах с фискальными регистраторами(на ком порту) и сканерами штрих кодов).
2. Мне уже не первый раз говорят: "как класно! терминал!" (в оснавном 1С-ники). от access-ников такое слышу редко поэтому жду статистики.
3. С# — возможно и лучше, но я с ним совсем не знаком(а на С писал в студенчиские годы довольно прикольные проги).
До работы с базой еще не дошел, пока читаю книжку "программирование в сети Windows".

Спасибо за отклик.

Волей судьбы разрабатывал почти такой же сервер , правда с несколько более сложной обработкой пакетов. Примеры из MSDN смотреть нужно смотреть с большой осторожностью — ИМХО слишком много в них ошибок.
Прочитав обсуждение могу посоветовать внимательнее выбирать модель самого клинет-серверного взаимодействия, и, если есть возможность отдавать предпочтения простым моделям. Сделать так, чтобы сервер держал одновременно 100 подключений достаточно сложно (особенно если среди них присутсвуют соединения по комутируемым линиям).
Если Вы решитесь писать такой сервер рекомендую уделить внимание следующим вопросам:
— синхронизация потоков (если плохо спроектировать будут большие проблемы при отладке)
— система обработки ошибок — рекомендую написать эту систему с самого начала — потом внедрять будет очень сложно — а система жизненно важная. Рекомендую реализовать логи со стеками вызовов и т.п. Иначе фиг разберешься когда и где возникла ошибка.
— производительность потока, принимающего соединения — этот поток не должен содержать длительных операций (создание нити относительно длинная операция, а дисковый обмен — тем более)
— управление работающими потоками — контроль выполнения, диагностика зависания, ошибок и т.п.
— управление соединениями (особенна важна диагностика "умерших" соединений)
— утечки памяти — как в вашем сервере так и в СУБД (!) — их быть не должно
— уничтожение процессов/потоков (никаких Terminate (!))
— закрытие соединений
— внимательно смотреть в сторону многопроцессорного сервера (рассинхронизация процессорных кэшей); сервера, поддерживающего Terminal Services (раздельные простроансва имен объектов ядра для различных сессий); машины с несколькими сетевыми картами (осбенно если используешь UDP).

Это те грабли, которые я смог вспомнить навскидку. Ну а самое главное — правильно спроектировать архитектуру.

Надеюсь, что Вы словите меньше глюков, чем словил в свое время я.
С наилучшими пожеланиями Михаил Копачев.

Здравствуйте, mkopachev, Вы писали:


M> Волей судьбы разрабатывал почти такой же сервер ,
Я же говорил, что кто-то должен был делать что-то похожее

Спасибо,за рекомендацци (скопировал и сохранил), сейчас читаю умную книжку и понимаю, как много нюансов в этом вопросе.
Кстати, чем закончилась Ваша разработка? (Если не секрет)

Здравствуйте, N_A, Вы писали:

N_A>Здравствуйте, mkopachev, Вы писали:


M>> Волей судьбы разрабатывал почти такой же сервер ,
N_A>Я же говорил, что кто-то должен был делать что-то похожее

N_A>Спасибо,за рекомендацци (скопировал и сохранил), сейчас читаю умную книжку и понимаю, как много нюансов в этом вопросе.
N_A>Кстати, чем закончилась Ваша разработка? (Если не секрет)

На данный момент работает в 8 регионах России. Идет внедрение
Если не серкрет, о какой умной книжке идет речь? Может мне тоже надо ее почитать?

Здравствуйте, mkopachev, Вы писали:

M>На данный момент работает в 8 регионах России. Идет внедрение
Ух ты,круто, а что за контора, прога (вид деятельности)? (Жутко интересно!!!)

M>Если не серкрет, о какой умной книжке идет речь? Может мне тоже надо ее почитать?
Программирование в сетях Windows (Джонс Э., Оладн Дж.) Еле нашел.
Еще помогает "Windows для профессионалов." (Джеффри Рихтер)
А Вы по каким учились?

Здравствуйте, N_A, Вы писали:

M>На данный момент работает в 8 регионах России. Идет внедрение
N_A>Ух ты,круто, а что за контора, прога (вид деятельности)? (Жутко интересно!!!)
Интересного, увы, не очень много — система предоставлет возможность удаленно работать с финансовыми документами.

N_A>Программирование в сетях Windows (Джонс Э., Оладн Дж.) Еле нашел.
N_A>Еще помогает "Windows для профессионалов." (Джеффри Рихтер)
N_A>А Вы по каким учились?

Обе вышеназванные имею в бумаге. Советую найти книги В. Столингса (имеются в виду книга по операционным системам и книга по сетям — предупреждаю сразу, там примеров кода нет — только концепции, но это очень полезно).
Могу также порекомендовать внимательно изучить несколько продуктов, которые сходны по функциональности с вашим — узнаете что нужно делать, не исключено что и как делать тоже догадаетесь.
Очень полезно поковырять исходники — смотри все до чего дотянешся...
Но все равно, какие бы умные книги не читал, то и дело натыкаешься на какие-нибудь грабли , так что будь готов

С уважением Михаил Копачев

Здравствуйте, mkopachev, Вы писали:

M>Обе вышеназванные имею в бумаге. Советую найти книги В. Столингса (имеются в виду книга по операционным системам и книга по сетям — предупреждаю сразу, там примеров кода нет — только концепции, но это очень полезно).
Сенькс.

M>Но все равно, какие бы умные книги не читал, то и дело натыкаешься на какие-нибудь грабли , так что будь готов

Всегда готов!

Здравствуйте, N_A, Вы писали:

/* поскипано */

Вставлю и я свои пять копеек...
Только сказанное — абсолютное имхо, просьба не вопринимать в штыки.

Предложенный вариант кустарного клиент-сервера на акцессе — имхо полнейший изврат.
Акцесс — врождённо тормознутая вещь, и держать на нём большую базу с частыми обновлениями и запросами — не слишком хорошо. Просто гениальный пример про Янус уже был приведён, браво Glyph!
Если хочется рабочий шутрый сервак, кучу рабочих клиентов и спокойную жизнь — то всю (возможно) имеющуюся базу из акцесса надо перегонять в MSSQL, или, если не устраивает финансовый аргумент, например в Firebird или MySQL (в котором насколько я помню нет ХП)
Если же хочется расковырять поподробнее сетевые технологии — то есть куда более весёлые и (если уж так надо) трудоёмкие примеры Напишите терминальную систему — типа "Удалённый рабочий стол". Мало не покажется. Хотя возможно я не прав.