UniDAC для работы с большими таблицами > 300к записей не годится - потребляет очень много памяти. Их новая фича "SmartFetch" призвана это дело побороть, но вот уже сколько билдов подряд, начиная с версии 5.3 её не могут довести до ума. Постоянно AV-шки, assert'ы на равном месте (то при удалении\изменении записи, то на RAISERROR в триггере MS SQL UniDAC валится стопкой AV-шек). Эти баги правят, но на это зачастую уходят месяцы от релиза до релиза. В новом билде эти ошибки исправлены, но с ним приходит и стопка новых багов. Написать какой-то мало-мальски серьезный коммерческий продукт становится невозможным.

Что касается FireDAC, так исправления багов вообще можно годами ждать и если они выйдут, то только на последние версии Delphi XE 5,6,7. Пруф: http://qc.embarcadero.com/wc/qcmain.aspx?d=124435 Из-за этого бага вообще остановилась миграция проекта с BDE на FireDAC.

Так что такие, совсем не радужные, дела

defecator,

В 5.5.12 на UniTable некоторые баги были исправлены. Но на этой версии невозможно работать со SmartFetch и представлениями, на которые повешены триггеры INSTEAD OF.

В версии 6.0.1 это было исправлено, но в ней добавился собственный парсер SQL-запросов, полный багов. На сложных запросах, с UNION и алиасами ломается TUniQuery во время выполнения.

Нового билда, после 6.0.1 с исправлениями до сих пор не видно (25.11.2014), а времени прошло уже почти месяц.

Появились новые факты и эмоции на тему выбора компонентов доступа к СУБД


Компания, в которой я работаю, использует Юнидак уже несколько лет для продакшн проектов, которые используют множество клиентов в Украине и не только. С первого же билда Юнидак, который был на тот момент, постоянно есть какие-то глюки, в основном Access Violation. Спустя столько времени и тонн баг-репортов мы уже привыкли к AV-шкам, научились их подпирать какими-то костылями, либо ограничивать какой-то функционал, где всплывает ошибка UniDAC, благо эти ошибки довольно просто находились. В одном релизе есть какой-то один набор AV-шек, выходит новый билд, эти баги попатчены, но находятся новые (в течении полудня), при каких-то новых событиях.

Но на днях Юнидак нас удивил! Вышел билд 6.2.9 от 14.12.2015. Мы его тестили и нашли только ОДНУ AV во всем билде Юнидак, связанной с опцией обновления roBeforeEdit. В принципе, всего одна AV-хороший результат для UniDAC'a. И вот, мы на днях выпустили релиз и на следующий день были в шоке с новенького бага UniDAC: все числа, которые меньше 0.1, UniDAC молча, без зазрений совести, округлял до десятых. Соответственно 0.001 превращались в 0.1, 0.05 в 0.5 и т.д.
И вот что большего всего бесит в UniDAC: этот баг уже запостили на их форуме 21.12.2015 - они типично ответили, на данный критичный баг, что воспроизвели и исследуют проблему. Но мля, никакого письма клиентам, мол будьте аккуратны - есть критический баг, который можно сразу и не заметить. Для них это мелочь и им все равно. Если приложение, используещее UniDAC, это ERP-система с товарооборотом и прочим, то за время своей работы оно может столько начудить с суммами и ценами, что наступит коллапс, исправлением которого будет только один способ - восстановлением БД из бэкапа.


На сайте Devart в клиентах значатся такие компании как BMW, Boening, Samsung, Toyota и т.д. Как они могут использовать такие глючные продукты, где подвоха можно ожидать в самых невероятных местах? Дай Бог, чтобы не упал ни один самолет или не отказали тормоза в машине из-за AV или еще какого-то бага в компонентах Devart'a. Хорошо, что они со своим продуктом не добрались еще до АЭС.

Тестовый проект:

Dimitry SibiryakovЖелание жрать всегда самую свежую версию кактуса вызывает недоумение

вот когда исправят этот кактусище http://qc.embarcadero.com/wc/qcmain.aspx?d=124435
так сразу и соскочим с UniDAC'a