2 c127

Позволь мне немного все-таки высказаться в пользу Access.
Текст твоего поста наводит на мысль, что ты не в курсе, что начиная с office2000 в Access появился новый тип приложения - ADP (Access Database Project), причем он представляет из себя полностью заточенного под MS SQL клиента.

Вопрос. А много ли есть программистов, пишущих клиентов на VB или Delphi, умеющих корректно обращаться с коннекшеном к MS SQL?
Ведь как они "рисуют" свои формы или DataSet-ы? Они кидают компонент, представляющий из себя ADODB.Connection, открывают и пользуют его.
А правильно ли это? Особенно, если к серверу одновременно подключены сотни клиентов? Конечно нет. Необходимо обыгрывать такие вещи как пул коннектов, выдавать коннекшены только на время операции (чтение рекордсета или update рекордсета), и тут же "отцеплять" их от рекордсета. Все это не сложно, но обычно этим никто не заморачивается. А вот Access очень даже заморачивается. Он генерит свои COM-объекты, совместимые по интерфесу с ADODB.Connection и ADODB.Recordset, но внутренняя реализация этих объектов "заточена" именно под MSSQL. Поэтому сотни клиентов на Access, подключенные к серваку, грузят его не так уж и сильно, ввиду корректности работы самого Access по отношению к MS SQL.

Все остальное - лирика. Нет практически ничего, что можно сделать на VB, но нельзя на Access. Все тоже самое. Только на Access многие вещи даже еще гораздо проще. :)

2 tygra
Когда ты научишься отвечать по-существу?
Я не знаю, что ты имеешь в виду. ADO - это и в африке ADO, и я знаю, что в дельфи есть объекты-роперы над объектами ADO. Моя мысль сводилась о конкретном использовании ADO как такового, а не использования его именно в дельфи. Существует ошибочное расхожее мнение, что если мы имеем только один объект - ADODB.Connection, но которым пользуются одновременно несколько открытых рекордсетов, то значит и реальный конекшн к базе только один. Чушь. Сколько открытых рекордсетов с приаттаченным коннекшеном, столько реальных конекшенов и открыто.

Как делаешь ты? (в двух словах).

2 Mik Prokoshin
Какие именно ресурсы сервера тратятся? :)
Я не разработчик этого продукта и не в состоянии дать подробного отчета. Но есть масса рекомендаций микрософт по корректной работе с их детищем.

Или речь идет об отсоединении-восстановлении connection ?
Да, например по таймеру (10-20сек) держать коннекшен открытым, после последнего использования (дабы не делать этого 10 раз в секунду в период активной работы :) ). Если приложение мульти-тредовое, то держать пул таких коннекшенов с ведением учета по каждому. Это так же ответ для funikovyuri.
Из-за особенностей COM я избегаю использования одного и того же коннекта из разных потоков.

2 Senin Viktor
"Чудеса" с хэндлами контролов (верней их отсутсвии при отсуствии фокуса на контроле, да и отсуствие (либо слабая и малопонятная) поддрежка сообщений виндоуса ) - это одна из вещей могущая отравить жизнь, но без нее легко обходится
весь прикол в том, что контролов-то и нет! В смысле нормальных, виндовых контролов. Почти все встроенные контролы Access - это ActiveX WindowLess Cotrols, т.е. они просто "рисуются" в окне формы-контейнера. Именно поэтому ленточная форма на Access сама по себе - шустрое дело. Прикинь, что было бы, если бы он создавал системные окна на каждый контрол! :)

2 pkarklin

я писал:
Существует ошибочное расхожее мнение, что если мы имеем только один объект - ADODB.Connection, но которым пользуются одновременно несколько открытых рекордсетов, то значит и реальный конекшн к базе только один. Чушь. Сколько открытых рекордсетов с приаттаченным коннекшеном, столько реальных конекшенов и открыто.

pkarklin писал:
Вот еще один пример полной чуши.

:) ты вообще хоть иногда в доки заглядываешь?

Disconnect Your Client Cursor from the Connection for R/O and Long-Use Scenarios
Disconnected Recordset objects are supported by the client cursor engine. Use this feature when you are performing a time-consuming operation that doesn't require expensive database resources to be held open. If you need to, you can later reconnect the Recordset to the connection to perform updates.

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

