| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Компоненты прямого доступа к MSSQL [D6, MSSQL]
Я Ламер © (2004-05-09 00:30:00)Здравствуйте All.
Интересует сабж. Как правило работаю с MSSQL сервером через ADO, недавно узнал, что есть компоненты прямого доступа к MSSQL. Так вот интересует какие преимущества/недостатки дает такой подход, и где можно найти такие компоненты. Спасибо.
KSergey (2004-05-12 08:31:00) [1]> [37] SergSuper (11.05.04 21:29)
Вы конечно супер, вам виднее... ;)
Однако прдставитель борланда ссылался на то, что они по каким-то соглашениям с MS имеют доступ к некоторой "расширенной" документации, на основании которой они (борландовцы) строят свои компоненты доступа в новый версиях дельфи.
> [36] Я Ламер (11.05.04 17:24)
> Очень как-то много слов и мало толку. Все "проблемы", про
> которые здесь говорили не являются таковыми. С помощью ADO
> можно реализовать как свой SQL запрос на обновление
А вот отсюда поподробнее можно, а? Как именно? Просто перечислить, хотя бы.
> Меня интересуют действительно
> какие преимущества дает SDAC. На сколько процентов быстрее
> я могу загрузить данные из MSSQL, по сравнению с обычным
> Query и ClientDataSet-ом.
Я не знаю про SDAC
Приводимые в свое время цифры создатлями SQL Query, на сколько помню, отличались (в лучшую сторону) процентов на 10, максимум 15 от доступа через BDE (ODBC видимо использовалось?). Вроде упор делался на скорость фетчинга записей.
ADO еще не было вроде. Было какое-то DAO и т.п. "переходные" технологии.
Так что говорить о существенном приросте точно не приходится, тем более, что, как верно замечено, основное время - это выполнение запроса сервером...
SergSuper (2004-05-11 21:29:00) [2]2 KSergey
> По информации, которой козыряет борланд (в частности, могу
> опять сослаться на Орлика), DB Library вовсе не остановлена.
> И все она поддерживает
Что - Борланд разрабатывает DB Library? Ну-ну
Ну надо же понимать что DB Library - это прошлый век, они разрабатывались еще Сайбейзом, там все функции основаны на получении неких хенделов и работы через них. А в OLEDB вызовы осуществляются как можно догадаться вызовом функций соответсвующих интерфейсов.
Что касается того стоит ли использовать сторонние компоненты... В принципе основное время тратится на обработку сервером и гнаться за милисекундами тут смысла особого нет (за исключением задач массовой заливки данных на сервер). Что касается всяких удобств - наверное можно найти(или самому сделать) компоненты которые написаны не вместо, а поверх АДО и обеспечивают дополнительный функционал(а он вам кстати нужен?).
Мой принцип - как можно больше придерживаться стандартных решений. Хотя бы потому что гораздо больше людей использует ADO чем SDAC. Я последнего не знаю и не исключаю что он в чем то лучше, но пользоваться всё равно не советую :)
Я Ламер (2004-05-11 17:24:00) [3]Очень как-то много слов и мало толку. Все "проблемы", про которые здесь говорили не являются таковыми. С помощью ADO можно реализовать как свой SQL запрос на обновление, так и
обработку кешированых изменений. Меня интересуют действительно какие преимущества дает SDAC. На сколько процентов быстрее я могу загрузить данные из MSSQL, по сравнению с обычным Query и ClientDataSet-ом. Могу ли я через эти компоненты использовать именно особенности MSSQL (BULK INSERT, DISTRIBUTED TRANSACTION и т.д.). Какие именно удобства дает использование SDAC?
sniknik (2004-05-11 16:42:00) [4][34] :( не то. было про обновления БД а не НД. ;о)
sniknik (2004-05-11 16:39:00) [5]> Вот чего действительно нет в ADO компонентах - так это возможности прописать свой SQL-запрос для обновления БД (типа ADO сами знают что
> и как надо делать)
ADODataSet1.Properties['Resync Command'].Value:=
'SELECT Abonents.AbonentID AS A_AbonentID, Abonents.AbonentName, Calls.*
FROM Abonents INNER JOIN Calls ON Abonents.AbonentID = Calls.AbonentID
WHERE Calls.CallID = ?';
sniknik (2004-05-11 16:38:00) [6]а, ну это можно сделать через соеденение набора с ClientDataSet (кстати когда проверял SDAC компоненты, заметил что он так и работает как будто туда еше ClientDataSet добавили (не от мидас конечно, свой наверное))
или можно просто отсоеденить набор от конекта и добавлять и менять что хочеш и сколько хочеш, правда ApplyUpdates придется руками реализовывать, (последующее присоедение скорее всего ничего не даст).
а если нужна "ручная обработка" то тоже можно прописать Resync Command и оно будет обновлятся по этому правилу.
Курдль (2004-05-11 16:37:00) [7]Кто такой BatchUpdate? У меня такого нет!
KSergey (2004-05-11 16:26:00) [8]Стоп.
Что касается кэширования изменений - см. BatchUpdate
Вот чего действительно нет в ADO компонентах - так это возможности прописать свой SQL-запрос для обновления БД (типа ADO сами знают что и как надо делать)
Впрочем, спасибо nike (вроде?). Он рассказал как (Connection := nil - и вперед! Ну либо тот же BatchUpdate с "откатом" изменений, но отправкой их на сервер и перечитыванием. Тоже вариант)
Курдль (2004-05-11 16:17:00) [9]Ок.
Напр. у стандартного компонента TIBDataSet есть св-во OnUpdateRecord, куда прописывается соотв. функция. Она определяет действия, прописанные разработчиком, которые будут производиться при попытке фиксации кэшированно-измененной записи.
Т.е. при режиме кэшированных изменений можно весь день бодаться с набором данных (добавлять, редактировать, удалять записи), при этом сотни раз вызывать After/before Insert/Edit/Post.
Но только в конце дня вызвать ApplyUpdates - вот тогда и начнется "ручная обработка" фиксации изменений каждой записи.
sniknik (2004-05-11 16:10:00) [10]а! (3) onNewRecord ?
sniknik (2004-05-11 16:08:00) [11]я ее не знаю, (а ты не обьяснил) просто кинул название события, могу только догадыватся (нестандартными компонентами не пользуюсь, чаще всего, за редким исключением (куплено) это у нас запрещено).
попытка в догадке 2, onBefore/AfterInsert ?
Курдль (2004-05-11 15:51:00) [12]
> > TADODataSet нет onApplyRecord
> onBefore/AfterPost ?
А Вы разницу совсем не ощущаете? :(
sniknik (2004-05-11 15:49:00) [13]> TADODataSet нет onApplyRecord
onBefore/AfterPost ?
Курдль (2004-05-11 15:19:00) [14]
> А чем не угодили стандартные, Дельфи- ориентированные АДО
> компоненты, написаные Борландом, из дельфовой палитры компонент?
Да очень многим! Например, у TADODataSet нет onApplyRecord. Этого мало?
KSergey (2004-05-11 14:58:00) [15]> [21] SergSuper (11.05.04 11:01)
> Развитие DB Library был остановлено на версии 6.5 и хоть
> и сейчас можно посредством ей коннектиться к 2000-му, новых
> возможностй сервера использовать нельзя(например вы не получите
> через неё строку длинной больше 255 символов).
> (Кстати как это может быть, что бы описание билиотеки было
> общедоступно, а потом закрыто?)
По информации, которой козыряет борланд (в частности, могу опять сослаться на Орлика), DB Library вовсе не остановлена. И все она поддерживает.
Но доокументация по ее новым фичам отсутствует в общедоступной (MSDN) документации....
Danilka (2004-05-11 11:20:00) [16][22] Johnny Bombardir (11.05.04 11:18)
А чем не угодили стандартные, Дельфи- ориентированные АДО компоненты, написаные Борландом, из дельфовой палитры компонент?
Johnny Bombardir (2004-05-11 11:18:00) [17]Мне кажется, что использование "нестандартных", но зато на Delphi ориентированных компонент (гну линию SDAC), просто-напросто облегчает программисту жизнь. А это кое чего да стоит.
SergSuper (2004-05-11 11:01:00) [18]Развитие DB Library был остановлено на версии 6.5 и хоть и сейчас можно посредством ей коннектиться к 2000-му, новых возможностй сервера использовать нельзя(например вы не получите через неё строку длинной больше 255 символов).
(Кстати как это может быть, что бы описание билиотеки было общедоступно, а потом закрыто?)
Для версий 7.0(по-моему и 6.5) и позже DB Library вобщем-то необязательна и базовая документированная библиотека для неё - OLEDB. Именно OLEDB посылает запросы и разбирает TDS(Tabular data stream - поток данных от сервера, документация на который закрыта). Через OLEDB можно посылать запросы и последовательно получать значения полей таблиц. Для удобства работы с данными служит ADO, которая например заворачивает их в рекордсеты.
Что касается библиотек сторонних разработчиков...
А оно надо? Что даст использование нестандартных компонентов?
На мой взгляд для этого должна быть достаточно весткая причина(мне правда в голову такая не приходит)
sniknik (2004-05-11 08:29:00) [19]KSergey © (11.05.04 07:36) [19]
если бы зависело только от библиотеки, DB Library, то оно бы не рушилось когда насильно сервер закрываеш при коннекте. ну или хотябы (если считать что прямой доступ не к данным а к клиентской библиотеке) не выдавало бы EOleException : Connection failure. почему ошибка идет из COM обьекта? если он не используется? (ADO это и есть этот COM обьект, компоненты в дельфях обертка над ним) или DB Library это доступ к OLE DB драйверу? т.е. получаем другую обертку не стандартную, причем с ограниченными возможностями (зато настроенную полностью на этот единственный метод).
вот с тем что "зачем к нему доступ помимо ADO (MSSQL)" полностью согласен, и также думаю что другого просто нет. (даже те кто заявляет о "прямизне" его используют, не лутше ли тогда просто самим тоже его использовать? без посредников)
KSergey (2004-05-11 07:36:00) [20]> [17] sniknik © (10.05.04 16:41)
> перечитай [5]
> прямой доступ и без ADO(OLE DB) не работает!?
Я конечно не знаю, что хотели этим сказать создатели Zeos, но я склонен вот как рассуждать.
Есть MS'овская библиотека доступа - так называемая DB Library. Это официальная библиотека клиентского доступа к MS SQL. Т.к. протоколы доступа к собственно серверу не документированы, а существуют лишь хакнутые снифферами описания, то, соответственно, все, что идет мимо DB Library - есть хак со всеми вытекающими (в части стабильности, поддержки всех фич и т.д.).
Однако дока на DB Library перестала поставляться (на сколько я знаю), последнее описание ее было лишь для версии сервера 6.5.
Как оказалось, никуда это баблиотека не делась (заявление С.Орлика в кулуарах конференции). Просто ее описание не стало общедоступным, лишь для каких-то партнеров MS.
А потому очевидно, что все нормальные компоненты работают именно через эту библиотеку (в частности, могу это утверждать про давно почившую SQL Query).
На основании вышесказанного рискну сделать предположение, что все требования по поводу наличия каких-то библиотек подразумевают наличие установленной соотвествующей версии MDAC, которая, увы, не делима (официально) и сожержит, кроме всего прочего, нужную версию DB Library.
Последний абзац - лишь мое мнение. Скромное.
| |
Страницы: 