Devart Forum

Добрый день.

Столкнулся с проблемой:
При работе периодически наблюдается ошибка Update Failed. Found 0 Records
но дело не в том, что в этот момент какой-то другой из пользователей поменял текущую запись.
Эта ошибка, возникнув в приложении один раз, продолжает появляться абсолютно во всех UniTable в приложении. Не помогает ни Refresh ни даже переоткрытие UniTable. Ошибка возникает при любой операции изменения данных (вставки, редактировании, удалении)
В UniTable включена опция RefreshBeforeEdit В профайлере я вижу запрос, который формирует Юнидак перед редактированием записи таблицы (лочит запись, согласно опции RefreshBeforeEdit)
Запрос формируется верно, по полям PK таблицы и по условиям этого запроса возвращается одна запись из таблицы (RowsAffected внитри Юнидака должен быть = 1).

Воспроизвести ситуацию на тестовом проекте не удается. Можно смоделировать только ошибку, если в момент редактирования записи первым пользователем, второй её удалит. Первый попытается сохранить и получит ошибку. Но после обновления источника первый пользователь сможет продолжить работу с приложением.

В мануале Юнидака написано, что эту опцию рекомендуется отключать, если на таблице висят триггеры. Триггеры на таблице есть, но операции над сохраняемой записью они не производят. Если бы триггер здесь влиял, ошибка бы проявлялась на конкретной таблице. А так, раз возникнув, она продолжает возникать абсолютно на всех UniTable, пока не перезапустить приложение.

Если отключить опцию StrictUpdate, на что еще это может повлиять, кроме того, как перед выполнением запроса на редактирование записи, Юнидак будет проверять, что редактируется действительно одна текущая запись?
Окружение Delphi 10.1 Berlin, UniDAC 6.4.14

Добрый день.

в TUniQuery в SpecificOptions для провайдера SQL Server можно указать параметр NonBlocking. Но почему-то эта опция не работает.
Тестовая ХП в SQL Код в тестовом приложении: В модуле UniProvider.pas метод TOptionsList.ImportOptions опция NonBlocking для InternalClass = 'TOLEDBCommand' установлена в False. Далее в DBAccess.pas в методе TCustomDADataSet.OpenCursor поле FNonBlocking имеет значение False.

Как можно заставить запрос выполняться асинхронно, чтоб пользователь мог его прервать в любой момент? Возможно есть какой-то альтернативный способ прерывания выполнения запроса или установлены не все свойства для TUniConnection\TUniQuery?

Окружение: Delphi Seattle 10, MS SQL Server 2008 R2, UniDAC 6.2.9

В БД таблица имеет поле varchar(200). В приложении нужно ограничить кол-во символов в поле. Перед открытием таблицы делаю UniTable1.FieldByName('FieldName').Size:= 50;
После открытия UniTable размер поля снова сбрасывается на 200, как в БД.
Проверял на компонентах доступа ADO - такой ошибки нет, ограничение остается и работает после открытия таблицы.

Окружение: Delphi XE, UniDAC 6.2.9, MS SQL 2008R2

Добрый день. Планируется ли релиз в декабре? Ожидался же на начало месяца.

Отлично, а когда планируется релиз?

Добрый день.

Если после сохранения записи выполнить Refresh и растянуть грид, в нем портятся данные, затем происходит Assert.
Во вложении скрипт создания БД, тестовый проект.

Гифка, со с steps to reproduce:


Окружение Delphi XE, Delphi XE10 Seattle, UniDAC 6.1.6, UniDAC 6.2.8, MS SQL 2008 R2

Когда, приблизительно, можно ждать релиза?

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

Есть ли какие-то результаты по этому вопросу?

AndreyZ писал(а):При CursorUpdate = True для сохранения изменения данных мы используем интерфейс OLE DB, который требует явного заполнения всех полей таблицы, в противном случае незаполненные поля будут установлены в значение NULL. Мы не можем повлиять на это поведение OLE DB.

И при утсановке в TUniConnection OLEDBProvider в prNativeClient ситуация, судя по тестам, та же самая.
Но тем не менее ADO апдейтит только изменяемое поле из всей таблицы с помощью курсора и остальные поля записи в NULL не устанавливаются: Провайдер в TADOConnection установлен в Microsoft OLE DB Provider for SQL Server (в строке подключения - Provider=SQLOLEDB.1) остальное по умолчанию.

Настройки ADOTable:
CursorLocation = clUseServer
CursorType = ctKeyset
остальное по умолчанию.

AndreyZ писал(а): Для серверного курсора типа ctKeySet записи, добавленные или удаленные другими пользователями недоступны для курсора.

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

Доброго времени суток.

Есть ли способ оптимизировать запрос на UPDATE, который делает TUniTable, путем уменьшения перечня обновляемых полей?
Суть проблемы: при обновлении одного поля из записи в TUniTable в профайлере виден запрос
exec sp_cursor 180150005,33,1,N'[TestTable]',@Field1=1,@Field2=2,@Field3='Test',@Notes=NULL.
т.е. UPDATE выполняется по всем полям. Если таблица имеет большое количество полей, то это не рационально.
На таблице висит триггер на UPDATE, который проверяет изменяемые значения каждого поля. Поскольку в вышеуказанном запросе участвуют все поля, мы имеем лишние проверки валидности значений полей, которые по факту не менялись.

Настройки TUniTable: Настрйоки TUniConnection: Пробовал ставить SpecificOptions.Values['SQL Server.CursorUpdate']:= 'False', UPDATE выполняется только по измененному полю посредством запроса, но есть проблема: при создании новой записи (Append) и последующем сохранении - её нет в датасете.

Все остальные настройки - по умолчанию.
Используется UniDAC 5.2.7, MS SQL 2008 R2.

З.Ы. была замечена ошибка "Bookmark is invalid." после сохранения новой записи. при настройках (Остальное - по умолчанию).