Подключение Delphi к SQL Server - «надежная» замена BDE?

у нас есть приложение некоторого размера (около 1MLOC), которое было запущено еще в те дни, когда BDE собирался упразднить. В настоящее время мы используем его только для подключения к SQL Server с помощью ODBC. Несмотря на устаревший статус, он работал на удивление хорошо, и, скорее всего, он будет работать еще 15 лет. Однако никто не знает, когда он перестанет работать. И если это прекратится, Embarcadero ничего не сможет с этим поделать. Итак, это бомба замедленного действия, и нам нужно ее заменить. Но чем?

ADO-компоненты в Delphi выглядят многообещающе. Существуют компоненты таблиц и запросов, которые напоминают компоненты BDE, и они не являются сторонними компонентами, созданными одним человеком, который может потерять интерес. Мы также надеемся использовать строки подключения вместо неуклюжего ODBC-Administrator.

Однако около года назад Microsoft объявила, что OLE DB устарела, и для собственной разработки мы должны использовать драйвер ODBC для собственного клиента SQL Server.

Итак, мой вопрос: подключены ли ADO-компоненты в Delphi к СТАРОЙ БД? Или мы не будем использовать OLE DB, если выберем «Собственный клиент SQL Server» в списке драйверов?

Я ожидаю / боюсь, что для использования драйвера ODBC для собственного клиента SQL Server нам придется настроить источник данных в ODBC-Adminstrator, как мы это делаем сейчас. Или можно подключиться к ODBC с помощью строк подключения?

А какие существуют Delphi-компоненты, которые могут подключаться к ODBC без использования OLE DB? Да, я знаю о dbExpress, но похоже, что нам потребуются годы, чтобы преобразовать его из BDE.

Спасибо, LandShark


person LandShark    schedule 11.10.2012    source источник
comment
Просто чтобы добавить в список наши компоненты с открытым исходным кодом от Delphi 5 до XE3. Вы можете получить доступ к SQL Server через OleDB или через ODBC (что является будущим, поскольку OleDB - и, следовательно, ADO - официально устарела Microsoft). Существует TQuery замена, которая намного быстрее, чем версия BDE, и совместима с отдельными методами. Но объем проекта больше ориентирован на код, а не на компоненты / RAD.   -  person Arnaud Bouchez    schedule 11.10.2012


Ответы (3)


У нас была аналогичная потребность в миграции 5 лет назад, и мы провели довольно много исследований и тестирования. Самый простой путь миграции с BDE - на SDAC с devart (http://www.devart.com/sdac/). У Devart есть утилита замены BDE, которая просматривает ваш код и заменяет компоненты BDE эквивалентными компонентами SDAC. Это даст вам около 90% пути, после чего вам придется вручную внести некоторые изменения, чтобы все работало (например, если вы используете fetchall, вам нужно закомментировать весь код fetchall, но вы увидите шаблон и можете исправить оставшийся код в основном через поиск и замену). Производительность компонентов SDAC превосходна, они поддерживают все вызовы сервера sql, и вы можете использовать зашифрованные соединения через Интернет. Компоненты поддерживают Native SQL или OLEDB-подключения к SQL Server. Они также работают в автономном режиме с использованием кешированных обновлений. Другой вариант, если вы планируете поддерживать другие платформы баз данных в дополнение к SQL-серверу, - это использовать UniDac - он такой же, как SDAC, но будет работать с SQL Server, Oracle и другими - очень похож на старый BDE без накладных расходов.

person Charlie V    schedule 11.10.2012
comment
›UniDac - это как SDAC, хотя SDAC - это всего лишь часть UniDAC, не так ли? - person Arioch 'The; 11.10.2012

1) «собственное соединение» не означает использование ODBC или OLE DB, а также BDE и DBX. Собственное соединение означает использование специальной библиотеки, которая может подключаться только к MS SQL и не использует какие-либо стандартные серверно-независимые pipileines. Напротив, BDE и DBX, ADO и ODBC - это общие библиотеки, обеспечивающие подключение к любому серверу, для которого вы установите плагин.

