Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Access or Delphi  [new]
Tung
Member

Откуда: Архангельск
Сообщений: 539
подскажите лучшее решение,
я работал с MSSQL и Delphi,
Заказчик хочет многпользовательскую базу и клиента на Accesse,
я с акцессом в прошлом не рабтал
вопрос 1:
база акцесса является ли многопользовательской или нет,
вопрос 2:
писать клиент на акцессе или убедить заказчика что на дельфе лучше

???
2 ноя 03, 20:22    [403115]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Denis A.
Member

Откуда: Челябинск
Сообщений: 353
Писать на аксессе используя MSSQL как СУБД.
2 ноя 03, 20:32    [403121]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
c127
Guest
Писать клиента на акцесе есть извращение. Использовать акцесс как многопользовательскую СУБД тоже есть извращение, будет сильно тормозить, кроме того будут пропадать данные. Для многопользовательских (>=2) приложений нужно брать какой-нибудь SQL сервер, например тот же MSSQL.

Пиши клиента на дельфи, раз с ним знаком, что взять в качестве SQL сервера зависит от предполагаемых объема данных, количества клиентов и трафика. Но оракл либо ДБ2 наверняка будет достаточно.
3 ноя 03, 00:35    [403176]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Pavel
Member

Откуда: Кемерово
Сообщений: 2435
Если пишется заказной некоммерческий продукт, то можно и на Ассеss, естественно проект adp.
3 ноя 03, 08:26    [403293]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Delphi + MSDE

обьясни заказчику, что access имеет ряд ограничений, в а MSDE позволит без дополнительных затрат повышать производительность переходом на другие версии сервера + возможность репликации
3 ноя 03, 19:24    [404697]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Pavel
Member

Откуда: Кемерово
Сообщений: 2435
У проекта adp Access есть только одно серьезное ограничение - возможность работы только с MSSQL (MSDE).
4 ноя 03, 06:42    [404920]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Senin Viktor
Member

Откуда: Подмосковье
Сообщений: 5006
2Tung

А сколько клиентов будут работать с базой постоянно? Чем они будут заниматься? Какой объем информации планируется вводить/изменять? Какой ее прирост в месяц? И т.п.

А заказчика лучше убедить использовать то, что ты знаешь: Дельфу и сиквел. Хуже от этого никому не станет.

2с127
>Писать клиента на акцесе есть извращение

Если не знать акеса - то да. Так же, если у прогера извращенный вкус и любовь к красному фону форм и желтым буквам :) Только акес здесь не причем

>будет сильно тормозить, кроме того будут пропадать данные

Смотря сколько юзеров подключенно и на сколько качественно написан код. А данные не пропадают, они иногда могут "портится", соблюдая некоторые правила - риск порчи можно свести к минимуму.
4 ноя 03, 09:26    [405006]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Youry
Member

Откуда: Киев
Сообщений: 70
MS SQL (MSDE как легкий вариант) + MS Access (ADP) - это вполне нормальная комбинация. Особенно если заказчик так настроен.
4 ноя 03, 23:15    [406475]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
c127
Guest
Senin Viktor
>Если не знать акеса - то да. Так же, если у прогера извращенный вкус и любовь к красному фону форм и желтым буквам :) Только акес здесь не причем

Я почти не знаю акцесс. Я сужу в основном по тому, что он никем всерьез как клиент не рассматривается. VB, дельфи - полно, а акцесса нет. Все проекты, использующие mdb формат данных и которые я знаю, используют VB в качестве GUI. Это неспроста.

>А данные не пропадают, они иногда могут "портится", соблюдая некоторые правила - риск порчи можно свести к минимуму.

Совершенно непонятно зачем тратить силы и сводить риск порчи данных к минимуму какими-то специальными приемами, если есть SQL сервера, в которых такой риск уже сведен к минимуму?
5 ноя 03, 00:32    [406516]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
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 многие вещи даже еще гораздо проще. :)
5 ноя 03, 03:19    [406535]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
f_w_p
Guest
Смотря сколько юзеров подключенно и на сколько качественно написан код. А данные не пропадают, они иногда могут "портится", соблюдая некоторые правила - риск порчи можно свести к минимуму.
Можно поподробнее о причинах пропадания и способах минимизации. Руководство навязало нам систему на ACCESS и теперь у нас одно из любимых занятий вылавливать какие записи пропали и восстанавливать их из архива.
5 ноя 03, 08:13    [406588]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2vdimas:
А можно поподробнее, какие ресурсы SQL сервера, собственно, тратятся при открытии клиентского датасета ADO ?
Или речь идет об отсоединении-восстановлении connection ?

