Devart Forum

Релиз UniDAC, который включает данное исправление, уже доступен для скачивания.

Мы исправили проблему с медленной загрузкой через MSLoader. Данное исправление войдёт в следующий билд SDAC и UniDAC.

Пожалуйста, постарайтесь составить небольшой пример, на котором воспроизводится данное поведение и пришлите его на почту andreyz*devart*com. В пример также включите скрипты для создания таблицы-источника и приемника.

Выход следующего билда UniDAC запланирован нами на конец этого или на начало следующего месяца.

Спасибо за информацию. Мы воспроизвели описанное вами поведение и будем его исследовать. Мы сообщим вам о полученных результатах.

Если ни одно поле записи не было изменено, то при вызове метода Post UniDAC формирует SQL запрос, который явно изменяет значения всех полей. При этом может возникнуть ситуация, когда на момент вызова Post для серверного курсора эта запись уже удалена другим пользователем. В этом случае сервер вернет ошибку. Если же UniDAC не будет вызывать запрос, то пользователь не узнает, что запись была удалена. Т.е. такое поведение является корректным.

Мы добавим сообщение об ошибке, если одновременно в датасете будет включен SmartFetch и тип курсора установлен в серверный курсор.

В предоставленном вами примере, кроме включенной опции SmartFetch, в датасете UniTable1 для провайдера SQL Server установлен тип серверного курсора ctKeyset. Поведение SmartFetch в UniDAC аналогично поведению серверных курсоров SQL Server, поэтому нет смысла одновременно использовать в одном и том же датасете и SmartFetch и серверный курсор. Данное поведение UniDAC не менялось нами ни в текущем релизе, ни в предыдущих релизах много времени.

Более подробное описание типов серверных курсоров SQL Server в UniDAC можно прочесть в нашей онлайн-документации: https://www.devart.com/sdac/docs/?devar ... ortype.htm

В предоставленом вами примере, для использования SmartFetch, перед открытием датасета установите свойству TUniQuery.SpecificOptions.Values['SQL Server.CursorType'] значение 'ctDefaultResultSet'.

vfisher писал(а):6.1.4 17-Jun-15...Bug with unnecessary update of all fields when a server cursor is used is fixed

Мы не можем воспроизвести указанный вами баг на текущей версии UniDAC 6.1.6 . Мы также попытались воспроизвести его на тестовом примере, который нам присылал denzay.dp, однако баг не воспроизвелся.

Пожалуйста, пришлите мне на почту andreyz*devart*com тестовое приложение, на котором воспроизводится данная проблема. К приложению также добавьте скрипт для создания тестовой таблицы.

К сожалению, в UniDAC не реализована обработка инфо-сообщений SQL Server, но она реализована в компонентах SDAC. Для получения инфо-сообщений SQL Server в SDAC вы можете использовать обработчик событий TMSConnection.OnInfoMessage . Более подробнее о событии OnInfoMessage вы можете прочесть в нашей онлайн документации: https://www.devart.com/sdac/docs/?devar ... essage.htm

Чтобы в приведенном вами примере получить сообщение об ошибке, передавайте при вызове RAISERROR значение параметра severity больше 10. Например, если значение этого параметра будет 11, то код вызова RAISERROR в триггере будет такой:

Мы изменили поведение UniDAC - out параметрам из SQL запроса автоматически устанавливается тип ptInputOutput для свойства TDAParam.ParamType этих параметров датасета. Данное изменение войдет в следующий билд UniDAC.

Мы исследуем это поведение и сообщим вам о результатах.

В версии 5.0.1 и последней версии, данное поведение UniDAC не отличается.

В SQL запросе для выполнения хранимой процедуры необходимо указывать типы параметров out, чтобы SQL Server вернул значения для этих параметров запроса.

Задавать свойству TDAParam.ParamType значение ptOutput необходимо, чтобы UniDAC вернул значения для этих параметров датасета из параметров запроса.

Приятно видеть, что вы разобрались с поведением транзакций в PostgreSQL. Если у вас возникнут вопросы относительно UniDAC, пожалуйста задавайте их и мы на них ответим.

raMZES писал(а):Я явно указал использовать определенную TUniTransaction, но это свойство игнорируется.

Пожалуйста уточните, после того как вы для этой транзакции установили сво-во ReadOnly в True, вызвали метод StartTransaction и изменяете данные в датасете - вы получаете сообщение об ошибке 'в транзакции в режиме "только чтение" нельзя выполнить UPDATE.'?

raMZES писал(а):Здесь же получается, что я указал в TUniTransaction уровень изоляции RepeatableRead, а он работает как ReadCommited.

Для этого вам необходимо для транзакции, которая связана с датасетом TUniQuery, вызывать метод StartTransaction перед открытием этого датасета.