Какие компоненты лучше использовать для доступа к MS SQL ?

← →
DmiSb (2006-06-05 15:20) [0]

Нормально ли работают ADOExpress в Delphi7

← →
Ega23 © (2006-06-05 15:29) [1]

> Какие компоненты лучше использовать для доступа к MS SQL
> ?

ADO

> Нормально ли работают ADOExpress в Delphi7

"Нормально" - это перпендикулярно поверхности.

← →
DmiSb (2006-06-05 15:36) [2]

"Нормально" - это в смысле глюков много или не очень ?

← →
Ega23 © (2006-06-05 15:38) [3]

> "Нормально" - это в смысле глюков много или не очень ?

Мне вот интересно: а почему некоторые человеки начинают винить в глючности Delphi, ADO, C++ etc, вместо того, чтобы просто выпрямить руки?

← →
DmiSb (2006-06-05 15:42) [4]

Я согласен выпрямить руки :)
Просто не хочеться сразу стукаться рожками в проблемы (ошибки при работе той же Delhpi, ADO). Для Delphi5 Borland официально выпустила 2 обновления, которые касаются именно ADO. Вот мне и стало интересно как обстоят дела в Delhpi 7.

← →
Still Swamp (2006-06-05 15:44) [5]

Рекомендую ADO. Никаких проблем не замечено за долгое время.
Есть глюки у старых MDACов, связанные с поддержкой коннекта, но в последних версиях 2.8 SP1 исправлено. Так же рекомендую как вариант устанавливать соединение по надобности.

← →
Ega23 © (2006-06-05 15:45) [6]

> Для Delphi5 Borland официально выпустила 2 обновления, которые
> касаются именно ADO. Вот мне и стало интересно как обстоят
> дела в Delhpi 7.

Насколько мне известно - проблем нет. Ни в D5, ни в D7. Хотя ADO на месте не стоит, может и для семёрки через какое-то время патч нужен будет... :о)

← →
Ega23 © (2006-06-05 15:47) [7]

> Так же рекомендую как вариант устанавливать соединение по
> надобности.
>

В смысле?

← →
Still Swamp (2006-06-05 16:57) [8]

В смысле глюк был связан с тем что соединение уже установлено и держится за свет Alive.... по идее. Потом происходит любой exec и приходит исключение.

На тот момент вышли из положения тем что приконнектились, процедуру вызвали, отключились. И так далее.

← →
Ega23 © (2006-06-05 17:05) [9]

> На тот момент вышли из положения тем что приконнектились,
> процедуру вызвали, отключились. И так далее.

Ну это, ИМХО, изврат. В принципе, если обращение к базе редкая операция - можно и так реализовать. Но если очень часто... Просто само по себе создание подключения - дорогая штука. А когда бьёшься за миллисекунды - это совсем неприемлемо.

Вот как раз была задача недавно, нужно было отслеживать состояние связи с сервером, при этом информацию на экран выводить (нормальная картинка, либо "соединение разорвано").
Реализовал так: создаю отдельный поток, передаю в него ConnectionString, создаю в рамках этого потока свой экземпляр ADOConnection, соединяюсь и дальше начинаю каждые 5 секунд (параметр настраивается) пытаться выполнить запрос "Select top 1 id from susobjects".

← →
saxon (2006-06-05 17:09) [10]

> Still Swamp (05.06.06 16:57) [8]
> приконнектились, процедуру вызвали, отключились. И так далее.

А с пулом соединений что происходит?

← →
Still Swamp (2006-06-05 17:12) [11]

Вот именно что ИМХО.
Соединение проходит при нормально рабочей сети за 0.025 сек. Так что 5 секунд думаю не кричино.

Что получаем при таком подходе. Отсутствие бороды из мертвых перегрузившихся пользователей. Гарантированное подключение без извратов, если пользователь вышел из зоны wifi, или выдрал хвост у машины. Или подменили сервер перенаправление dns или еще что. И все без хлопанья окошками... откройте закройте программу....

← →
Still Swamp (2006-06-05 17:15) [12]

А с пулом соединений я не знаком. Это забота SQLщиков... а они не жалуются.

← →
sniknik © (2006-06-05 17:25) [13]

Ega23 © (05.06.06 17:05) [9]
> "Select top 1 id from susobjects".
привлечение таблици... уже тормоза хоть и небольшие.
делай "Select 1 as id" для проверки коннекта достаточно, результат тоже можно не проверять, только ждать эксепта.

← →
saxon (2006-06-05 17:26) [14]

> Still Swamp (05.06.06 17:15) [12]
> Это забота SQLщиков... а они не жалуются.

А они и не будут жаловаться. Это в программе бяка вылезит, а сервер будет работать как и работал.

← →
Still Swamp (2006-06-05 17:26) [15]