А про Access я могу сказать только то, что у каждой новой версией имеется несовместимость с предыдущей. И Access идет в составе офиса. А Office многие стараются поддерживать в "актуальном состоянии".
5 ноя 03, 09:48    [406704]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
vdimas - обычно практикой для начинающего Дельфиста является создание общего DataModule'я на котором лежит общий TADOConnection
Это во-первых - во вторых ADO и так по-умолчанию использует POOL соединений
5 ноя 03, 10:01    [406734]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
tygra
Member

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


Ты на Дельфе то работал, и через ADO? Кажется нет - такую белебердень нести. Отвечать не буду - тут в каждом топике почти есть ответ по этому поводу.

2 pkarklin Придется еще и это в книгу включить

-- Tygra's --
5 ноя 03, 10:21    [406793]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Senin Viktor
Member

Откуда: Подмосковье
Сообщений: 5006
2c127
> Я сужу в основном по тому, что он никем всерьез как клиент не рассматривается. VB, дельфи - полно, а акцесса нет. Все проекты, использующие mdb формат данных и которые я знаю, используют VB в качестве GUI. Это неспроста.


Иногда мне кажеться, что людям просто нравится вручную колбаситт боунд/анбоунд контролы, искать аналогии выпадающим многостолбиковым спискам, использовать то какие-то левые, то сильно дорогие генераторы отчетов и т.п. вещи, котрые уже встроенные в акес. Ну не любяит у нас прогеры, чтобы без гемору

>Совершенно непонятно зачем тратить силы и сводить риск порчи данных к минимуму какими-то специальными приемами, если есть SQL сервера, в которых такой риск уже сведен к минимуму?

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


2f_w_p
>Руководство навязало нам систему на ACCESS и теперь у нас одно из любимых занятий вылавливать какие записи пропали и восстанавливать их из архива

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

2vdimas
>Нет практически ничего, что можно сделать на VB, но нельзя на Access.

"Чудеса" с хэндлами контролов (верней их отсутсвии при отсуствии фокуса на контроле, да и отсуствие (либо слабая и малопонятная) поддрежка сообщений виндоуса ) - это одна из вещей могущая отравить жизнь, но без нее легко обходится.

2Mik Prokoshin
>А про Access я могу сказать только то, что у каждой новой версией имеется несовместимость с предыдущей

Надуманное обвинение.
А что в дельфи 3 было все то же, что и в дельфи 5? Все совместилось?
Нормальная вещь - новая версия - новые функции, форматы бд.

===
кесарю кесарево.
И выбор акеса как хранилища (mdb) и как клиента должен быть обоснован.
И тот и другой продукт могут решить свою задачу...если продукт делает профессионал в своем деле.
5 ноя 03, 17:37    [407836]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Senin Viktor писал:

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

В скуле, это обычно настраивается раз и навсегда. И нет необходимости в каждом клиенте городить огород

Senin Viktor писал:

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

Так уж приключилось, что на одной машине у меня крутиться клиент к MS SQL, сама база MS SQL 6.5 и однопользовательская база на mdb. Крутяться они уже года четыре, в режиме 24х7. Про MS SQL я вспоминаю только тогда, когда нужно добавить новый функционал в клиента. Даже на новые версии не перевожу, незачем. А вот для нормальной работы mdb пришлось обучать дежурных админов, что бы они ее умели "поднимать", а то устал в 6 утра суботы бегать ее "восстанавливать". К счастью, то, что там записывается, никому не нужно. Справочники никогда не изменяются и с легкостью восстанавливаются из дистрибутива.

Senin Viktor писал:

Надуманное обвинение.
А что в дельфи 3 было все то же, что и в дельфи 5? Все совместилось?
Нормальная вещь - новая версия - новые функции, форматы бд.

Все совместилось. Появились дополнительные удобства.
Вот в версиях скулей структура баз меняется. Но на то они и называются РЕЛЯЦИОННЫМИ, что способ обращения не зависит от физической структуры таблиц. Так что, мои клиенты на дельфях даже "не заметили", что они работают уже не MS SQL 6.5, а с 7.0 и 2000.

Senin Viktor писал:

кесарю кесарево.
И выбор акеса как хранилища (mdb) и как клиента должен быть обоснован.
И тот и другой продукт могут решить свою задачу...если продукт делает профессионал в своем деле.

