Почему может выскакивать Syntax error or access violation?

← →
Bless (2003-11-21 15:33) [0]

Люди, может кто-то сталкивался в ошибкой
Syntax error or access violation?
Что сие означает? Меня интересует не перевод на русский,
а какие могут быть причины ее появления, а то у меня уже
догодки кончились

Выскакивает после сбедующих строк
(q - это TADOQuery)

SQl.Text:=" DECLARE @nzsme int SET @nzsme=:nzsme"+
" UPDATE fakt_mes_mat"+
" SET ob=:ob6, st=:st6 WHERE nzs=@nzsme AND nzm=""6"""+
" UPDATE fakt_mes_mat"+
" SET ob=:ob7, st=Null WHERE nzs=@nzsme AND nzm=""7""";
Parameters.ParamByName("nzsme").Value:=nzsme;
Parameters.ParamByName("ob6").Value:=ob6;
Parameters.ParamByName("st6").Value:=st6;
Parameters.ParamByName("ob7").Value:=ob7;
execSQL;

Причем, если вместо параметров явно подтавить числа в запрос,
ошибка пропадает.

Также ошибка исчезает, если в этом месте использовать другой TADOQuery
(q активно используется в предыдущих строках программы
для самых разных запросов. Может в этом дело?)

← →
Johnmen © (2003-11-21 17:00) [1]

1. Сперва q.Close
2. Перед каждым определением параметра ParamByName надо
Parameters.ParamByName("...").DataType:=...; // ftInteger, ftString etc
3. Другая причина.

← →
Bless (2003-11-21 17:38) [2]

>1. Сперва q.Close

Делал я так. Делал даже
q.connection:=nil;
Не помогает.

>2. Перед каждым определением параметра ParamByName надо
> Parameters.ParamByName("...").DataType:=...; // ftInteger,
>ftString etc

Гм... Попробую сейчас. Но вообще-то насколько я понимаю datatype выставляется сам, соответственно типу значения справа от ":=", если его тип можно определить. Я проверял на нескольких примерах. Да и в окне Watch на месте перед ошибкой dataType стоял ftInteger, как и должно.

← →
Bless (2003-11-21 17:45) [3]

Попробовал указывать явно тип. Результат тот же.

← →
Silver Alex © (2003-11-21 17:49) [4]

а зачем так писать, нельзя все это сделать в хранимой процедуре?

← →
Anatoly Podgoretsky © (2003-11-21 17:53) [5]

И что можно сразу два UPDATE сделать в адо, в одном предложении?

← →
Sandman25 © (2003-11-21 17:55) [6]

Там между командами Declare, Update и еще Update разве никаких разделителей не надо? Типа точки с запятой? Если вообще несколько команд в одном SQL.Text поддерживаются...

← →
me (2003-11-21 19:19) [7]

Если хочется запускать на выполнение целый batch - про параметры нужно забыть

← →
sniknik © (2003-11-21 22:28) [8]

me (21.11.03 19:19) [7]
с чего бы это? если можеш поясни причины.

вроде бы все работает, и у Bless говорит тоже если другой квери подставить. т.е. виноват не метод а конкретный компонент/настройки/остатки предыдуших запросов/изменений.

← →
Shirson © (2003-11-23 19:14) [9]

С ADO параметры задавать лучше так:
q.Parameters.ParamValues["nzsme"]:=nzsme;

← →
Bless (2003-11-24 09:38) [10]

>а зачем так писать, нельзя все это сделать в хранимой процедуре?

Можно, конечно. Но сейчас, когда я морально созрел для хранимых процедур, написана уже добрая половина проекта без них. То бишь, чтобы получить "тонкого" клиента, желательно все переписать, а не очень хочется. И даже если я воспользуюсь хранимой процедурой лишь в этом конкретном случае, с ошибкой все-равно надо разобраться.

← →
Bless (2003-11-24 11:24) [11]

Кстати, вопросик.
Почему код

with q do begin
SQL.Text:=
" INSERT INTO t1(kod) VALUES (123)"+
" SELECT * from t1"+
" SELECT * FROM t2";
active:=true;
end;

сам переводит q из ltOptimistic в ltBatchOptimistic.
То есть, до его выполнения q.LockType было ltOptimistic, а после
выполнения - ltBatchOptimistic

← →
Bless (2003-11-24 11:41) [12]

И еще 2 вопроса:
если потом сделать
q1.recordset:=q.recordset;
q2.recordset:=q.nextRecordset;

то q1, q2 тоже становятся ltBatchOptimistic. Почему?

И что происходит, когда делаешь q1.recordset:=q.recordset?
Зависит ли q1 после этого как-то от q?
Могут ли какое-то манипуляции с q после такого присваивания
каким-либо образом повлиять на q1?

← →
Bless (2003-11-24 12:54) [13]

Проблема локализована. Следующий код работает:

SQl.Text:=" UPDATE fakt_mes_mat"+
" SET ob=:ob6, st=:st6 WHERE nzs=:nzsme AND nzm=""6"""+
" UPDATE fakt_mes_mat"+
" SET ob=:ob7, st=Null WHERE nzs=:nzsme1 AND nzm=""7""";
Parameters.ParamByName("nzsme").Value:=nzsme;
Parameters.ParamByName("nzsme1").Value:=nzsme;
Parameters.ParamByName("ob6").Value:=ob6;
Parameters.ParamByName("st6").Value:=st6;
Parameters.ParamByName("ob7").Value:=ob7;
execSQL;

То есть, что-то с локальной переменной связано. Но что?
Есть у кого-нибудь какие-то идеи?

← →
Bless (2003-11-24 15:42) [14]

Все работает с изначальным текстом запроса,
если убрать перед предыдущим q.open
(я говорил, что q активно использовался до вышеприведенных строк)
строку q.prepared:=true;
А так как я толком не понимаю, какой в этой строке смысл, то буду признателен за любые объяснения по этому поводу.

То есть, я читал хелп и из него понял, что prepared:=true "подготавливает" запрос к выполнению и что вроде как "подготовленный" запрос выполняется быстрее. Но что значит "подготовить запрос", я не понимаю.

Почему может выскакивать Syntax error or access violation? Найти похожие ветки