Обычно собственные библиотеки обеспечивают более тесную интеграцию с сервером и использование некоторых функций, которые могут отсутствовать в общих библиотеках (например, события на серверах firebird / interbase). Они также могут работать быстрее, поскольку им не нужно перекодировать потоки данных и команды в / из стандартов общедоступного API конвейера.

Общедоступные интерфейсы OTOH упрощают переключение серверов и упрощают разработку серверно-независимых приложений.

2) Почему вы думаете, что преобразование BDE -> DBX будет сложнее, чем BDE -> ODBC или BDE -> ADO или BDE-> что угодно? Преобразование есть преобразование. ADO также имеет свои ограничения и недостатки, такие как DBX и любая другая библиотека.

3) DBX имеет плагин MS SQL. DevArt предлагает свой набор подключаемых модулей DBX и может предоставить лучший вариант, чем стандартная поддержка Delphi DBX MS SQL. А может и нет.

4) Помимо них есть несколько хорошо известных серверно-независимых библиотек.

  • ZeosLib - FLOSS, но имеет плохую поддержку последних версий Delphi. Вечная альфа.
  • AnyDAC - http://www.da-soft.com/anydac, коммерческий, широко известный
  • UniDAC - http://www.devart.com/unidac, коммерческий, широко известный

5) у вас может быть много прямых соединений ODBC на любом сайте сборщика компонентов, например http://www.torry.net/pages.php?id=570

6) то же самое для встроенного подключения MS SQL http://www.torry.net/pages.php?id=1513

Однако для оценки этого выбора и принятия решения требуется внутреннее знание контекста, которым можете обладать только вы.

person Arioch 'The    schedule 11.10.2012
comment
2) Да, в любом случае это будет огромная задача, но, поигравшись с компонентами ADO и dbExpress, с ADO кажется, что это проще. Компоненты ADO разработаны аналогично компонентам BDE. dbExpress - нет. - person LandShark; 11.10.2012
comment
3) Разве стандартный драйвер dbExpress не использует ole db? - person LandShark; 11.10.2012
comment
2) Поскольку дизайнером OLE DB в основном был дизайнер Delphi - этого и следовало ожидать :-) Хорошо, помощники классов исправят отсутствие некоторых методов параметров SQL и т.д. /// 3) Не знаю. Попробуйте деинсталлировать MDAC и запустить их - person Arioch 'The; 11.10.2012
comment
4) Теперь я вижу, что DevArt SDAC может использовать либо ole db, либо собственный клиент SQL Server, так что у нас, вероятно, есть решение, не использующее ole db. - person LandShark; 11.10.2012
comment
Стандартный драйвер DBX, вероятно, использует OLE DB: было сказано, что он работает только в потоках после вызова CoInititialize - person Arioch 'The; 12.10.2012

Несколько лет назад у нас была такая же проблема. Полагаю, если бы было идеальное решение, альтернатив не было бы так много.

Так или иначе, мы перешли с BDE + ODBC на ADO + SQLOLEDB. Основные причины заключались в том, что он был очень надежным, легко конвертируемым, не требовал установки дополнительных устройств на клиентские компьютеры (например, BDE) и был быстрее, чем другие, поставляемые с delphi, включая DBX (при использовании DisableControls).

Также в качестве дополнительного замечания, если вы хотите использовать ODBC для настройки соединения, вы можете использовать диспетчер ODBC для настройки значений, но считывать их из реестра и подключаться напрямую без ODBC. Это помогло нам переключиться.

person Tom    schedule 11.10.2012
comment
Хорошо, но тогда вы используете устаревшую базу данных ole db, которая поддерживается только семь лет назад. Он может работать намного дольше, чем поддерживается Microsoft, но есть большая вероятность, что вы не сможете подключиться к следующей версии SQL Server. То есть, если нет возможности использовать ADO-компоненты Delphi без ole db. Может быть, как на этом сайте (блоги .sqlteam.com / dang / archive / 2011/09/04 / rip-ole-db.aspx) он говорит: Используйте ODBC с драйвером Server Native Client. Интерфейс уровня вызовов ODBC можно использовать напрямую или через ADO API более высокого уровня. На самом деле это мой основной вопрос. - person LandShark; 11.10.2012