C/С++ и MS SQL сервер

Писал ли кто С или C++ программы, выполняющие запросы к MS SQL серверу? Какие инклуды и библиотеки используются? Может кто-нибудь знает ссылочку с описанием функций?

Я подобные программы делал для ORACLE. Причем как с OCI так и с включаемым SQL.

Resurrector>Пользуй ODBC, ADO, или другой унивесальный интерфейс.

Выделено мною

Я пишу клиентов на Visual C++ (MFC + ATL (OLE DB) + Stingray Objective Toolkit + Stingray Objective Grid) для MS SQL Server 7.0-2000.

У Вас же варианты такие:
Средства доступа
1. MS SQL Server API
Пункт "Developer Tools" при установке сервера (обратите внимание на подпункты). Использовать не рекомендую по причине жесткой привязки к MS SQL. "Не юзал, но осуждаю" .
2. ODBC. Универсальное средство доступа. Не рекомендую, ибо считаю тормознутым архаизмом. В качестве обертки можно использовать MFC или ADO.
3. OLE DB. Универсальное средство доступа, IMHO самое быстрое. Header - oledb.h. Обертки - ATL и ADO.

---

Если пишете в MS VC++, то...
...для ускорения написания кода можно использовать ODBC через MFC или ADO, либо OLE DB через ADO.
...для написания малотормозящей (или вообще работоспособной) программы рекомендую OLE DB через ATL (или без обертки - через интерфейсы).

Документация:
1. Для MS SQL API - SQL Server Books Online + MSDN.
2. Для OLE DB - MSDN (Platform SDK -> Database And Messaging Services -> Microsoft Data Access SDK).

Гм. А разве вместе с сервером не идёт "комплект разработчика" - заголовочные файлы и библиотеки? Это я по аналогии с IB Database - только для него занимался программированием на "родном" API. И документации достаточно. Может, переустановить сервер и посмотреть, что предлагается для установки?

Дилетант>Писал ли кто С или C++ программы, выполняющие запросы к MS SQL серверу? Какие инклуды и библиотеки используются? Может кто-нибудь знает ссылочку с описанием функций?

Дилетант>Я подобные программы делал для ORACLE. Причем как с OCI так и с включаемым SQL.

Пользуй ODBC, ADO, или другой унивесальный интерфейс.
Я даже не знаю, имеет ли MS SQL собственный...

Resurrector>Почему?

Потому что универсальность означает в данном случае в том числе и переносимость^* на другие серверы БД (Interbase, DB2). Я считаю это важным моментом.

---

• - При грамотном программировании .

Resurrector>>Почему?

Igor>Потому что универсальность означает в данном случае в том числе и переносимость^* на другие серверы БД (Interbase, DB2). Я считаю это важным моментом.
Igor>

---

Igor>* - При грамотном программировании .
Увы и ах... Насчет DB2 и IB ты IMHO не прав... На практике эта преносимость получаетс только для тех систем, для кот-х реализованы OLE DB провайдеры. Но если даже он есть, то еще не факт что он поддерживает нужные фичи. И даже если нужные фичи есть , то еще не факт что они работают точно так же как на сервере, кот-й использовался первоначально. Например мне через ADO так и не получилось залить в binary поле данные в Acces тем же макаром, как я это легко делаю с MS SQL. Мож я конечно и не дорыл (необходимости не было), но скажем прямо это говорит о неперносимости программы с MS SQL на Acces без дополнительных танцев с бубном.
Так что переносимость ADO это IMHO миф. Хотя сам по себе ADO — довольно удобный и мощный способ доступа к БД.

Resurrector>>Пользуй ODBC, ADO, или другой унивесальный интерфейс.

Igor>Выделено мною

Почему?

Fakas>Увы и ах...

Да, все не так уж просто. Собственно, об этом и было примечание . Я, конечно, не утверждаю, что можно сделать полностью переносимой любую задачу . Хорошо уже то, что написание переносимых программ в принципе возможно.

Fakas>На практике эта преносимость получаетс только для тех систем, для кот-х реализованы OLE DB провайдеры.

Провайдера для DB2 я, по-моему, видел (если кого-то интересует - дистрибутив под рукой, могу посмотреть); с IB не знаком вовсе. Однако OLE DB, если мне не изменяет память, - промышленный стандарт, со всеми вытекающими...

Fakas>Но если даже он есть, то еще не факт что он поддерживает нужные фичи.

Да. В числе таких фич можно указать необязательные (optional) интерфейсы OLE DB .

Fakas>Мож я конечно и не дорыл (необходимости не было), но скажем прямо это говорит о неперносимости программы с MS SQL на Acces без дополнительных танцев с бубном.

Этот случай однозначно требует Глубокого Бурения . Просто чтобы доказать совместимость серверов через OLE DB .

Fakas>Так что переносимость ADO это IMHO миф.

А чистый OLE DB?

Fakas>Хотя сам по себе ADO — довольно удобный и мощный способ доступа к БД.

Ага. А мне больше нравится ATL .

Resurrector>А если софт не планируется переносить на другие платформы, то вполне можно считать, что АДО - универсальный интерфейс.

Вообще-то ADO - только обертка . На счет универсальности можно говорить про ODBC и OLE DB.

Resurrector>Понял?

Вообще-то я с тобой не спорил, а как раз наоборот .

Igor>Да, все не так уж просто. Собственно, об этом и было примечание . Я, конечно, не утверждаю, что можно сделать полностью переносимой любую задачу . Хорошо уже то, что написание переносимых программ в принципе возможно.

