Меня эта двойка тоже раздражает.
Чем тебя не устраивают стандартные константы?
Это такой специальный метод обфускации? Чтоб собиралось только тут, только с этими драйверами и нигде больше?

Что такое "стандартные константы"?Те которые определены в sql.h компанией Microsoft еще в те времена когда она только изобрела ODBC. Те которые используются всеми ODBC драйверами, потому что они все используют один и тот-же sql.h,

А откуда взялся конфликт макросов??? В нормальной программе делается #include <sql.h> и все макросы оказываются определены один раз и на всю компиляцию. Если ты подключаешь к себе какой-то левый заголовок, то ССЗБ и вся проблема решается убиранием этого #include.

Не, я конечно могу предположить что встретился на земле идиот который написал свой собственный ODBC драйвер на основе собственного набора SQL* констант. Но неужели тебе обязательно использовать этот кривой драйвер??? Что у тебя за уникальная RDBMS что для нее есть всего один единственный драйвер, да и тот со сбитой картой типов???

Нууу.... FireBird это конечно птица гордая...
Но все равно не вижу проблемы.

Если ты делаешь ETL, то во первых, можно все сделать намного проще через две отдельные утилиты - одна выгружает, другая загружает. Между ними может быть что угодно - чаще всего это CSV, реже какой-нибудь собственный формат файлов, еще реже полноценный IPC...

Не хочешь две утилиты? Тогда разбей свою утилиту на три логических части - одна будет "работать" с бизнес элементами (в смысле описывать и хранить данные не в виде таблиц, а в виде классов) а две другие будут делать чисто сериализацию этих бизнес элементов в свои RDBMS. Вот эти две части просто кидаешь в подкаталоги (чтобы не путаться) и работаешь с ними по отдельности.

Жив и будет жить еще очень-очень долго.
Просто вспомни что для MS SQL Server'а это "native" интерфейс и всяческие "более продвинутые" интерфейсы являются на самом деле обертками над ним. Так что пока MS живет как фирма - ODBC будет жить.

Альтернатив на самом деле довольно много, практически каждая команда делавшая свою СУБД делала для нее и интерфейс исходящий из технических решений в самой СУБД. Но...
Но сегодня, все СУБД имеющие клоны сервера для Виндов имеют в стандартной поставке и ODBC драйвер. Да и для Линукса имеются клоны драйверов, хотя там чаще можно встретить другие интерфейсы. Но... к ним все равно делают ODBC обертки. Простота интерфейса в сочетании с универсальностью (как ОС так и СУБД) - эту комбинацию побить чрезвычайно сложно.

Кстати, вот еще одни вариант для TC: https://firebirdsql.org/en/odbc-driver/ и выкинуть к чертям ibase.h.

Заменяют. В .Net языках.
Не забывай что ODBC это С интерфейс и только С и С++ могут с ним работать напрямую, все остальные языки требуют обертки. Вот для .Net такой оберткой и является ADO.Net.

Общего у ODBC и ADO довольно много. Начиная с владельца и заканчивая общими принципами работы с ними.
В среднем, для простоты понимания, можно говорить что ADO и ODBC это родные братья, но ADO для тех языков которые предпочитают работать с классами, а ODBC для языков предпочитающих функции. По возможностям и количеству фич они практически равны.
С точки зрения практической реализации, большинство ADO подключений к СУБД это всего-лишь использование моста ODBC-OLEDB-ADO с ODBC драйвером делающим реальные TCP запросы, а клиентская программа работает на ADO. Практически, вплоть до появления ADO.Net не существовало ADO драйверов.

А рекомендации... Все зависит от СУБД и языка на котором пишется клиент. В среднем, можно брать тот интерфейс который более удобен с точки зрения языка клиента (и это чаще всего ADO). Потери производительности на обертке можно игнорировать.
Но бывают ODBC драйвера с "расширениями вендора" которые дают больше функциональности. Например ODBC для SA позволяет делать push сообщений на клиента из хранимых процедур - чрезвычайно вкусная штука, но доступная только для прямого использования ODBC.

Вообще-то dblib это детище Sybase а не Microsoft. Разработанное во времена Sybase SQL Server.

Когда Microsoft купила у Sybase исходники их СУБД - купили и исходники клиентского интерфейса (dblib).
Долгое время, dblib был единственной возможностью подключаться к обоим СУБД (Sybase и MS SQL Server). Потом энтузиасты взломали этот интерфейс и родился FreeTDS.
Потом у Microsoft появились другие СУБД (FoxPro, Access) и возникла необходимость поддерживать три разных интерфейса - родился ODBC. Новый интерфейс стал "родным" для MS SQL Server и dblib в Микрософте умер.
А вот Sybase продолжала его поддерживать, но параллельно и новый интерфейс начали разрабатывать - родился CTlib. Оба интерфейса dblib и CTlib продолжали распространятся в каждой новой версии (теперь уже) Sybase Adaptive Server Enterprise. И вместе они назывались Open Client. Потом Open Client начал включать в себя и ODBC и OLE DB драйвера. Сейчас, когда эта СУБД уже носит имя SAP Sybase Adaptive Server Enterise - dblib продолжает существовать в каталоге на клиентском диске. Но я не знаю ни одного существующего проекта который не был бы переведен на CTlib или ODBC.

Не только похожее название, но и такой-же набор классов и методов - а это и есть определение интерфейса.

Да, ADO обертка над OLE DB. И да существуют OLE DB драйвера. Вот только они все разрабатывались по остаточному принципу и чрезвычайно кривы (как собственно и сам OLE DB). Поэтому практически всегда ADO используется с ODBC (через мост конечно же).

ODBC их тоже поддерживает. Примеры, ну хотя-бы xBase и Excel. В этих случаях парсер SQL запросов и собственно "сервер" находится непосредственно внутри ODBC драйвера. Этот SQL является диалектом разработанным для MS Access и практически as is скопированный во все микрософтовские ODBC драйвера для нереляционных БД, называется Jet SQL.

И вообще, мы ушли от изначальной темы топика, поэтом прекращаем.

Врут.

Да нет такой картинки. Там слишком много будет стрелочек чтобы в них всех разобраться. Или возьми эту картинку что ты уже нашел, объедини два нижних бокса (SQL/non-SQL) и добавь стрелочек из каждого верхнего бокса в нижний (за исключением ADO который только на OLE DB).

В общем ситуация простая:
У каждой СУБД есть собственный протокол общения с клиентами. SQL или не-SQL СУБД не важно.
Каждый такой протокол имеет собственный интерфейс который может использоваться клиентом - в этом случае клиент получает полный доступ к возможностям СУБД. Но эти интерфейсы уникальны для каждой СУБД и не совместимы между собой (исключение родственные протоколы).

Кроме уникальных (родных) интерфейсов существует группа универсальных интерфейсов рассчитанных на использование в конкретном языке (группе языков). Тогда мы говорим о "драйвере для СУБД" в рамках интерфейса.
Драйвер для СУБД реализует протокол общения между СУБД и машиной клиента, и выступает переводчиком между клиентским интерфейсом и протоколом. Если интерфейс SQL, а сама СУБД не SQL, то парсер языка вставляется внутрь драйвера, между собственно клиентским интерфейсом и драйвером протокола.
За исключением ADO который является полной оберткой надо OLE DB и полностью зависит от драйвера реализованного в OLE DB. Однако так как существует стандартный драйвер-мост OLE DB - ODBC то и ADO может работать на ODBC драйвере.

В результате ODBC драйвер переводит нативный интерфейс в ODBC интерфейс, потом OLE DB
провайдер для ODBC переводит ODBC интерфейс в OLE DB интерфейс, потом ADO обёртка
переводит OLE DB интерфейс в ADO интерфейс. В особо запущенных случаях ADO интерфейс
переводится в VCL DB интерфейс (для Delphi мышевозников) или обратно в нативный интерфейс
(для MS DB Links).

"А теперь мы со всей этой фигнёй попытаемся взлететь." (c)Да. Но на практике это работает и вполне успешно.

Прежде чем ужасаться, подумай, как этот "перевод" делается.