Ggg_oldСейчас перехожу на VC. Вопрос, - что предпочтительнее для работы с ASA?
Ну лично я предпочитаю ODBC. Просто и легко. ODBC очень просто обернуть в свой собственный интерфейс, я например делаю ODBC вызовы только из одного модуля в полтора десятка собственных функций и десять килобайт размером. А дальше уже идет код типа:

Если тебя тянет к С++, то лучше будет работать с ADO. Там уже вся работа с базой представленна в виде классов. Дополнительный плюс - ADO реализован напрямую на очень многих языках и будет просто переходить с одного языка на другой, принципы работы с базой будут уже знакомы.

Embedded SQL вещь конечно хорошая, но слегка замороченая. ESQL незаменим если ты делаешь утилиту управления базой/сервером. Но для простого клиентского приложения оно не удобно.

Про OLE DB ничего не скажу, я сам с ним не работал.

Ggg_oldЯ "идею" EmbedSQL совсем не понимаю.
Идея очень простая - Embedded SQL это родной интерфейс ASA заточеный на особенности ASA. Через ESQL ты сможешь получить наиболее полный доступ к базе и серверу который невозможен через универсальные интерфейсы (ODBC/ADO/etc).
Например ТОЛЬКО через ESQL ты сможешь просканировать сеть чтобы найти IP адрес работающих серверов а не просто подключится к ним :)
Но это касается конечно только C-based ESQL библиотека которого идет вместе с ASA и его описание включено в BOL.
Все утилиты ASA используют как раз этот интерфейс.

Embedded SQL по версии Power Builder это всего лишь возможность давать команды серверу БД без создания datawindow и по сравнению с C-ESQL, PB-ESQL это маленький и хиленький уродец не стоящий обсуждения :)

Ggg_oldAll Sybase precompilers 11.0 and later use a runtime library composed solely of documented Client-Library and CS-Library calls. Basically, the precompiler transforms an Embedded SQL application into a Client-Library application , which is then compiled using the host-language compiler.
Ну. А что смущает?
Данный кусок вырван явно из документации на ASE а не ASA (их все же не надо путать, хоть они и родственники :) Но в ASA ситуация почти точно такая же. Пишешь программу на С-ESQL прогоняешь через препроцессор и получаешь чистый C или С++ код в котором все SQL вызовы превращаются в кучку вызовов к библиотеке dblibX.dll.

Ggg_oldПо поводу цитируемой доки. На сайте я не нашел отдельного описания openclient для ASA и ASE. Есть просто openclient v12.5, и более ранние версии. А в доке на ASA только указаны некоторые ограничения и особенности.
А это очень просто объясняется :) OpenClient как набор протоколов и библиотек обспечивающих доступ к БД делался изначально для ASE. Для ASA его уже более-менее пытались портировать. Поэтому, чтобы не морочить себе голову с полуработающим интерфейсом - если сервер ASE, то можно брать OpenClient. Если сервер ASA - то про OpenClient лучше забыть. Теоретически через OpenClient ты сможешь подцепиться к ASA, практически никто этим не занимается :)

Ggg_oldЯ попробовал поискать приличный C++ враппер для ODBC. Пока не нашел. Есть мелкие библиотеки, которые люди писали сами для себя. :-(
Приличный объектный враппер над процедурным ODBC это ADO. А OLE DB это совершенно отдельная штука которая изначально делалась под объекты. Что использовать - вопрос более религии и шаманских плясок.
Если пишешь на С могу дать свой собственный враппер ODBC. Мне его хватает уже который год :)

Ggg_oldНо... есть еще ADO.NET - которая вроде как пришла на замену ADO, но работает только для .NET.
Ну как я уже говорил, выбирая из ADO и OLE DB я предпочту ADO, потому что нативные вызовы ADO есть уже почти во всех современных языковых системах. А OLE DB только для С++.

MasterZivЯ уже писал, что не понимаю, отчего такая рекомендация.
Почему я не рекомендую при написании своего клиента для ASA использовать интерфейс OpenClient? Да потому что OpenClient делался и делается в первую очередь для ASE. Для всего остального его портируют - значит там будут глюки.
По моему, намного надежнее и проще с самого начала использовать универсальные интерфейсы типа ODBC/ADO.

MasterZivЯ могу попробовать порассуждать в таком же духе : "Для чего делался ODBC и ADO ? Для MSSQLServer. Для всего остального его портируют, значит там будут глюки ..." Похоже получилось ?
Конечно похоже, и даже правдиво :)
Просто ODBC и ADO за прошедшие года уже вылизаны. Сравни сколько людей используют их и сколько пользователей OpenClient? Да хотя бы с той точки зрения, что получить ответ по ODBC в форуме намного больше шансов что по OpenClient - уже огоромнейший плюс в сторону ODBC. Да еще и форумов по ODBC на порядки больше чем форумов по OpenClient.

iLLerА вот еще вопрос. В комплекте с АСА есть файл odbc.h, а также odbc32.lib для компоновки проекта на Си. Немного не догоняю, если ODBC единый независимый стандарт, то почему его части вкладывают в АСА.А чтоб были. На случай, если у тебя нету MDAC и в поставке твоего компилятора нету этого необходимого минимума...

iLLerА если я захочу подключаться к другим СУБД через ОДБС, мне уже эти файлы не помогут, понадобится перекомпилировать с новой билблиотекой от другой СУБД? Ведь вроде весь смысл ОДБС в том, что он позволяет абстрагироваться от конкретной реализации СУБД.

Проясните, почему они включены в пакет СУБД, а не поставляются в отдельном SDK. И могу ли я использовать именно эти файлы не в применении к конкретной СУБД (АСА)?Не паникуй. Они и так поставляются в отдельном SDK, называемом MDAC - Microsoft Data Access Components.
Но в MDAC лежат и библиотеки и хедеры и полная документация по всем трем интерфейсам (ODBC, ADO и OLE DB). И кстати, большинство современных компиляторов имеют копии всех этих библиотек в своей поставке, но уже без документации :)
В общем, ходи сюда, качай SDK и будет щастье: http://www.microsoft.com/downloads/details.aspx?familyid=78cac895-efc2-4f8e-a9e0-3a1afbd5922e&displaylang=en


Единственный хеадер из поставки ASA что может пригодится для работы с ODBC это asaodbc.h. В нем перечислены несколько констант - номера специфических функций поддерживаемых ODBC-драйвером для ASA. Если их не использовать то и хеадер не нужен.