Компоненты прямого доступа к MSSQL

← →
Я Ламер (2004-05-09 00:30) [0]

Здравствуйте All.
Интересует сабж. Как правило работаю с MSSQL сервером через ADO, недавно узнал, что есть компоненты прямого доступа к MSSQL. Так вот интересует какие преимущества/недостатки дает такой подход, и где можно найти такие компоненты. Спасибо.

← →
KSergey © (2004-05-10 09:48) [1]

Я, возможно, давно не интересовался состоянием дел, но, по-моему, такие компоненты были для MSSQL 6.5 - 7
Далее их вытеснила ADO, и, соответственно, они часто не поддерживают все фичи последних версий (возвращение множественных RecordSet, например).

В свое время их авторы утверждали, что они работают быстрее.

← →
Anatoly Podgoretsky © (2004-05-10 10:23) [2]

А что значит прямой доступ?

← →
Nikolay M. © (2004-05-10 10:54) [3]

В последних версиях Zeos Library были. Вплотную с ними не работал, запустил, приконнектился, что-то заселектил и отложил в сторону.

← →
sniknik © (2004-05-10 12:09) [4]

они были не "прямого доступа".
для начала определение, как я его понимаю, такие компоненты должны понимать базу безо всего, оперируя только файлом базы (mdf) напрямую, иначе какие же они "прямые"?
так вот запрос и получение данных на компонентах от Zeos Library - их dbExpress, "сваливался" на середине после принудительной остановки сервера MSSQL. т.е. какие же они "прямые"?

← →
sniknik © (2004-05-10 12:29) [5]

решил посмотреть,ну типа а может я ошибаюсь?
вот с их сайта описание компонент в 2х разных местах (практически на одной странице, видно без листаний)

1

Following the main features of our dbExpress drivers:

* Direct access to data
* High performance
* Supports latest versions of servers
* All data types support
* Ability of monitoring query execution
* Extended options for advanced behaviour
* Source code available
* Free support for registered users
* Licensed per a developer without royalty fee
2

bExpress driver for MS SQL Server (DbxSda) provides access to MS SQL Server database. It works using high performance Microsoft OLE DB technologies. DbxSda supports MS SQL Server 2000 and MS SQL Server 7. The driver requires OLE DB installed on workstation.
(поверьте он еще и установленного MSSQL сервера требует на сервере ;о)) прямые, как же. или может у них свое определение "прямого доступа"?

← →
Курдль © (2004-05-10 12:31) [6]

> для начала определение, как я его понимаю, такие компоненты
> должны понимать базу безо всего, оперируя только файлом
> базы (mdf) напрямую, иначе какие же они "прямые"?

Ну да! Подменяя "клиента" и "сервера" в одном лице! Берешь, это так значицца, компонениы прямого доступа к "Ораклу" DOA, науськиваешь их на ораклевую базу (сотня разных файлов) и работай себе - в ус не дуй! :)

← →
sniknik © (2004-05-10 12:37) [7]

> Подменяя "клиента" и "сервера" в одном лице!
именно, вот IB/Yaffil/Farebird embeded, это прямого доступа (правда не компонент, dll) она сама "в одно рыло" с файлом базы и работает не привлекая никого в посредники.

← →
Курдль © (2004-05-10 12:40) [8]

Вы чувствуете разницу между однопользовательским Yaffil-oм и системой клиент - сервер?

← →
Johnny Bombardir (2004-05-10 12:50) [9]

Народ, что имеете против компонент SDAC (SQL Server Data Access Components for Delphi and C++ Builder)

http://crlab.com/sdac/

Эта фирма вообще на подобных компонентах специализируется. ODAC, например

← →
sniknik © (2004-05-10 12:52) [10]

а то, и даже есть "сверх чуство", что те кто "напрямую" работают с сервером базы/клиентом сервера базы/другим посредником, а заявляют что имеют прямой доступ к данным (Direct access to data) не совсем правы (говоря очень мягко).

← →
Курдль © (2004-05-10 12:55) [11]

> sniknik © (10.05.04 12:52) [10]

Да подумайте же Вы логически! Ну пусть даже клиента удастся подменить dll-ной (что в принципе возможно), но что же делать с сервером?

← →
sniknik © (2004-05-10 13:02) [12]

Курдль © (10.05.04 12:55) [11]
не против логики. против того чтобы называли веши не своими именами.
(если смотреть на схему доступа там так и есть. но тогда это не прямой доступ к данным (или хотя бы пусть свой сервер сделают, быстрее/так еще можно сказать "мы (не компонента комплекс) используем прямой доступ"))

> Народ, что имеете против компонент SDAC
я, ничего. не пользуюсь и ничего не имею. раз только пришлось проверять (сравнивал по просьбе с ADO, типа намного быстрее), выяснил что реализуется всего один вариант настройки ADO компонент без возможности изменений.
т.е. ADO на подобную работу настроить можно (~те же скорости то же поведение), а вот наоборот этими компонентами реализовать другой вариант ADO нельзя (у меня не получилось/также как у того кто спрашивал).

← →
sniknik © (2004-05-10 13:04) [13]

