Хм.
Это, судя по всему, VB. Не могу сказать какие тонкости в работе с АДО из ВБ, но в приведенном тобой коде нет метода Seek. Какой тип у переменной MyTable? Подозреваю, что он как-то связан с _Recordset. Значит можно вызвать Seek как-нибудь так: MyTable.Reordset.Seek
Напомню, что Seek ищет по текущему индексу. Если эта таблица SQL-ная, то это не мешает ее открыть по первичному ключу, индексу, или вообще в том порядке как тебе нравится. И нет принципиальных проблем сформировать новый запрос, который вернет искомую запись. Другое дело, что АДО не поддерживает этот метод в других драйверах, кроме упомянутых в моем постинге.
А вообще интересно, зачем тебе этот Seek? Чем Locate не подходит?

Несовсем так, ADO Recordset определается при открытии. Точнее как он будет открыт. Если так, то можно делать Seek
  Set CurWork = DBEngine.Workspaces(0)
  Set FindDb = CurWork.OpenDatabase("BaseName", False, Not RW)
  Set MyTable = FindDb.OpenRecordset("FindTable", dbOpenTable, dbSeeChanges, dbOptimistic)
И заметь dbOpenTable подходит только для таблиц. С Sql это неможет работать по определению(там нет номера записи)!

К No 3
>А как организуется именение данных, представленных датасетом?
>В BDE удобно делать запросы на вставку/изменение через TUpdateSQL, а в ADO вроде такого нет.
ADO сам формирует запросы на изменение, их можно подсмотреть с помощью SQL Profiler, если речь идет об MSSQL Servere. Если же очень надо по-своему проапдейтить (действительно бывает нужно), то на BeforePost можно забульбенить свой апдейт, только не забудь после этого добавить Cancel (чтобы перевести датасет в состояние dsBrowse) и Abort чтобы прервать дальнейший процесс постинга записи.

К No 5
>Кстати некто незнает как реализован метод seek в ADOTable если это SQL?

Вот - из хелпа
The VCL Seek method is a direct implementation of the Seek method for the ADO Recordset object. At the time of this writing, this method is only supported for use with Microsoft Access2000 and the Jet 4 provider.
Так что глянь на MSDN - может уже этот метод работает с SQL-базами. Хотя вряд ли. Однако не понятно почему не реализовано, ничего фантастически сложного тут нет.

А по поводу нужны - не нужны компоненты. Я тоже использую лишь малую часть борландовских компонент (я так понимаю, что 3rd-party компоненты выходят за границы обсуждения). Но если ты меня спросишь, какие компоненты я бы выкинул, я, пожалуй, скажу - никакие. Это как со словарем - есть устаревшие слова, которыми уже никто не пользуется, но это не повод чтобы их выкидывать. Другое дело, что если по ошибке в набор компонент пролез полный мусор, то его, конечно, надо выкинуть.

Кстати некто незнает как реализован метод seek в ADOTable если это SQL? Ведь SQL неподерживает этот метод! А в DAO надо открыть таблицу как таблицу, не как динамический recordset. Это все применимо только к MsAccess. Согласен для SQL серверов применение ADOTable недопустимо.

Пожалуй я и 10% стаддартных компонент не использую, впрочем своих и сторонних еще меньше. Принцип следующий - использовать когда только возможно стандартные (как визуальные так и компоненты для доступа к данным). От добра добра не ищут. Так например на ADO пока не перехожу хотя работаю с MS Access.

Когда я выдвигал тему,  то хотел чтобы обсуждение пошло несколько дальше, чем использование ADOTable и ADODataSet. Хотелось бы провести аналогию между алгоритмическими языками и языками, на которых мы общаемся. Очевидно, что любой язык, английский, русский - структура динамическая. Возникают и отмирают новые слова, обороты и т.д.Какое-то словечко становится модным, слышишь его на каждом углу. Потом на смену ему приходит что-то другое. Некоторые люди обходятся словарным запасом в 1000 слов другие - 500.Оправдано ли существование всех "стандартных" компонентов в Delphi? Может стоит кое что выкинуть? Или добавить? Я например и половины не использую.

А как организуется именение данных, представленных датасетом?
В BDE удобно делать запросы на вставку/изменение через TUpdateSQL, а в ADO вроде такого нет.

>Слышал что компонент ADOTable не совсем "родной" для Delphi 6.0 и предпочтительнее использовать ADODataSet

Я полагаю, что родным или неродным ADOTable может являться для ADO, но никак не для Delphi. Если смотреть с этой точки зрения, то действительно, интерфейс ADO предоставляет доступ к таким объектам как Connection, Command и Recordset. Т.е. как бы да, ADOTable - неродной для AOD.
Но посмотрим глубже.
Свойство TableName фактически является свойством CommandText, просто по-другому названным. А CommandType вообще на Create устанавливается в cmdTable. Т.е. ADOTable это тот же ADODataset, только слегка подмаскированный под TTable. Так что использовать ADOTable или ADODataset с CommandType установленным в cmdTable - дело сугубо хозяйское. Другой вопрос, стоит ли вообще пускать дело создания запросов к базе на самотек? Я лично с некоторых пор (а именно, почти сразу после знакомства с ADO) использую только ADODataset и только с CommandType установленным в cmdText. Поверьте, это очень просто написать: SELECT * FROM MyTable. Зато когда вам понадобится какое-нибудь усложнение запрса, скажем, добавить к запросу еще одну таблицу (JOIN), это будет сделать легко. Короче, ADODataset более универсален.
Более того, когда мне требуется получить _Recordset, не требующий редактирования, или выполнить команду не возвращающую рекордсета, я вообще стараюсь гнать все напрямую через ADOConnection, потому что предпочитаю держать под контролем то, какой именно запрос будет послан на SQL сервер.
Т.о. реально необходимы всего две из имеющихся компонент, а остальные созданы для удобства тех, кому покажется удобным их использовать.