Ptn
Ибо вот с чего бы это запросы с использованием двойных ковычек в 5.2 да и в 5.1 не компилируются ?

Да, та еще фича :-) Кажется связана была с принятием/изменением какого-то стандарта SQL.
Хорошо, где запросы еще компилируются их сразу видно, а если динамичесикий-там вообще труба.
Когда вылезет, не знаешь.

Но это полбеды. А вот то, что в хранимых процедурах дата по умолчанию в ODBC формате - это вообще непонятно зачем изменили.
Да и команду перевода формата в числовой режим в Developer Reference найти не получилось.
Нашел уже не помню где (кажется $ZU(115) )

Там еще проблемы были, например каше 4 плевала на декларации типов в методах, да и много чего в каше 4 было менее строго, в каше 5 все такое вылезло как ошибки.
Еще было наследование csp от persistent класса, в каше 4 работало, каше 5 ругается матом (но не ошибку наследования, а то, что не может создать структуру хранения, то ли на то, что не может сделать OnSave, не помню уже) :-)
Много подобного видел.
Здесь есть логика и это просто нужно исправить.

Есть проблемы, не связанные напрямую с миграцией, например зацикливание при создании очереди компилляции:
Классов около 300 без учета csp, все они друг на друга ссылаются всяко-разно (наследование, свойства и т.д.). Если скомпилировать всю базу или достаточно много классов, то при изменении некоторых и попытки компилляции выдется сообщение "класс A устарел", компилишь класс A - говорит "класс B устарел", компилишь класс B - говорит "класс A устарел".
Бился головой об стену, просил помощи в Intersystems - в итоге их представитель перестал отвечать на письма. "Полечилось" удалением глобала oddDEP, теперь всегда после такой ошибки советую делать команду k ^oddDEP.
Но разве это нормальное решение проблемы? Тем более один раз чуть не нажал k ^oddDEF :-)

Ptn
Лазить по всему коду и ковычки менять ? Или есть секретная функция включения легаси режима ?
Я надеюсь, что функции включения совместимости не было, иначе слишком обидно было бы за проделанную работу :-)

Раз проблема с кавычками решается так просто, может быть, есть красивое решение с "устареванием" классов?
А то как-то это совсем некрасиво - удалять системные глобалы.

Флаги компилляции пробовали всяко-разно.
Дело то не в том, что они действительно устаревают - как раз ошибка начинается поле CompileAll,
причем принудительно (-u) и успешной.
То есть так не может по идее ничего устареть, все скомпилировано. Тронешь пару классов - и начинается, причем может говорить "устарело" на классы, которые не изменились с момента компиляции.

Наследование там есть многоуровневое и множественное тоже. Это из-за него?

автор>>Наследование там есть многоуровневое и множественное тоже ?

Из-за него раз.
Из-за флагов компиляции (r,y,b) два
Из-за CDLфлагов System три.
Советую компилять из терминала по проектам.


Флаги компилляции очень вряд ли. Пробовали и принудительно, и не компилировать неустаревшие, и компилировать связанные и без них. Системные флаги компилляции ведь имеют меньший приоритет, чем указанныев командной строке?

Проекты компилить - не дело, потому что это очень долго. Представте себе компил по проектам, где всего 300 классов и после каждого изменения бывает нужно откомпилить класс?

Проект очень связный, сложно разделить его на куски.
Тем более проблема не в устаревании, а в зацикливании, то есть класс А не компилит, потому что устрел класс B, а класс В не компилит, потому что устарел класс А.
Притом что ни тот, ни другой в компилляции не нуждаются на мой взгляд.

Их всегда парами- тройками компилить? А скомпилишь один, она цепляет к нему еще несколько "устаревших".

А ведь результат опроса опубликован!

http://www.intersystems.ru/inews/surveycache2007/index.html