VadimSokhaНа тот момент, когда я описал в этой эхи глюки , как раз , iAnywhere открывала кейсы багов:)
Я в курсе куда сообщать, но уж если о багах, то один баг iAnywhere не хочет признавать, как я ни старался:(
Ситуация:
В процедуре коннекта создается переменная через CREATE VARIABLE.
В таблице есть исчисляемое поле посредством функции
В этой функции есть обращение к этой переменной
В случае RECOVERY(потеря базы) - накатка лога на бекап, накатка не выполняется:(
iAnywhere говорит, что это фенечка, мол , во ремя накатки лога такая переменная не создается.

Но факт "на носу": Работать так можно, а вот восстановить базу стандартными средствами - нет.
Да и для "фенечки" больновато...
Это есть в АСА 9...есть ли это в АСА 10 и 11, как вы можете догадаться - не проверял.
Все правильно они говорят. Вычисляемое поле вычисляется только в момент записи, а потом это значение просто хранится. Но в момент накатки лога, сервак будет опять же выполнять все операции изменения и вставки полей, но только под внутренним коннектом, где естественно ни о какой переменной не слышали. Поэтому лучший способ победить проблему ... это в функции проверять, есть ли такая глобальная переменная. Тогда восстановление базы без проблем пройдет ;) А еще лучше не ссылаться на собственные функции и тем более глобальные переменные в вычисляемых полях, все таки для этого есть вьюверы :)

P.S. Биллинг у нас шустрит на 10-ке с космическими скоростями, огромными обьемами и без каких либо падений. 11-ую я как то раз увидел, удивился, скачал, поюзал - так как мне полнотекстовый поиск особо не нужен пока, а заново золотой диск покупать работодатель не будет, оставил ее в дистрах. Планировал, что если фирма наберет обороты, перейдем на 11-ую в след году, теперь вот ищу работу и соотвествующе с 11-ой получается полный облом :(

Ggg_oldРад видеть ASCRUS'а снова на форуме! Давненько не было видно.
Спасибо :) На самом деле как читатель я периодически присутствую на форумах скуля. Сейчас, пока ищу на замену работу, появилось немного времени побыть писателем ;)

dime11Здравствуйте!Сервер ASA 11.0.1 Developer Edition. При выполнении select max(ID)+1 from table оптимизатор неправильное направление сканирование первичного ключа, вместо backforward используется forward (при необходимости вышлю Plan). Таблица Table (ID numeric(10) primary key,Name varchar(250)) содержит 5324010 записей. Но же запросе под ASA 9 Developer Edition оптимизатор выбирает правильное направление сканирование. Кто может разъяcнить некорректную работу оптимизатора в ASA 11.0.1 Developer Edition.
Скачайте и накатите последний EBF для 11.0.1. Вполне возможно этот баг уже исправлен.

dime11ASCRUS,
Сладывается впечатление что это урезанный оптимизатор для Developer Edition.
Это уже домыслы ;) У девелопер вообще ничего не урезано, а урезанный оптимизатор - это нонсенс :)