На самом деле то г*, которое я описывал, представляет клиента на дельфи к mdb . Руки бы поотрывал!
5 ноя 03, 21:58    [408108]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
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 сама по себе - шустрое дело. Прикинь, что было бы, если бы он создавал системные окна на каждый контрол! :)
5 ноя 03, 22:31    [408122]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Senin Viktor
Member

Откуда: Подмосковье
Сообщений: 5006
2vdimas
>весь прикол в том, что контролов-то и нет!

Знаю я про это. Не которые - нет. И пытаются hwnd получать да message ловить там где их нет. Простой выход уж если очень захочется: использовать сторонние компоненты.


2Cat2
>А вот для нормальной работы mdb пришлось обучать дежурных админов, что бы они ее умели "поднимать", а то устал в 6 утра суботы бегать ее "восстанавливать".

Лично меня после 2-3 поломок бд это все начинает напрягать и я начинаю искать причину сбоев. Правда, там где работаю (работал), т.е при мне - нифига база не падала, а вот у клиентов (без всякого обслуживания с моей стороны - все как бы на автомате) - было несколько раз: ничего страшного - разобрались.

==
А главное в Акесе: делать бакапы! Наконец-то в 2003 ввели давно нужную фичу - бакап из меню :) Глядишь в 2020 - появиться возможность создовать бакапы по расписанию :)
6 ноя 03, 09:45    [408369]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 vdimas

автор писал:
Когда ты научишься отвечать по-существу?


А что тебе отвечать по существу. Чем больше ты постишь, тем больше чуши в твоих постах.

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


Вот еще один пример полной чуши. Не переноси то, что городит Access при работе с сиквелом (а именно беспорядочное открыти/закрытие коннектов), с нормально разработанным приложением, которое работает через один коннект. Ты чуствуется ни разу не видел нормальных приложений, работающих через один коннект. Более того, для реализации некоторых фичей в своих проектах я еще и пуллинг соединений отключал. Как инструмент для разработки рыбы Access еще потянет. Но серьезный проект ему не позубам.

2 tygra

Книгу таки придеться писать. :-)
6 ноя 03, 09:52    [408377]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Точно, придется :)

У меня 1 (один ) коннект в приложении. И на сервер идет 1 (один) коннект.
Лучше писать на том, чего зависит полностью от программиста, чем на том. что работает само по себе и городит мешок коннектов.

-- Tygra's --
6 ноя 03, 11:31    [408592]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

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

Не совсем так. Так м.б. только при использовании серверных рекордсетов, при клиентских - число сессий зависит только от одновременно параллельно выполняемых запросов. Это при включенном пулинге. Без - сессия всегда одна.

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

Я извиняюсь, но просто в тех статьях, что я читал по увеличению эффективности ADO DB приложений в intranet, ничего про отсоединения не было. Напомните источники, если не трудно.

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

>Если приложение мульти-тредовое, то держать пул таких коннекшенов с ведением учета по каждому.

Скажу честно, что с multi-thread и ADO не работал, не знаю. Но вроде бы ADO thread-safe, нет ?
6 ноя 03, 12:19    [408711]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2vdimas:

Насчет pool'а в ADO

Pooling is available in two forms for applications that use the Microsoft Data Access Components: ODBC offers connection pooling through the ODBC Data Source Administrator, and OLE DB core components provide resource pooling as well as additional services such as shaping and the client-side cursor.

OLE DB Resource Pooling
OLE DB resource pooling, also known as OLE DB session pooling, is handled by the OLE DB core components. To take advantage of resource pooling, an OLE DB consumer must invoke the data provider by using either the IDataInitialize or the IDBPromptInitialize interface. (ADO will attempt to do this automatically.) OLE DB resource pooling can be turned on for one provider and off for another.


Это цитаты отсюда http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/pooling2.asp

P.S> так что ты там по таймеру у сооединения закрывал?
6 ноя 03, 14:09    [408971]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Mik Prokoshin

Скажу честно, что с multi-thread и ADO не работал, не знаю. Но вроде бы ADO thread-safe, нет ?

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.



оригинал здесь
6 ноя 03, 16:39    [409108]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
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 уже дал ссылку.
Там же прочти про пулы коннекшенов, которые создаются и множатся, независимо от твоего желания.
6 ноя 03, 22:50    [409403]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
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 серваку обычно подключают весьма ограниченное число серверов приложений. А зачастую, так и вообще один. В этом последнем случае я бы вообще держал постоянно по одному открытому коннекту на каждый рабочий тред в пуле тредов, для уменьшения времени отклика сервера приложений.
6 ноя 03, 23:15    [409411]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить