C++ Builder и SQL Server 7.0

Раньше работала с СУБД PostgreSQL и использовала для связи из билдера компонент PostgresDAC. очень нравился. Сейчас, на работе, приходится работать с SQL Server 7.0, ибо другого там не хотят. Подскажите, пожалуйста, какой-то похожий компонент для связи с SQL Server. стандартные компоненты не очень воодушевляют... В гугле ничего не нашла

0

ADO + "сладкая парочка" QA+EM стандартной поставки мелкомягких для проектирования БЛ сервера и отладки клиентских запросов.
Лучше для мс скл не найдете.

0

Сообщение от MsGuns ADO + "сладкая парочка" QA+EM стандартной поставки мелкомягких для проектирования БЛ сервера и отладки клиентских запросов. Лучше для мс скл не найдете.

а как насчёт SDAC? Еще особо не смотрела его, но выглядит прилично.

0

Вот "базар" для примера.
http://www.sql.ru/Forum/actual... 258533&hl=

Добавлено через 38 минут
"Глюки" имеются у абсолютно любого рабочего софта и это как бы естественно.
На собственном опыте могу сказать, что когда ссталкиваешься с новым сервером (DAC+Клиентское ПО+компоненты+диалект SQL), то "глючность" проявляется как следствие непривычности. К старым "инструментам" со всеми их глюками уже привык и их не замечаешь, новые же проявляются во всей красе

Когда я переходил с парадокс на интербейз, мне все в КС казалось глючным, ну бувально все ! Начиная от какого-то дебильного скл и заканчивая какими-то транзакциями

Затем после нескольких лет работы с ФБ "пересел" на мускул. Море негатива !!! То, что легко делалось в ФБ (одна закладка IBX чего стоила ), тут преврращалсось в муки адовы !

Следующий сервер был MS SQL. "Какая гадость" - было первое мое впечатление. Особенно сильное если учесть что после долгой работы с элегантым и удобным как "беретта" IBExpert пришлось "разговаривать" с сервером посредством угробищ QA+EM. Плевался от АДО, от строки соединения, от "блокировочной" технологии, от отсутствия Suspend (т.е. сервер не начинает отсылку данных до того, как полностью не закончит ее выборку), от невозможности Select from SP,
от "убожества" функций, от "скудости" триггеров (в МС СКЛ есть только AfterXXX).

Потом был PostgreSQL и Oracle...

В общем итог таков - КАЖДЫЙ интструмент имеет свои плюсы и минусы, к которым просто надо привыкнуть. Что касается конкретного программиста... ИМХО, работать надо учиться с тем, что установлено на работе ДО тебя. И не пытаться протаскивать свое до тех пор пока достаточно глубоко не разобрался с новым и не в состоянии более-менеее объективно сравнить "старую" технологию с "новой".

Что касается ТС:
1) ИМХО, без крайней нужды не стоит пользоваться компонентами сторонних разработчиков ибо при достаточно долгой жизни проекта (например разработка ERP/MRP типа) привлечение сторонних библиотек по каждому случаю (кому-то для постгреса, кому-то чтоб грид прокручивался мышой, кому-то просто для красивых кнопок) проект обрастает огромным слоем инсталляшек, без которых проект просто не будет компиллиться в ИДЕ). Особенно это приколько в командных пректах или когда вместо одних приходят другие программисты. Кроме того известны траблы с "посторонними" компонентами при переходах с ранних на более поздние версии ИДЕ.

2) ADO - родное для МС СКЛ. В случае необходимости без существенных затрат проект может быть переведен для ADO.net (для восьмерки например) - убежден, что MS не кинет своих многочисленных пользователей (имеется в виде МС СКЛ).
Что будет с "саппортом" от третьих лиц, будут ли они своевременно "подкручивать" его под мелкомягких - тот еще вопрос.

3) В АДО при работе с МС СКЛ глюков на самом деле вовсе немного.
Испытывал неудобство только в таких случаях:
- неадекватность интерпретации полученных от сервера чисел с точностью более 4 дес.знаков на клиенте (Джет виноват наверное, потому что в акцесе та же фигня) - приходилось заменять тип данных в запросах с NUMERIC (по умолчанию в разных калк-запросах) на FLOAT.
- затруднено (по крайней мере для меня), а главное не гибко явное управление транзакциями. То же самое можно сказать о событийной модели сервера. Но это уже сервер виноват, а не ДАК.
- в ADO внесли путаницу, добавив для бывших локальщиков BDE-подобные компоненты (TADOTable, TADOQuery, TADOStoredProc), имитирующие работу "старых добрых" парадоксов и фоксов. Но так как ежа с ужом скрестить невозможно, то и компоненты эти ведут себя не так (и это естественно,- поди докажи вчершнему парадоксисту, что скл-сервер - это не локалка, а очень даже наоборот !), отсюда и "глючность".
- отсутствие ХОРОШЕЙ СИСТЕМАТИЗИРОВАННОЙ литературы по связке ADO+MS SQL и наоборот масса поделок аля Фаронов-Архангельский, наносящих огромный вред делу и способствующий распространению слухов о "глючности" АДО. Хороша справка, но ее надо долго и нудно читать, разбираться, анализировать и систематизировать - а кому это нынче не в лом ?

2

MsGuns, огромное вам спасибо за такой подробный и полезный ответ! Я всерьез начала задумываться над тем, чтоб лишний раз взвесить все "за" и "против" SDAC. Почитаю документацию, что найду, по ADO и очень вероятно, что все же буду использовать именно его.
Еще раз спасибо!

0