Devart Forum

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

Спасибо за информацию. Мы воспроизвели и исправили проблему с потреблением памяти при FetchAl = True. Данное исправление войдёт в следующий билд UniDAC. Также, в следующем билде для TUniQuery и TUniTable будет добавлено свойство TSmartFetchOptions.

vfisher писал(а):Зафетченные данные из кэша не удаляются по аналогии с BDE, FireDAC, т.е. опять же держим память до закрытия таблицы, даже если данные нам больше не нужны.

При включенном SmartFetch и режиме LiveBlock = True минимизируется потребление памяти - выделяется блок памяти для того количества записей которое указано в свойств FetchRows. При вычитывании последующих записей новая память не выделяется и записи, которые вышли за пределы блока удаляются из памяти.

Если вы хотите получить это исправление, пришлите ваш адрес электронной почты и номер лицензии на andreyz*devart*com, и мы вышлем вам билд с исправлением.

Опция roAfterInsert не переоткрывает и не обновляет серверный курсор. Эта опция обновляет данные добавленной записи в датасете.

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

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

При опции SpecificOptions.Values['SQL Server.CursorType']:= 'ctKeySet' TUniTable работает с контекстом серверного KeySet курсора.

При CursorUpdate = False для вставки записи TUniTable выполняет команду 'exec sp_executesql', которая вносит изменения в таблицу, но не изменяет контекст курсора.

Согласно спецификации MSDN, в контексте KeySet курсора не будут видны записи, которые были добавлены или удалены в других контекстах.

Указанный вами скрипт не выполняется даже в SDAC версии 5.10.0.8. Пожалуйста, уточните, какой скрипт выполняется в старой версии без ошибок и не выполняется в новой версии SDAC.

Для того, чтобы поведение новой версии SDAC было аналогично старой версии TMSQuery.Options.UniqueRecords необходимо установить в True. При этом проблема при выполнении запроса из первого поста будет воспроизводиться как в старой, так и в новой версии. Проверьте, воспроизводится ли у вас проблема при выполнении запроса из первого поста на старой версии SDAC.

Если вы хотите получить данное изменение - пришлите свой e-mail и лицензию на andreyz*devart*com и мы вышлем вам специальный билд.

Приносим свои извинения. Сейчас все проблемы решены, скачайте UniDAC еще раз и переустановите его.

Ответ на ваш вопрос вы можете прочитать в параллельном топике
http://forums.devart.com/viewtopic.php?t=29501

В новый билд UniDAC данное изменение не вошло. Изменение данного поведения будет доступно на следующей неделе.

Добрый день.

Litta04 писал(а):1. Использование SQLInsert,SQLUpdate и т.д. в MSQuery возможно только при заполненном блоке SQL?

Да, т.к. при закрытом TMSQuery в дата-сет нельзя внести изменения.

Litta04 писал(а):2. Если да, то они в прямой связи ? Т.е. если в блоке запроса select ... from table1, возможно ли в блоке, к примеру, insert в другую таблицу (insert into table2 (id,name) values (:id,:name))?

В TMSQuery.SQLInsert есть возможность записать SQL-запрос, который изменит данные в другой таблице. Подробнее можно узнать тут http://www.devart.com/sdac/docs/devart_ ... insert.htm

Litta04 писал(а):3. В каких случаях используется компонент MSUpdateSQL ?

Об использавании TMSUpdateSQL можно узнать тут http://www.devart.com/sdac/docs/index.h ... atesql.htm

Пример использования TMSUpdateSQL вы можете увидеть в SdacDemo демо-проекте, который находится в папке "C:\Users\Public\Documents\Devart\SDAC for RAD Studio XE 5\Demos\SDACDemo\".

Мы исследовали проблему и изменим данное поведение в следующей версии UniDAC.

denzay.dp писал(а):И при утсановке в TUniConnection OLEDBProvider в prNativeClient ситуация, судя по тестам, та же самая.

UniDAC работает и c SQL Native Client provider через OLE DB интерфейс, поэтому поведение одинаковое.

denzay.dp писал(а):Но тем не менее ADO апдейтит только изменяемое поле из всей таблицы с помощью курсора и остальные поля записи в NULL не устанавливаются:

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

denzay.dp писал(а):Имелось в виду, что обновление данных происходит в той же TUniTable при CursorUpdate = False. Post формирует не exec sp_cursor, а SQL запрос. При этом, если запись мы insert-им, то в TUniTable эта запись, которую мы только что добавили, не видна. В гриде визуально запись исчезает, что выглядит как-то обескураживающе. После рефреша эта запись становится видна.

При опции SpecificOptions.Values['SQL Server.CursorType']:= 'ctKeySet' TUniTable работает с контекстом серверного KeySet курсора.

При CursorUpdate = True для вставки записи TUniTable выполняет команду "exec sp_cursor", которая вносит изменения в контекст самого курсора.

При CursorUpdate = False для вставки записи TUniTable выполняет команду 'exec sp_executesql', которая вносит изменения в таблицу, но не изменяет контекст курсора.

Согласно спецификации MSDN, в контексте KeySet курсора не будут видны записи, которые были добавлены в других контекстах.