funikovyuri писал:
Use ADO Like an Apartment Model
Although the ADO implementation is free-threaded, don't use it in that way in the middle tier. Don't cache an instance of an ADO object, such as a Connection, globally and invoke methods on it concurrently from multiple threads. If each client request in your application model invokes the Connection.Execute method on a globally cached Connection object on the middle tier, your application will not scale. This is because of synchronization in the Connection.Execute method.

You will get much better throughput by using an application model where each client request creates a new instance of a Connection object, calls Connection.Open and then Connection.Execute, and releases the Connection object on the middle tier. Each request does have the additional overhead of creating a new instance of a Connection object and obtaining a connection from the connection pool. However, because your Connection.Execute call isn't synchronized, the throughput is much better.
Именно это я и имел в виду. У каждого потока (thread), обращающегося к базе должен быть свой коннект, и ни в коем случае не стоит использовать один общий из соседнего потока (именно потому, что ADO-объекты thread-safe, т.е. только один тред может одновременно использовать один объект, напр. конект).
Однако, закрывать коннект его сразу после использования, как предлагает здесь микрософт - жалко, поэтому и жду несколько секунд, вдруг понадобится (я понимаю, он автоматически берется из пула и т.д. и т.п., но вот ты сам же дал цитату, где говорится, что это требует времени).
Далее. Никогда не уповайте на автоматический пул коннектов. Он жив (для данной базы) только до тех пор, пока живет хоть один коннект к этой базе данных.

2 tygra (pkarklin)
насколько я понял, вы обращаетесь к базе из того же треда, в котором у вас работает основное GUI??? Да еще держите ПОСТОЯННО один глобальный конекшн открытым? Тогда все вопросы к вам немедленно снимаются, извините, конечно, но мы разговариваем на разных языках :)
Блин, ну меня умиляет это все У МЕНЯ ЕСТЬ ПОСТОЯННО ПОДКЛЮЧЕННЫЙ ОДИН КОННЕКТ, СМОТРИТЕ КАК Я КРУТ. мдя-я-я...
а при долгих запросах у нас приложение-то замирает и даже не прорисовывается... а грид мы показать не можем, пока к нему все запрошенные данные не придут. А все запросы исполняем только последовательно, один за другим. :) Видел такого, написанного именно на дельфи, вот так в лоб, предостаточно. Блин, один глобальный постоянно подключенный коннекшн. Ты еще в книгу это включи, для оболванивания населения.
Мне даже трудно представить себе конфигурацию сервера, который бы выдержал более 2 тыс одновременно подключенных таких, с позволения сказать, "программ".

Насчет задержек во время постоянных процедур подключения/отключения. Экспериментально установлено, что если с некоторой базой (именно базой внути инстанса сервака) работает только ОДИН пользователь, то после отключения на некоторое продолжительное время (точно не замерял, что-то около минуты-две), повторное соединие происходит с задержкой (2-3 сек).
Если же с ЭТОЙ базой работает одновременно несколько пользователей, то повторные подключения выполняются мгновенно, по крайней мере, субъективно не заметны оператору.

Оператор может заполнять один документ произвольное количество времени, и к чему все это время держать конект активным?

В 1999-м к моему SQL 7.0-серваку на Celeron-333 256M подключались сотни клиентов и спокойно работали. Кстати, вначале я тоже держал один коннект постоянно открытым. Пока работают десяток-другой клиентов - это не заметно. Но когда больше...

Вдогонку, насчет Access. Как раз-таки Access предоставляет пользователю ОДИН ГЛОБАЛЬНЫЙ объект, совместимый по интерфейс с ADODB.Connection, но он заточен спецами по MS SQL таким образом, что клиентское приложение "щадит" ресурсы сервера. Но конечно, все это полная чушь , пришел Тигра (pkarklin) и показал разработчикам MS SQL как правильно писать клиентские приложения для ИХ SQL Server.
Научи их, Тигра, научи... а то несчастные разработали MS SQL и сами не поняли, чего там они разработали.

----
В многоуровневых приложениях, где операции с базой берет на себя средний слой , нужно юзать более одного коннекта (см. последний пост funikovyuri). И там действительно полезно ВСЕГДА держать хотя бы один коннект активным. Но, дык, это же совсем другая песня. К одному SQL серваку обычно подключают весьма ограниченное число серверов приложений. А зачастую, так и вообще один. В этом последнем случае я бы вообще держал постоянно по одному открытому коннекту на каждый рабочий тред в пуле тредов, для уменьшения времени отклика сервера приложений.