2 Crip

10:42
Ваш пример вообще в VFP не будет работать в силу ограниченности синтаксиса SQL.

10:30
.Все могут ошибаться. У VFP свой движок при работе с DBF, по сравнению с которым MS Jet 4.0 отдыхает, хотя он кстати тоже не так уж плох в части доступа к mdb

Не могу понять логики. :) Не объяснишь?
Так ограниченный SQL у VFP или все-таки он лучше, чем MS Jet?
Приведенный мною запрос MS Jet жует и причмокивает, да еще и гораздо сложнее справится, а вот VFP давится... жаль.

Сама MS двигает Jet как самый быстрый движок для доступа к файловым базам. Причем, не только к MDB - список довольно большой. Не помню упоминания от MS о том, что VFP - самый быстрый движок. Только от третьих сторон (что, согласитесь любобытно, особенно после приведения "авторитетных" ссылок, утверждающих, что OLE DB базируется на ODBC ).

Дурацкий спор насчет OLE DB. Связка с ODBC может осуществлятся из OLE DB при наличии соотв. OLE DB провайдера, т.е. соотв. COM-объекта в системе, который всего-навсего один из многих OLE DB провайдеров, которые могут быть установлены в системе. Если убрать один этот несчастный провайдер, то мы у нас остануться только "родные" OLE DB провайдеры для источников данных, которые, кстати, уже существуют практически подо все распространенные базы, начиная от ORACLE (несколько вариантов от разных производителей) и заканчивая MySQL (тоже несколько вариантов) и даже Postgre SQL.

Кстати, MS посталяет OLE DB провайдер для VFP баз, которому абсолютно фиолетово - есть в системе ODBC или нет.

2 ErMak
Рассмотрим OLE DB. Технология OLE DB построена на ODBC и расширяет ее до компонентной архитектуры, которая обеспечивает высокоуровневый интерфейс доступа к данным. Эта архитектура предоставляет постоянный доступ к SQL-данным, не SQL-данным и неструктурированным источникам данных по локальным сетям и Internet.

Пример неграмотного перевода, который вводит в заблуждение. В оригинале могло быть based (или еще как-нибудь), что в данном контексте скорее означает выросла-из , взяла за основу и т.д.
Это все-лишь значит, что OLE DB - дальнейшее развитие идей, заложенных в ODBC (но ни в коем случае не использование программного кода или ODBC библиотек).

------
2 All
ну да, флеймить прикольно, да еще и познавательно.
Немного непонятна, все же, позиция привеженцев VFP. То, что кто-то не знает каких-то подробностей относительно этой системы, ставится чуть-ли не в вину. :) Это веселит. Тем более, что большинство из них демонстрирует наличие знаний ТОЛЬКО по VFP.
Все же, пользу от обмена информацией никто отрицать не станет.
Так что, даешь технический филиал ПТ!

сходил, по ссылке.

млять, ну каша-кашей.

ADO->OLE DB->ODBC->API SQL;
Причем как видно из схемы ADO является в свою очердь интерфейсом к OLE DB, который в свою очередь является интрефейсом к ODBC. А почему OLE DB нельзя вызывать напрямую, минуя ADO ? Все просто - OlE DB не имеет COM-интерфейса.
На самом деле ODBC просто скрыт оберткой OLE DB.
Вообще ни в какие ворота не лезет.
Молодой человек. Если есть интерес к OLEDB, то надо читать не VB 6.0 для начинающих, а просто спецификацию по OLEDB.
Ну такой фигни автор той книги напорол...

Берем VC, создаем проект, создаем новый COM-объект - OLE DB провайдер. САМИ реализуем все OLE DB COM-интерфейсы. САМИ. РУЧКАМИ. Например по работе со своим структурированным файлом. (я такое уже дважды делал). И получили очередного OLE DB провайдера. Где тут ODBC???


Все просто - OlE DB не имеет COM-интерфейса.
COM объект не имеет COM-интерфейса???
Мой Jet переплюнули!

Да, одна и та же фирма разработала и ODBC и OLE DB, но если они и связаны, то только через несчастный OLE DB for ODBC провайдер, которым обычно никто не пользуется, потому как это тупо - ставить лишнюю прослойку между ODBC источником и собой в виде OLE DB посредника. Все пользуют родные OLE DB дрова под конкретные источники.

2 YuriWhite
И после этого будем говорить что OLEDB не базируется на ODBC :)
Что мы вкладываем в понятие "базируется"? Использует или является продолжением идеи?
Не использует. Является логичным продолжением идеи.

Если в ODBC мы работаем с хендлами, то в OLEDB - с объектами. Намного удобней, логичней и современней.
Кто-нибудь тут именно с ODBC работал? Не с DAO и VFP, где все высокоуровневое, а именно с ODBC? А потом, изрядно на%бавшись, попробовали бы OLEDB. Все споры прекратились бы моментом.

ADO - вообще отдельная песня. Это всего-навсего высокоуровневый интерфейс над низкоуровневым OLEDB. (см. список имплементаций для OLE DB Session объекта - не очень удобно напрямую юзать, правда очень быстро )

А почему OLE DB нельзя вызывать напрямую, минуя ADO ?

Потому что не разрешено! Можно, но не всем. На VB - нельзя.

Итоги:
ODBC - гетерогенный способ доступа к реляционным данным;
OLE DB - гетерогенный способ доступа к гетерогенным данным,
причем, доступ к реляционным данным происходит через ODBC;
ADO - программная модель доступа к данным через OLE DB;

2-й пункт некорректен. Я даже знаю откуда он:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag02/html/TheEvolutionofData-AccessTechnologies.asp
(In fact, for access to SQL-based data, OLE DB still uses ODBC because it's the most optimized architecture for working with SQL.)

Теперь ясно, отчего такие споры. Явно устаревшие данные на сайте Microsoft? Да еще и от непонятного автора - Copyright © 2002 Penton Media, Inc. All rights reserved.
Подозреваю, что на момент выхода, первые OLEDB дрова были просто обертками над ODBC. Смотрим что сейчас:
1. Открываю Control Panel -> ODBC -> Start Trace.
2. Открываю SQL Enterprise Manager (использует старую DB LIB для MS SQL, построенную на ODBC )
3. Пара кликов по дереву слева, и файл трассировки стал размером более 4M.
4. Открываем VS.NET -> Server Explorer.
5. Создаем OLEDB коннекшн к тому же SQL серваку.
6. Излазил все на серваке, пооткрывал таблицы, поредактировал, сохранил и т.д.
7. файл ODBC трассировки - не шелохнулся.

Каждый может повторить эксперимент.