Э... а....
Какие бяки меня ожидают? Конкретней. :)

← →
saxon (2006-06-05 17:30) [16]

То что соединение не может быть установленно, т.к. пул переполнен.
Это я к тому, что конечно надо > устанавливать соединение по надобности, но не без ума. :)

← →
Ega23 © (2006-06-05 17:31) [17]

> делай "Select 1 as id" для проверки коннекта достаточно,
> результат тоже можно не проверять, только ждать эксепта.
>

Гм.. Мысль интересная. Оно же всё равно в рамках определённой базы будет идти...
Слушай, ну в очередной раз - спасибо! Это я не додумался...

← →
Ega23 © (2006-06-05 17:33) [18]

> Что получаем при таком подходе. Отсутствие бороды из мертвых
> перегрузившихся пользователей. Гарантированное подключение
> без извратов, если пользователь вышел из зоны wifi, или
> выдрал хвост у машины. Или подменили сервер перенаправление
> dns или еще что. И все без хлопанья окошками... откройте
> закройте программу....

А если тройная связка Master-Detail? На каждое - свой коннект? И как вообще такую связку при таком подходе организовать?
Что-то не совсем представляю...

← →
Still Swamp (2006-06-05 17:35) [19]

Детальнее что значит переполнен пул.
На локальной тачке?
Не встречал такого. У меня стоит робот билинг на АТС 700 внутренних номеров. Регулярно таким образом информирует базу о каждом действии абонента (сняли трубку, положили трубку, нажали кнопочку на аппарате, и проч тапишные сообщения) и ни про какие пулы не жалуется.

← →
Still Swamp (2006-06-05 17:36) [20]

>
> А если тройная связка Master-Detail? На каждое - свой коннект?
> И как вообще такую связку при таком подходе организовать?
>
> Что-то не совсем представляю

Что имеется в виду мастер-детал?

← →
Ega23 © (2006-06-05 17:40) [21]

dataSet1, dataSet2 : TDataSet; DataSource1, DataSource2 : TDataSource; DBGrid1, DBGrid2 : TDBGrid; DataSource1.DataSet:=DataSet1; DBGrid1.DataSource:=DataSource1; DataSet2.DataSource:=DataSource1; DataSource2.DataSet:=DataSet2; DBGrid2.DataSource:=DataSource2;

← →
Ega23 © (2006-06-05 17:44) [22]

В двух словах:
Есть Master-грид, "смотрит" на один набор данных.
Есть detail-грид, "смотрит" на второй набор данных.
При перемещению по первому гриду выполняется подзапрос для второго грида.
Ну, например, в первом НД - заказы зв какой-то день, во втором - что конкретно было заказано в данном заказе.

← →
Still Swamp (2006-06-05 17:49) [23]

А это называется найти себе проблему и смело с ней бороться...

Я это делаю так...
Оборачиваю в DLL доступ к базе.

В начале проэкта: CreateDatabase.... создается объект соединение с базой но само соединение не устанавливается, выясняется логин пароль пользователя и запоминается, там коммандные строки и прочие настройки.

По надобности
p:=CreateProc("PROCNAME");
PutParam(p,"param1") .... заполняю параметры
Open(p) .... установка соединения, и проч... все в DLL
ReadData(p)
Close(p)

Да волшебное правило.... делаю один в одной DLL. Если надо несколько связных элементов на форме - вызываю эти DLL, с нужными калбэками, с выводом в TWinControl. А заботится о создании подключений пот множество датасетов - уже одна ado.dll.

← →
Still Swamp (2006-06-05 17:53) [24]

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

← →
Ega23 © (2006-06-05 17:59) [25]

> А это называется найти себе проблему и смело с ней бороться.
> ..

Ну почему? У тебя, похоже, классическая трёх-звенка. Иногда действительно очень мощная и очень нужная вещь. Но в случае простой клиент-серверной системы - это как из пушки по воробьям.
Т.е. что хочу сказать: вариант имеет право на существование. Вот только пользовать его тоже надо с умом, а не при каждом удобно случае.
ИМХО.

← →
Ega23 © (2006-06-05 18:00) [26]

> У тебя, похоже, классическая трёх-звенка.

Щас тут подумал - не совсем классическая. К запросам привязан сильно.

← →
Still Swamp (2006-06-05 18:04) [27]

вообще никак не привязан.
запросы - не моя забота. это забота SQLщиков. Моя забота вызывать SP, пхать туда параметры на свое усмотрение и получать данные на свое усмотрение. Что не прочиталось - не проблемы клиента. Длл работы с базой ругнется, клиент подставит умолчальные данные которые я хочу видеть и напишет фразу по вопросам звоните туда то и прочитайте ошибку. SQLщики далее думают что делать.

у меня в тексте ни одного запроса нет на весь проект. ни одного. и меня это так радует.