Переносимых в каком смысле ? Если между ОС, то вспоминая Kylix еще верится . А вот если между RDBMS... Возникают вопросы. Хорошо если надо всего лишь отображать/редактировать несколько табличек. А вот что-то посерьезнее... Начнем с того, что SQL несовместим между серверами, да что там, даже между разными версиями MS SQL 6.5 и 7 например.

Fakas>>На практике эта преносимость получаетс только для тех систем, для кот-х реализованы OLE DB провайдеры.

Igor>Провайдера для DB2 я, по-моему, видел (если кого-то интересует - дистрибутив под рукой, могу посмотреть); с IB не знаком вовсе. Однако OLE DB, если мне не изменяет память, - промышленный стандарт, со всеми вытекающими...

Да ? Насколько промышленный ? Кроме виндов ?


Fakas>>Мож я конечно и не дорыл (необходимости не было), но скажем прямо это говорит о неперносимости программы с MS SQL на Acces без дополнительных танцев с бубном.

Igor>Этот случай однозначно требует Глубокого Бурения . Просто чтобы доказать совместимость серверов через OLE DB .

В смысле что не проблема или в смысле, что таки да, надо попробовать ? Там проблема кажись просто в различии

Fakas>>Так что переносимость ADO это IMHO миф.

Igor>А чистый OLE DB?

Слишком низко. Серьезно. Когда доступ к БД это всего лишь один из подуровней системы, то углубляться до такой степени никакого времени не хватит на разработку.

Fakas>>Хотя сам по себе ADO — довольно удобный и мощный способ доступа к БД.

Igor>Ага. А мне больше нравится ATL .

А что есть ATL ?

Fakas>Переносимых в каком смысле ? Если между ОС, то вспоминая Kylix еще верится . А вот если между RDBMS...

Это что за зверь? Я имел в виду разные серверы БД.

Fakas>Возникают вопросы.

Да можно сразу сказать - проблемы . Точнее, масса проблем.

Fakas>Начнем с того, что SQL несовместим между серверами, да что там, даже между разными версиями MS SQL 6.5 и 7 например.

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

Fakas>Да ? Насколько промышленный ? Кроме виндов ?

Я имею в виду только винды .

Fakas>В смысле что не проблема или в смысле, что таки да, надо попробовать ?

Надо попробовать... на досуге . Чисто из интереса.

Fakas>А что есть ATL ?

ATL есть RULEZ от Microsoft .

quote:

---

ATL is the Active Template Library, a set of template-based C++ classes with which you can easily create small, fast Component Object Model (COM) objects. It has special support for key COM features including: stock implementations of IUnknown,IClassFactory,IClassFactory2 andIDispatch; dual interfaces; standard COM enumerator interfaces; connection points; tear-off interfaces; and ActiveX controls.

ATL code can be used to create single-threaded objects, apartment-model objects, free-threaded model objects, or both free-threaded and apartment-model objects.

---

 

// MSDN
ATL поставляется вместе с VC++

Fakas>Слишком низко. Серьезно. Когда доступ к БД это всего лишь один из подуровней системы, то углубляться до такой степени никакого времени не хватит на разработку.

Согласен. Поэтому чистый OLE DB и не юзаю - только "в упаковке" ATL, что, IMHO, эквивалентно работе с ADO. Если Вы пишете в VC++, рекомендую изучить вопрос о применимости ATL в Ваших проектах. Да, разумеется, круг задач, решаемых с помощью ATL, гораздо шире работы с БД!

Р.П.>Да, забавный спор двух знатоков <...>

Не забудьте, что при необходимости доступа из Linux (в моём случае - CGI-скрипты) native API - единственный способ. Понятное дело, лучше разработать правильную библиотеку классов, с чётким разделением клиентских интерфейсов и реализации - тогда и переход на другую БД будет не таким болезненным. Впрочем, это я уже в банальности ударился .

Fakas>>Слишком низко. Серьезно. Когда доступ к БД это всего лишь один из подуровней системы, то углубляться до такой степени никакого времени не хватит на разработку.

Igor>Согласен. Поэтому чистый OLE DB и не юзаю - только "в упаковке" ATL, что, IMHO, эквивалентно работе с ADO. Если Вы пишете в VC++, рекомендую изучить вопрос о применимости ATL в Ваших проектах. Да, разумеется, круг задач, решаемых с помощью ATL, гораздо шире работы с БД!

А что такое VC++ ? Мы на Delphi работаем.
ATL это библиотека шаблонов ? Если да, то это не эквивалент ADO

Resurrector>>Почему?

Igor>Потому что универсальность означает в данном случае в том числе и переносимость^* на другие серверы БД (Interbase, DB2). Я считаю это важным моментом.
Igor>

---

Igor>* - При грамотном программировании .

АДО, конечно универсально только в рамках Окон. ОДБЦ - самый универсальный и переносимый интерфейс. Но, так как речь идет о MS SQL, а он привязан к окнам, то, по моему, софт тоже будет привязан к ним. А если софт не планируется переносить на другие платформы, то вполне можно считать, что АДО - универсальный интерфейс. Понял?

Fakas>А что такое VC++ ?



Fakas>ATL это библиотека шаблонов ?

Угу.

Fakas>Если да, то это не эквивалент ADO

Эквивалент в смысле удобства работы, а не формально.

Да, забавный спор двух знатоков: один спрашивает, что такое RDBMS, а другой - что такое ATL . Это не наезд .

Конечно, слой абстракции между клиентом и БД - полезнейшая вещь. Желательно только, чтобы он не был жёстко привязан к ОС. Может, CORBA нас спасёт, а?

Сасибо всем, кто отзвался!