Собственно можно ли в SQL-выражении для работы с SQLite объявлять локальные переменные ?
Вопрос возник в связи с переносом базы с MS-SQL на SQLite 3.
Есть SQL выражение которое никак не могу перенести на SQLite 3

-- извлекаем из базы прежнее значение поля Doctype
declare @tempDoctype int;
SELECT @tempDoctype = Doctype 
FROM dbo.tContracts 
WHERE id = @contract_id

/* здесь обновляются данные tContracts*/ 

-- определяем Тип операции по изменению значения поля Doctype
-- @docType - новое значение
-- @tempDoctype - прежнее значение, хранившееся в базе
declare @operationType int;
if((@tempDoctype = 2) and (@docType != 2))
    set @operationType = 11;
else if((@tempDoctype != 2) and (@docType = 2))
    set @operationType = 13;
else set @operationType = 3;

-- вносим в LOG сведения о произведенной операции
INSERT INTO dbo.tOperationLog
(idOperation, idDataRecord, idUser, date)
VALUES (@operationType, @contract_id, @registrator_id, GETDATE())

Ищу аналог declare для SQLite.
Может быть я криво читаю доки, но похоже декларирование локальных переменных в SQLite не поддерживается.
Кто-нибудь может посоветовать решение ?

Судя по www.sqlite.org там ещё и "IF" не предусмотрен.
Это делает перенос ещё более эротичным.
Я бы использовал таблицу для задания отображения ( @tempDoctype, @docType ) -> @operationType.

Здравствуйте, redKOT, Вы писали:

KOT>Может быть я криво читаю доки, но похоже декларирование локальных переменных в SQLite не поддерживается.
Не поддерживаются, вообще, зачем понадобилось переносить? С такими запросами гемор вам обеспечен конкретный.
KOT>Кто-нибудь может посоветовать решение ?

Что-то типа:

INSERT INTO tOperationLog
(idOperation, idDataRecord, idUser, date)
VALUES ((SELECT case 
          when Doctype = 2 and @docType != 2 then 11 
          when Doctype != 2 and @docType = 2 then 13
          else 3 
        end
    FROM tContracts WHERE id = @contract_id), 
        @contract_id, @registrator_id, GETDATE())

Рекомендую такие конструкции использовать и на SqlServer, ибо императивщина почти всегда хуже декларативщины.

Здравствуйте, Ziaw, Вы писали:

Z>Не поддерживаются, вообще, зачем понадобилось переносить? С такими запросами гемор вам обеспечен конкретный.

За вариант спасибо, обязательно обкатаю и отпишусь
переносить решил, потому что SQL Server по громоздкости не соответствует масштабам приложения
машины слабые, сервер также оставляет желать много лучшего
поэтому хочу выжать максимум производительности

Здравствуйте, redKOT, Вы писали:

KOT>За вариант спасибо, обязательно обкатаю и отпишусь
KOT>переносить решил, потому что SQL Server по громоздкости не соответствует масштабам приложения
KOT>машины слабые, сервер также оставляет желать много лучшего
KOT>поэтому хочу выжать максимум производительности

SqlServer CE? Не думаю, что sqlite будет быстрее на заметную глазу величину, а проблем с переносом будет существенно меньше.