Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Непонятное поведение внутри процедуры Transact-SQL / 8 сообщений из 8, страница 1 из 1
26.09.2006, 16:37
    #34013333
A.K.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
Не первый день бьюсь над проблемой. ASA 8.0.3.
Внутри процедуры T-SQL есть такая строка:
Код: plaintext
1.
2.
3.
      update SC33
        set TREE1=@root_id
        where PARENTID=@curr_id
На отладчике проверено - запрос select * from SC33 where PARENTID='xxx', где 'xxx' - текущее значение @curr_id на момент выполнения UPDATE'а, возвращает ожидаемые строки. Переменная @curr_id принимает ожидаемое значение.
Тем не менее, периодически (процедуры вызывается несколько раз из скрипта) данный UPDATE перестает обновлять записи, при этом @@rowcount=0.
Повторное выполнение процедуры после сбоя дает стабильно тот же результат (сбой). Пересоздание процедуры проблему вылечивает на какое-то время.

Возможно, важный момент: Между несколькими вызовами процедуры таблица SC33 пересоздается и заполняется, причем с другим набором полей (естественно, поля TREE1 и PARENTID имеются во всех вариантах создания таблицы).
...
Рейтинг: 0 / 0
26.09.2006, 17:35
    #34013613
White Owl
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
Как именно пересоздается? Drop table - create table?
Может имеет смысл использовать временные локальные таблицы вместо постоянных?
Вообще, глюки такого типа происходят при нарушении индексов.

---
http://www.rusug.ru] Портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
26.09.2006, 17:51
    #34013664
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
White OwlКак именно пересоздается? Drop table - create table?
Может имеет смысл использовать временные локальные таблицы вместо постоянных?
Вообще, глюки такого типа происходят при нарушении индексов.
Не обязательно. Известная бага - это сохранение в кэше компилированной процедуры и ее планов запросов, где в результате изменения схемы БД сервер пытается выполнить сохраненный, но уже не соответствующий действительности план запроса процедуры. Особенно это легко прослеживается на этом примере:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
CREATE PROCEDURE Proc1 ()
BEGIN
  SELECT Field1, Field2
  FROM Table1;
END;

CREATE PROCEDURE Proc2 ()
BEGIN
  SELECT *
  FROM Proc1();
END;

-- работает
SELECT * 
FROM Proc2();

ALTER PROCEDURE Proc1 ()
BEGIN
  SELECT Field1, Field3
  FROM Table1;
END;

-- не работает
SELECT * 
FROM Proc2();
Даже если бы я оставил поле Field2, но у таблицы поменялся его тип, то обе бы процедуры вернули ошибку несовместимости типов.

P.S. Присоединяюсь к вопросу - зачем пересоздавать таблицы, кто мешает все делать на локальных времянках (тем более что они включены в поддержку диалекта TSQL) ?

---
http://www.rusug.ru] Портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
26.09.2006, 17:53
    #34013668
A.K.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
Пересоздается именно так.
Вернее так: после дропа таблица создается путем загрузки из DBF'а:
Код: plaintext
1.
2.
INPUT INTO SC33
 FROM "{cpath}\SC33.DBF"
 FORMAT DBASE ;
После этого в таблице воссоздается первичный ключ.

Еще при выполнении данной процедуры возникает ошибка:Column 'STATEFROM' not found при обращении к курсору по таблице SC33. Поле STATEFROM в это время в таблице существует и является последним полем в таблице.
...
Рейтинг: 0 / 0
26.09.2006, 17:58
    #34013683
A.K.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
ASCRUS

Спасибо, вы подтвердили мои подозрения насчет сохранения в кэше скомпилированной процедуры, возникшие после прочтения в документации:
авторAdaptive Server Anywhere always recompiles procedures the first time they are executed after a database is started, and stores the compiled procedure until the database is stopped.

В связи с этим 2 вопроса:
1) нельзя ли принудительно перекомпилировать процедуру перед выполнением?
2) если подойти к решению проблемы с другой, более правильной стороны:
как оператором INPUT INTO загрузить из DBF некое фиксированное подмножество полей таблицы?
...
Рейтинг: 0 / 0
26.09.2006, 17:59
    #34013686
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
Можно попробовать или грузить данные во времянку, а оттуда куда нужно раскидывать. Второй способ - вместо загрузки через INPUT попробовать подцепить удаленный сервер на DBF и оттуда тащить данные через прокси таблицы.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
26.09.2006, 18:01
    #34013693
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
Ну вдогонку уж третий способ - внутри хранимки организовать времянку, через динамический SQL загнать в нее данные и далее работать с ней.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
26.09.2006, 18:17
    #34013725
A.K.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Непонятное поведение внутри процедуры Transact-SQL
ASCRUS
Еще раз огромное спасибо. Думаю, наилучший вариант - через прокси-таблицы.

P.S.: эээх, сюда бы SQL*Loader, и без всяких гетерогенных сервисов, ... тьфу, прокси-таблиц бы обошлось. :-)
...
Рейтинг: 0 / 0
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Непонятное поведение внутри процедуры Transact-SQL / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]