Вопрос на общую тему...Стандарты

[ANDLL]

Вопрос на общую тему... Существует ли какой-то совсем единый интерфейс доступа к базам данных. Ну типа, DAO это к MSAccess, ADO вроде общий, но там черт ногу сломит, ODBC - это API(фи-фи), OLE DB не пробовал, но как-то не сильно про него слышно... Мне нужен общий способ подключиться к базе данных, пусть она будет расположена на локальном компьютере, или в сети. Драйвер базы данных известен. Путь к ней тоже. А вот как ее открыть и считать данные?

Не сочтите за труд...

[GSerg]

Не сочтём...
Упаднические настроения задушить и ADO изучать.

[ANDLL]

А это точно, и для сети работает? А то книгу куплю, а там первая строчка ADO-это ... для локальных DB.
И если уж на счет книг - может чего подскажете?

[Dzhon]

ADO работает и локально, и в локальной сети и удаленно... и сейчас без ADO никуда...СМЕЛО ЗА КНИГОЙ
авт. Роджер Дженнингс "Руководство разработчика баз данных на Visual Basic 6" 2001 г. Извини издателя не помню. Но книга очень неплохая (может кто другого мнения конечно ?!

[Leon_]

Не разделяю ваш оптимизм по поводу ADO..
Ну да, "сейчас без ADO никуда". Сейчас. Вчера было DAO, сегодня ADO, а завтра родится ODA или еще какой-нибудь AOD -- и что? Снова всем в магазин за книгами!
Это как с телефонами: "Все уже купили цветные телефоны? Точно все? Так, а теперь срочно за камерофонами. Камерофоны -- это теперь рулез". Ирония понятна?
Использовать нужно ту технологию, которой сейчас уверенно владеешь и которая подходит для решения задачи. А какой аббревиатурой это будет обзываться -- не так важно.

[tyomitch]

Кстати, раз уж затронули тему.
Кто-нибудь мне может ответить, в чём "идеологическая" разница между ADO и DAO и почему ADO - это типа рулез, а DAO - ацтой полный?
Почему все вдруг бросили DAO и перешли на ADO? Есть ли этому другая причина, кроме высококачественного маркетинга от МС?

[Rainbow]

Ну, по мне так объектная модель на порядок удобнее. Хотя, честно скажу, на DAO ничего серьезного не писала. Но так - на первый взгляд в ADO понятнее, что к чему. Во-вторых, в ADO есть такие пределсти как асинхронные запросы, ивенты всякие от объектов ловить можно.

еще загляни вот в этот топик: http://bbs.vbstreets.ru/viewtopic.php?t=5119
мы там с Алибеком пытались эту тему развить, но очень быстро согласились на ADO

[alibek]

Для небольших проектов с монопольным доступом к БД DAO на порядок удобнее, чем ADO. Говорю как человек, который первоначально работал именно под DAO
Конечно в ADO есть много фишек, которых впоследствии очень не хватает в DAO (это, в первую очередь, события и асинхронность), но все решаемо.
ODBC хорош только универсализмом. Помоему это как раз и есть тот стандарт, который ты ищешь, но его использовать неудобно.
Так что лучше ADO - для него есть очень много провайдеров, так что его вполне можно использовать в качестве универсального метода.

[Andrey Fedorov]

Для небольших проектов с монопольным доступом к БД DAO на порядок удобнее, чем ADO.

Но лучше пользовать что-то одно, точнее ADO

Вообще у меня был реальный случай когда DAO сработало лучше.
А именно - база у заказчика была в MDB-шке и содержала табличку со 150 полями. Дык вот - ADO эту табличку (даже пустую!) открывало крайне медленно (кто хочет попробуйте). Пришлось тот проект делать на DAO...

Ну а в остальном - ADO лучше и удобней на порядок.

ADO вроде общий, но там черт ногу сломит

Да чем он так тебя пугает? Он простой до ужаса - по крайней мере ничуть не сложней чем DAO. И удобней.

ODBC - это API(фи-фи), OLE DB не пробовал, но как-то не сильно про него слышно...

Ты путаешься: используя ADO можно подключиться к базе через ODBC или OLEDB

Мне нужен общий способ подключиться к базе данных, пусть она будет расположена на локальном компьютере, или в сети. Драйвер базы данных известен. Путь к ней тоже. А вот как ее открыть и считать данные?

Тут одинаково - хоть в DAO или ADO. Просто укажешь путь к своей MDB-шке - никакой разницы на каком диске она находится...

[ANDLL]

Просто укажешь путь к своей MDB-шке

Если есть mdbшка. Как я понимаю, DAO нельзя использовать для подключениям к базам dBase/XLS/MySQL.

А так все спасибо! Из топика узнал много интересного. Буду покупать книгу!

[alibek]

Можно. Можно использовать все, что есть в ODBC. Просто для доступа к MDB DAO позволяет использовать Jet, а при доступе через ODBC оно лишается многих своих преимуществ.

[Andrey Fedorov]

Если есть mdbшка. Как я понимаю, DAO нельзя использовать для подключениям к базам dBase/XLS/MySQL.

Можно - через ODBC.
Но лучше все-же пользовать ADO.

[alibek]

Это уж тебе виднее
Но я свободно использовал DBF-ки в работе через DAO.

[tyomitch]

Andrey, чем всё-таки ADO принципиально лучше DAO? С БД я только-только разбираюсь, поэтому вместо мудрёных аббревиатур (ODBC, DBF, etc.) можешь просто объяснить, что можно в одном и нельзя в другом?
Или же по возможностям они всё-таки равны, и выбор между ними - дело личных предпочтений?

[Andrey Fedorov]

Andrey, чем всё-таки ADO принципиально лучше DAO?

1. DAO уже несколько лет не рекомендуется к применению. К советам MS все-же стоит прислушиваться, особенно начинающим.
2. Объектная модель ADO лучше и удобней. Значительно.
3. Многого в DAO просто по определению не сделаешь
К примеру я могу создать Recordset не связанный ни с чем и нормально работать с ним. В общем, подобных мелочей много, но об них начинаешь вспоминать если приходится что-то править в старой программе с DAO - тогда начинаешь материться... Но, к счастью такие мне уже давно не попадались...

[alibek]

tyomitch, в принципе, все сказала Rainbow, события и асинхронность.
Лично мне DAO очень нравиться тем, что в нем нормально поддерживаются индексы (для метода .Seek). В ADO их тоже можно использовать, но там это не столь явно.

[tyomitch]

1) Советы МС ориентированы на то, чтобы им зашибить побольше бабок, а не мне. Поэтому я отношусь к ним с определённым недоверием, как и к любой рекламе.
2) "Лучше и удобнее" - в чём это выражается? У меня с обеими очень поверхностное знакомство - грубо говоря, пробежался Object Browser-ом. "Идеологических" различий (т.е. не таких, что этот метод переименован так-то, а то свойство перенесено в другой объект) не нашёл. Они есть?
Или же "лучше и удобнее" - это и есть дело личного предпочтения, как я изначально спрашивал?
Вон, Винда при установке каждый раз неизменно сообщает, что стала лучше и удобнее. Действительно, стала; но одно только предложение "она стала лучше и удобнее" нисколько смысла не несёт.
3) Вот именно про такие мелочи хотелось бы услышать в первую очередь. Есть ли обратные мелочи - что какие-то фичи DAO не попали в ADO?
И зачем, кстати, могут понадобиться не связанные ни с чем рекордсеты?