← →
Still Swamp (2006-06-05 18:06) [28]

А что касается маленкого проекта... так как показала практика, любой маленький проект если он нужен - превращается в большой, а если не нужен, так что с ним возиться... с ненужным то проектом.

← →
Ega23 © (2006-06-05 18:10) [29]

> запросы - не моя забота. это забота SQLщиков. Моя забота
> вызывать SP, пхать туда параметры на свое усмотрение и получать
> данные на свое усмотрение. Что не прочиталось - не проблемы
> клиента. Длл работы с базой ругнется, клиент подставит умолчальные
> данные которые я хочу видеть и напишет фразу по вопросам
> звоните туда то и прочитайте ошибку. SQLщики далее думают
> что делать.

А вызов SP - не запрос? Или ты сам текст запроса (exec s_tra-ta-ta @param1="ля-ля-ля" и т.п.) тоже откуда-то получаешь?

> А что касается маленкого проекта... так как показала практика,
> любой маленький проект если он нужен - превращается в большой

Небогатая, однако, практика...

← →
Still Swamp (2006-06-05 18:17) [30]

Вызов SP для меня не запрос, и exec_tra-ta-ta я не пишу, чему и была столь непопулярная ветка про FB где мне пытались объяснить мое криворучие. Так как:

ADOStoredProc.ProcName:="MyProcName";
ADOStoredProc.Prepare;
ADOStoredProc.ParamByName(ляляляля....
ADOStoredProc.ExecProc;
Ну или если надо то
ADOStoredProc.Open;
Лялляля
ADOStoredProc.Close;
a:=ADOStoredProc.ParamByName(ляляляля....

Вот ведь смех то. И ни одна лялечка в проекте ничего более не знает ни про какие SQL сервера, адо и прочее. И даже в рабчих формах DB.pas то не подключается.

← →
saxon (2006-06-05 18:21) [31]

> Still Swamp (05.06.06 18:04) [27]

Интересно (на самом деле), такой схемы работы еще не встречал.
А как вы поступаете если, например ктото из вас ошибся. Кто виноват?
Как вы организовываете взаимодействие?

> Still Swamp (05.06.06 18:04) [30]

А кто пишет - эту самую длл для работы с базой? Если не ты - то почему ты вопросы задаешь?

← →
Still Swamp (2006-06-05 18:24) [32]

Кто ошибся? Программисты?

DLL написал я. Но там тоже нет ни одной строчки запросов. Текст могу предоставить.

← →
Still Swamp (2006-06-05 18:27) [33]

А вопросы задаю потому что удодский FB с которым мы сидим уже неделю видете ли не возвращает DataSet из SP. И теперь мне надо для него написать более интелектуальную обертку, которая сначала по имени процедуры получит список параметров, заполнит их подготовит для принятия значений из клиента, построит этот пресловутый select * from SP (....) и сделает все остальное.

Это меня изрядно веселит.

← →
Still Swamp (2006-06-05 18:29) [34]

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

← →
saxon (2006-06-05 18:34) [35]

> select * from SP (....)

Ну вот это я тож считаю ерундой, но как есть так есть!! Я так понимаю они для совместимости не хотят улучшать.

А по поводу запросов к базе, то в любом случае либо это sql текст либо SP без "select * from" все равно это запрос (к слову о терминологии).

← →
Still Swamp (2006-06-05 18:39) [36]

Я НЕ пишу select * from....
Как бы так эдак еще объяснить почему это хорошо и чем для меня оно критично.

Я вызываю процедуры по именам не заботясь о том что они делают. Я в них пхаю параметры, получаю результат. Но мне не надо писать, ах дорогой sql, а не соблаговолите ли вы считать следущий вызов выборкой из таблицы, а вот еще я тут собрался insert подсуетить.

Это не проблемы клиента.

> Я в них пхаю параметры, получаю результат

А список параметров где берешь ?

> А вопросы задаю потому что удодский FB с которым мы сидим
> уже неделю видете ли не возвращает DataSet из SP.

Вот, блин, всю жизнь возвращал, а в июне 2006 - перестал.

← →
saxon (2006-06-06 10:48) [39]

← →
Still Swamp (2006-06-06 10:52) [40]

> > А вопросы задаю потому что удодский FB с которым мы сидим
> > уже неделю видете ли не возвращает DataSet из SP.
> Вот, блин, всю жизнь возвращал, а в июне 2006 - перестал.

Да расскажите же КАК из SP на FB получить DataSet. Благодарен буду. Очень Очень....

← →
Still Swamp (2006-06-06 10:54) [41]

SP - это не Query.... SP - это StoredProcedure.... StoredProcedure это не select * from....

Какие компоненты лучше использовать для доступа к MS SQL ? Найти похожие ветки