> Да подумайте же Вы логически!
а почему это я должен думать как оправдать тех кто меня обманывает?

← →
Sergey Masloff (2004-05-10 14:42) [14]

Курдль © (10.05.04 12:31) [6]
>Ну да! Подменяя "клиента" и "сервера" в одном лице! Берешь, это >так значицца, компонениы прямого доступа к "Ораклу" DOA, >науськиваешь их на ораклевую базу (сотня разных файлов) и >работай себе - в ус не дуй! :)
Нет, ты не понимаешь. Прямой доступ это работа с КЛИЕНТСКОЙ библиотекой (ее API) без промежуточных прослоек (BDE, dbExpress, ADO etc.)
Кстати DOA без установики клиента ORACLE работать действительно не может, а вот ODAC- может (естественно с оговорками). Что вещб вообще-то очень классная (я правда ПОКА этот вопрос недостаточно исследовал).

← →
Sergey Masloff (2004-05-10 14:43) [15]

Кстати с YA personal это так и есть - там просто сервер и клиент в одну библиотеку объединили.

← →
KSergey © (2004-05-10 15:51) [16]

> [10] sniknik © (10.05.04 12:52)

А разве data == файлы???
Впрочем, [14] Sergey Masloff (10.05.04 14:42) уже все сказал.

← →
sniknik © (2004-05-10 16:41) [17]

KSergey © (10.05.04 15:51) [16]
знаеш, именно чтото вроде этого и предполагал (и предполагаю до сих пор).
data == файлы/файл/любое хранилище данных пусть даже на магнитных лентах/стримерах/т.д. т.е. именно данные. кстати заранее ([4]) во избежание разных кривотолков дал свое определение.
определение из [14] > Прямой доступ это работа с КЛИЕНТСКОЙ библиотекой (ее API)
близко к моему, не совсем то, конечно, с послаблением, но и этого компоненты "прямого" доступа (один из них Zeos Library) не выдерживают.
перечитай [5]
прямой доступ и без ADO(OLE DB) не работает!?
[14] next > без промежуточных прослоек (BDE, dbExpress, ADO etc.)

← →
Sergey Masloff (2004-05-10 18:15) [18]

sniknik © (10.05.04 16:41) [17]
>прямой доступ и без ADO(OLE DB) не работает!?
Ну если говорить про MS SQL то я вообще не понимаю зачем к нему доступ помимо ADO так как ADO специально разрабатывался для эффективного доступа к MSSQL, не говоря уж об ADO.NET так что смысл в компонентах прямого доступа к MS SQL вообще минимален (если вообще есть)

← →
KSergey © (2004-05-11 07:36) [19]