[tyomitch]

alibek, я человек тёмный, что такое "асинхронность" применительно к ADO/DAO?

[Andrey Fedorov]

1) Советы МС ориентированы на то, чтобы им зашибить побольше бабок, а не мне. Поэтому я отношусь к ним с определённым недоверием, как и к любой рекламе.

Мда... Я представляю сколько бабок положит в карман Гейтс, если ты вдруг начнешь вместо DAO пользовать ADO...

"Идеологических" различий (т.е. не таких, что этот метод переименован так-то, а то свойство перенесено в другой объект) не нашёл. Они есть?

Есть. Но нет желания перерывать MSDN в поисках их.

Но если хочешь - поработай годика три с DAO, и потом, переходя на ADO, ты и выяснишь все различия...

[alibek]

tyomitch, ты можешь запустить "тяжелый" запрос асинхронно, затем твоя программа будет заниматься своими делами, а когда запрос отработает, слить информацию из рекордсета.
При синхронном запросе твоя программа будет висеть, пока запрос не отработает.
В DAO есть возможность делать асинхронные запросы, когда используется ODBC Workspace, только корявое оно там. И событий нет, т.е. факт отработки запроса надо делать в таймере.
В ADO, во-первых, асинхронность поддерживается не только для запросов, но и для подключений, а во-вторых, можно использовать события, которые сгенеряться по завершению запроса.

