Здравствуйте The Lex, Вы писали:

TL>Здравствуйте Dale, Вы писали:

D>>Здравствуйте The Lex, Вы писали:

D>>Мужики, а что вы на ODBC зациклились? Эту технологию Микрософт перестал развивать, а значит, через пару лет она начнет вымирать понемногу. Сейчас вполне путевая вещь — ADO, она в отличие от ODBC оперирует не блоками данных, а объектами ActiveX. В ней заложена масса приятных мелочей, вроде иерархических наборов команд и т.п.

По пунктам:

TL>Ну и? Первое: для любой мало-мальски серъезной СУБД имеется ODBC-драйвер.

Абсолютно верно, для своего времени ODBC была самой продвинутой технологией доступа к данным. По сути, единственная альтернатива библиотекам доступа, которые каждый производитель СУБД поставлял со своим детищем и которые были уникальны для каждой архитектуры. Вот только даже самые крутые технологии со временем устаревают, ничего тут не попишешь... Тем более что OLE/COM/COM+/DCOM/ActiveX/... , как бы их дядя Билли ни нахваливал, по-настоящему работоспособны и надежны стали совсем недавно, раньше проблемно было на них серьезные вещи делать.

TL>Второе: как ни странно, ADO тоже позволяет соеденяться через ODBC.

Нисколько не странно. Странно было бы, кабы наоборот (см. предыдущий пункт). Имея надежную, хорошо отлаженную и, главное, универсальную технологию доступа к данным, которая к тому же поддержана всеми серьезными производителями реляционных СУБД, глупо было бы не сделать туда лазейку. А лазейка эта — в трансляции ADO-шных операций над данными в ODBC и обратное преобразование результатов. Тем самым выигрывается время, пока поставщики сделают полноценные драйверы с поддержкой OLE DB. Сделают — возрастет эффективность, но пока и так работает.

TL>Третье: если уж на то пошло, то ADO — это надстройка над OLE DB...

Опять же никто не спорит, оно и в самом деле на то пошло. OLE DB — _низкоуровневая_ спецификация для интерфейса с сервером БД, а ADO оперирует с объектами _высокого_ уровня, удобными для прикладных программистов и прячущими от них довольно сложные и малоинтересные подробности интерфейса OLE DB. Хотя это на любителя, можно писать прямо для OLE DB. Пишут ведь люди на ассемблере... Хотя одни — по необходимости, другие — из кокетства, крутизну показать. Здесь ситуация примерно такая же.

TL>А как можно решить поставленную задачу на ADO?

Теперь от теоретических мудрствований — к конкретному делу. Насколько я помню, _поставленная задача_ — это просмотр первой таблицы, одним из полей которой является уникальный ключ, и выборка соответствующих записей из второй таблицы, которые ссылаются на этот ключ в качестве "foreign key"?
Если я правильно понял, в ADO такая операция делается на раз. Точнее, за несколько раз:)
1. Создать объект Connection
2. ---"--- два объекта Command (для выборки из первой и второй таблиц соответственно)
3. Указать первый Command в качестве родительского для второго
4. Выполнить метод Execute для первого Command
Это все! При перемещении курсора по первому набору записей второй модифицируется автоматически, для этого иерархия команд и придумана. По-моему, проще не бывает.