> [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.

Последний абзац - лишь мое мнение. Скромное.

← →
sniknik © (2004-05-11 08:29) [20]

KSergey © (11.05.04 07:36) [19]
если бы зависело только от библиотеки, DB Library, то оно бы не рушилось когда насильно сервер закрываеш при коннекте. ну или хотябы (если считать что прямой доступ не к данным а к клиентской библиотеке) не выдавало бы EOleException : Connection failure. почему ошибка идет из COM обьекта? если он не используется? (ADO это и есть этот COM обьект, компоненты в дельфях обертка над ним) или DB Library это доступ к OLE DB драйверу? т.е. получаем другую обертку не стандартную, причем с ограниченными возможностями (зато настроенную полностью на этот единственный метод).
вот с тем что "зачем к нему доступ помимо ADO (MSSQL)" полностью согласен, и также думаю что другого просто нет. (даже те кто заявляет о "прямизне" его используют, не лутше ли тогда просто самим тоже его использовать? без посредников)

← →
SergSuper (2004-05-11 11:01) [21]

Развитие DB Library был остановлено на версии 6.5 и хоть и сейчас можно посредством ей коннектиться к 2000-му, новых возможностй сервера использовать нельзя(например вы не получите через неё строку длинной больше 255 символов).
(Кстати как это может быть, что бы описание билиотеки было общедоступно, а потом закрыто?)
Для версий 7.0(по-моему и 6.5) и позже DB Library вобщем-то необязательна и базовая документированная библиотека для неё - OLEDB. Именно OLEDB посылает запросы и разбирает TDS(Tabular data stream - поток данных от сервера, документация на который закрыта). Через OLEDB можно посылать запросы и последовательно получать значения полей таблиц. Для удобства работы с данными служит ADO, которая например заворачивает их в рекордсеты.

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

← →
Johnny Bombardir (2004-05-11 11:18) [22]

Мне кажется, что использование "нестандартных", но зато на Delphi ориентированных компонент (гну линию SDAC), просто-напросто облегчает программисту жизнь. А это кое чего да стоит.

← →
Danilka © (2004-05-11 11:20) [23]

[22] Johnny Bombardir (11.05.04 11:18)
А чем не угодили стандартные, Дельфи- ориентированные АДО компоненты, написаные Борландом, из дельфовой палитры компонент?

← →
KSergey © (2004-05-11 14:58) [24]

> [21] SergSuper (11.05.04 11:01)
> Развитие DB Library был остановлено на версии 6.5 и хоть
> и сейчас можно посредством ей коннектиться к 2000-му, новых
> возможностй сервера использовать нельзя(например вы не получите
> через неё строку длинной больше 255 символов).
> (Кстати как это может быть, что бы описание билиотеки было
> общедоступно, а потом закрыто?)

По информации, которой козыряет борланд (в частности, могу опять сослаться на Орлика), DB Library вовсе не остановлена. И все она поддерживает.
Но доокументация по ее новым фичам отсутствует в общедоступной (MSDN) документации....

← →
Курдль © (2004-05-11 15:19) [25]

> А чем не угодили стандартные, Дельфи- ориентированные АДО
> компоненты, написаные Борландом, из дельфовой палитры компонент?

Да очень многим! Например, у TADODataSet нет onApplyRecord. Этого мало?

← →
sniknik © (2004-05-11 15:49) [26]

> TADODataSet нет onApplyRecord
onBefore/AfterPost ?

> > TADODataSet нет onApplyRecord
> onBefore/AfterPost ?

А Вы разницу совсем не ощущаете? :(

я ее не знаю, (а ты не обьяснил) просто кинул название события, могу только догадыватся (нестандартными компонентами не пользуюсь, чаще всего, за редким исключением (куплено) это у нас запрещено).

попытка в догадке 2, onBefore/AfterInsert ?

а! (3) onNewRecord ?

Ок.
Напр. у стандартного компонента TIBDataSet есть св-во OnUpdateRecord, куда прописывается соотв. функция. Она определяет действия, прописанные разработчиком, которые будут производиться при попытке фиксации кэшированно-измененной записи.
Т.е. при режиме кэшированных изменений можно весь день бодаться с набором данных (добавлять, редактировать, удалять записи), при этом сотни раз вызывать After/before Insert/Edit/Post.
Но только в конце дня вызвать ApplyUpdates - вот тогда и начнется "ручная обработка" фиксации изменений каждой записи.

Стоп.
Что касается кэширования изменений - см. BatchUpdate

Вот чего действительно нет в ADO компонентах - так это возможности прописать свой SQL-запрос для обновления БД (типа ADO сами знают что и как надо делать)
Впрочем, спасибо nike (вроде?). Он рассказал как (Connection := nil - и вперед! Ну либо тот же BatchUpdate с "откатом" изменений, но отправкой их на сервер и перечитыванием. Тоже вариант)

Кто такой BatchUpdate? У меня такого нет!

а, ну это можно сделать через соеденение набора с ClientDataSet (кстати когда проверял SDAC компоненты, заметил что он так и работает как будто туда еше ClientDataSet добавили (не от мидас конечно, свой наверное))
или можно просто отсоеденить набор от конекта и добавлять и менять что хочеш и сколько хочеш, правда ApplyUpdates придется руками реализовывать, (последующее присоедение скорее всего ничего не даст).
а если нужна "ручная обработка" то тоже можно прописать Resync Command и оно будет обновлятся по этому правилу.

> Вот чего действительно нет в 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 = ?";

[34] :( не то. было про обновления БД а не НД. ;о)

← →
Я Ламер (2004-05-11 17:24) [36]

Очень как-то много слов и мало толку. Все "проблемы", про которые здесь говорили не являются таковыми. С помощью ADO можно реализовать как свой SQL запрос на обновление, так и
обработку кешированых изменений. Меня интересуют действительно какие преимущества дает SDAC. На сколько процентов быстрее я могу загрузить данные из MSSQL, по сравнению с обычным Query и ClientDataSet-ом. Могу ли я через эти компоненты использовать именно особенности MSSQL (BULK INSERT, DISTRIBUTED TRANSACTION и т.д.). Какие именно удобства дает использование SDAC?

← →
SergSuper (2004-05-11 21:29) [37]

2 KSergey

> По информации, которой козыряет борланд (в частности, могу
> опять сослаться на Орлика), DB Library вовсе не остановлена.
> И все она поддерживает

Что - Борланд разрабатывает DB Library? Ну-ну
Ну надо же понимать что DB Library - это прошлый век, они разрабатывались еще Сайбейзом, там все функции основаны на получении неких хенделов и работы через них. А в OLEDB вызовы осуществляются как можно догадаться вызовом функций соответсвующих интерфейсов.

Что касается того стоит ли использовать сторонние компоненты... В принципе основное время тратится на обработку сервером и гнаться за милисекундами тут смысла особого нет (за исключением задач массовой заливки данных на сервер). Что касается всяких удобств - наверное можно найти(или самому сделать) компоненты которые написаны не вместо, а поверх АДО и обеспечивают дополнительный функционал(а он вам кстати нужен?).
Мой принцип - как можно больше придерживаться стандартных решений. Хотя бы потому что гораздо больше людей использует ADO чем SDAC. Я последнего не знаю и не исключаю что он в чем то лучше, но пользоваться всё равно не советую :)

> [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 и т.п. "переходные" технологии.

Так что говорить о существенном приросте точно не приходится, тем более, что, как верно замечено, основное время - это выполнение запроса сервером...

Компоненты прямого доступа к MSSQL Найти похожие ветки