Если хочется поискать важные различия, поищи все топики за авторством Rainbow -- она давала ссылки, но я не помню в каком разделе.

[Andrey Fedorov]

alibek

Лично мне DAO очень нравиться тем, что в нем нормально поддерживаются индексы (для метода .Seek). В ADO их тоже можно использовать, но там это не столь явно.

Чего в ADO неявного? Вроде все достаточно ясно в Help-е прописано.

Но у в ADO, кроме того, можно еще индексировать любое поле клиентского Recordset-a. И это будет использовано для Find/Filter.
А это гораздо удобней в большинстве случаев.

[alibek]

Andrey Fedorov, в том то и дело, что используется неявно. Т.е. Find будет работать в любом случае, хоть есть у тебя индексы, хоть нет.
А в DAO ты сам задаешь, делать поиск/сортировку используя индексы, или не использовать их.
Вообщем, субъективно это, нравится мне, когда я сам все могу задать, пусть это и гемморойно чуть.

А реализация .Seek в DAO сделана удобнее (единственное, в ADO есть не только основные условия, но и "первый равный", "последний равный" и пр.).

[Andrey Fedorov]

И зачем, кстати, могут понадобиться не связанные ни с чем рекордсеты?

Достаточно удобная вещь, кстати.

К примеру делал сегодня - получаю результат двух вьюшек на сервере. По довольно сложному алгоритму на клиенте делаю из них один Recordset и использую его для отчета.
Все получилось быстро и просто.

А как другой вариант - мне пришлось бы писать хранимку на сервере, при том что на Transact-SQL сделать то-же самое значительно трудней...

[alibek]

Andrey Fedorov, а поделиться, как ты это сделал? Или ты имеешь ввиду, что делается Execute, а потом отвязывается от коннекции?

[tyomitch]

Но если хочешь - поработай годика три с DAO, и потом, переходя на ADO, ты и выяснишь все различия...

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

[gaidar]

Немогу не заорать во всю глотку, читая топик "ADO.NET Rulezzz Forever"!!!!! , вот и не сдержался.

Советую знать и владеть ADO/VB6 и ADO.NET/VB.NET - в обязательном порядке. Только потому, что это _современные стандартные_ технологии (про второй это уже правда).

[Andrey Fedorov]

alibek

а поделиться, как ты это сделал? Или ты имеешь ввиду, что делается Execute, а потом отвязывается от коннекции?

Как вариант можно и это делать (в определенных случаях). Или открывать с BatchOptimistic.

Но я имел в виду следующий случай:

Dim r As New ADODB.Recordset

r.Fields.Append ...
r.Fields.Append ...
r.Open

В результате имеем нужный нам Recordset без создания
временных таблиц в базе.

[ANDLL]

К вопросу функциональности:
В DAO что бы узнать структуру DB есть Database.tables, а в ADO ничего подобного нету. Может, нужен специальный SQL-запрос?

[Ennor]

Нет, нужен ADOX, хотя лично я предпочитаю запросы наподобие следующего:

Код: Выделить всё

select id, name
from sysobjects
where xtype = 'U'
  and status >= 0


Оно как-то привычнее, да и непосредственно в серверном коде с этим работать можно...

[ANDLL]

Не работает. а если заменить sysobjects на msysobjects то пишет, что нет прав доступа. Если как у тебя, то пишет - таблица не найдена.
А как работать с ADOX?