Ошибка ADOQuery, триггера и запроса - PullRequest
Новая
       19

Ошибка ADOQuery, триггера и запроса

1 голос
/ 23 июня 2009

У меня есть ADOQuery, который вставляет запись в таблицу SQL Server 2005, которая имеет триггер для вставки данных в другую таблицу. Я использую следующий код, чтобы обновить запрос и избежать Row cannot be located for updating (в каждой таблице есть PK, свойство UpdateCriteria установлено, курсоры установлены на Dynamic, но иногда я все еще получаю сообщение об ошибке. Однако теперь это не вопрос). * 

procedure Requery(T: TCustomADODataSet; IDField: string);
var
  i: integer;
begin
  if T.RecordCount > 0 then
    i := T.FieldByName(IDField).AsInteger;
  T.Requery();
  if T.RecordCount > 0 then
    T.Locate(IDField, i, []);
end;

Перед запросом я могу получить значение поля ID. Однако после запроса поле идентификатора возвращает значение поля идентификатора другой записи таблицы, введенной триггером. Обе таблицы имеют поле идентификатора с одинаковым именем. Я также добавил SET NOCOUNT ON .... OFF для запуска, чтобы избежать ошибки Too Many Rows Affected, однако я не думаю, что это влияет на мою проблему. Я не видел подобных ошибок, когда работал с Delphi 6 - 7 и SQL Server 2000, поэтому я готов попробовать SDAC или DAO . Решит ли SDAC или DAO проблему или есть какое-либо решение без изменения ADOQuery?

Ответы [ 2 ]

2 голосов
/ 23 июня 2009

Я не знаком с ADOQuery, но, как вы говорите, вы получаете идентификатор таблицы, на которую воздействует триггер, и ожидаете получить идентификатор исходной таблицы, возможно, это вопрос использования эквивалентной функции SQL "scope_identity". См. Лучший способ получить идентичность вставленной строки?

РЕДАКТИРОВАТЬ

Кажется, что проблема связана с тем, что сам запрос ADO использует @@ Identity для получения идентификатора добавленной записи, в то время как он должен действительно использовать scope_identity (), что имеет значение, когда у вас есть триггеры, вставляющие данные в другая таблица, которая содержит столбцы идентификаторов, как и в вашем случае - см. ссылку выше для получения подробной информации о scope_identity и @@ identity. В этом посте есть некоторые детали проблемы

1 голос
/ 23 июня 2009

Один из способов избежать этого беспорядка, который я использовал в прошлом, заключался в добавлении поля GUID в мою основную таблицу, и перед сохранением (если guid был пустым) я сгенерировал бы новый guid в коде и удерживал эту ссылку , Затем я сохранил бы запись и повторно запросил бы запись, содержащую известный guid. Это застраховало меня, что я получил именно ту запись, которую хотел, и затем продолжил присваивать FK значение идентификатора основной записи. Конечно, это медленнее, но всегда работает статистически.

...