Осторожнее с CTRL+S на таблицах

[mit]

Используем 3.0 сп 3 c Citrix, так как комбинация клавиш на переключение раскладки одинакова, иногда происходит "залипание" CTRL-а. Это предыстория. История: в АОТ раскрываю ветку таблиц, и с залипшим CTRL набираю sales. При этом, происходит следующее: на "a" - выбираются, как и положено все таблицы, дальше - на каком то из символов "l" или "e" или "s" система уходит в себя, и не возвращается. Все пользователи начинают получать сообщения:

Error Сообщение (19:59:03) Невозможно выбрать запись в 'SysSetupLog' ('SysSetupLog')База данных SQL обнаружила ошибку.
Info Сообщение (19:59:03) Описание ошибки SQL: [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name 'DATAAREAID'.
Info Сообщение (19:59:03) Оператор SQL: SELECT A.VERSION,A.APPBUILD,A.KERNELBUILD,A.DESCRIPTION,A.NAME,A.RECID FROM SYSSETUPLOG A(INDEX(I_1518KEYIDX)) WHERE ((DATAAREAID=?) AND (((((VERSION=?) AND (APPBUILD=?)) AND (KERNELBUILD=?)) AND (NAME=?)) AND (DESCRIPTION=?))) OPTION(FAST 2)

ок, выходим, заходим. Результат - система спрашивает, как зовут, открывает главное меню, и все. Дальше наблюдаем песочные часы и обмен с сервером. попытка вызвать дебагер ни к чему не приводит. не помогают рестарт АОСа, рестарт SQL, удаление индексных файлов - все безрезультатно. Визуально в таблицах данные как будто целы. Захожу толстым клиентом - куча ошибок. Толстым под админом - УРА! пустила! Синхронизируем, перезапускаем - появился контрольный список обновлений. Как пройду - обязательно напишу что получилось

з.ы. попробовал на еще одной версии, вуаля! фокус получился! у меня 2 порченые базы!

[Vadik]

Простите, не мог удержаться:

[АНЕКДОТ]
Юзверь:
З
д
р
а
с
т
в
у
й
т
е
,

у

м
е
н
я

з
а
п
а
л

E
n
t
e
r
,

ч
т
о

д
е
л
а
т
ь
?

Минут чезер пятнадцать ответ:

Служба поддержки: Попробуйте его вытащить.

Юзверь: СПАСИБО ОГРОМНОЕ, ВЫ НЕ ПОВЕРИТЕ, ПОКА ВЫТАСКИВАЛ ENTER, ПОДДЕВАЯ ЕГО ОТВЁРТКОЙ, ЗАПАЛ SHIFT. КАК ВЫ ДУМАЕТЕ, CTRL ЗАПАДЁТ, ЕСЛИ Я БУДУ ВЫТАСКИВАТЬ SHIFT?

Служба поддержки: Попробуйте с другой стороны.

Юзверь:
Б
л
и
н
!
!
!
[/АНЕКДОТ]

Антиоффтопик: вы зависшую по Ctrl+S аксапту срубали или она сама завершалась? А то смотрю, как trcAxaptaError.log наполняется записями "Invalid object name 'TMPINFOLOG'" (что само по себе странно - таблица-то временная) и думаю - зациклилось или подождать еще немного?

По поводу ошибок на системных таблицах предувствия самые что ни на есть мрачные

[mit]

да, АНЕКДОТ в тему :-)
Вы получили такой-же результат?
Минут через 10 - снял задачу.

[Vadik]

пытаюсь войти двухуровневым клиентом
он тоже валит в лог ошибки на TMPINFOLOG
открыл AOT - все таблицы изменены на USP слое (сам сижу на USR)

[mit]

У меня таблицы все изменены на юср слое, где и работал. удалил из юср 'TMPINFOLOG', теперь
не могу открыть форму лицензионных условий - недостаточно прав.
Похоже что испортилось приложение. при сохранении все таблицы
переехали в верхний слой.

[George Nordic]

Друг мой!

Мы тоже работаем в Ax3.0 sp3 + Сitrix. Но вот разработку ведем просто тонким клиентом. Мне кажется, что не стоило так рисковать...
Во всяком случае, большое спасибо за предупреждение - а то с терминалов, когда приходиться что-то подправить, ситуация вполне может и повториться.

С Уважением,
Георгий

[mit]

2 George Nordic
разработку мы не ведем, потребовалось посмотреть на данные

2 All
после перекомпиляции многие формы стали рабочими, на некторых стало нехватать прав. Как писалось выше, все таблицы переехали на самый верхний слой, что в общем то логично, так как таблицы в отличие от классов полностью переписываются в сохраняемом слое.
Удаление таблицы из usr приводит к ошибке и закрытию приложения, но таблица при этом из слоя usr удаляется. т.е. всего пару тысяч перезапусков
еще одна особенность - у некоторых таблиц невозможно посмотреть свойства, у некоторых при открытии узла с индексами - так же вылетает.
Что буду делать - вновь собирать приложение.

вскоре мы продолжим наш репортаж, продолжение следует

[mit]

Как и обещал - привожу способы решения задачи.
Итого:
При сохранении таблицы, вся она сохраняется в текущем слое. Итак, проблема в приложении. Таблицы переехали в usr, но не доехали. Поясню. В результате загадочно выставились права на таблицы (вернее свойство ConfogurationKey выставилось в неизвестное значение). Свойство таблиц просмотреть не удалось (в окне свойств приглашение развернуть узел для просмотра свойств элемента). Все таблицы - заимели свойства по умолчанию. т.е. Temporary = No или SaveDataPerCompany = Yes
Изменения коснулись только тех таблиц, которые на слое были нетронуты разработчиками.
Но по порядку. Запуск тонким клиентом - система дергает сервер, но меню не показывает, и песочные часы не прячет.
2 варианта:
1)У вас есть резервная копия рабочего приложения- смело доставайте, и пользуйте.
2)У вас нет резервной копии. Обидно, но поправимо. В таком случае ее нужно будет собрать. Заходим под 2-х уровневым. Делаем синхронизацию. Система теперь будет грузиться. Сборка заключается в перетаскивании в проект всего, чт о лежит в проблемном слое. Далее следует выгрузка этого проекта, и поднятие на чистом приложении. Экспорт всего слоя не помогает, так как при экспорте проблемных таблиц система валится. (Если ваше приложение требует немедленного запуска - можно пустить даже пользователей, в этом случае придется какое то время понаблюдать за системой. Некоторые формы не открываются, ссылаясь на недостаток прав на таблицу. Необходимо найти в репозитарии эти таблицы и удалить из слоя). Стоит обратить внимание, что все временные таблицы получили свойство Temporary = No, и появились в БД. Некоторые временные таблицы используются при запуске системы, и соответственно они очень быстро переполняются.
После поднятия проекта - синхронизация. Вылезут проблемы. Выявил 2 типа. Превый - если используется несколько компаний, и есть общие таблицы (наш случай) - систему раскорячивает от того, что индексы строятся по DATAAREAID и RECID. т.е после SaveDataPerCompany = Yes в таблице появилось поле DATAAREAID. В результате синхронизация не пройдет, пока не удалить все дублирующиеся данные. Если это таблица каких ни-будь логов, и данными можно пожертвовать - удаляем всю таблицу (при синхронизации она будет вновь создана).
Второй - это у таблицы появилось дополнительное поле. Таблица работала нормально, но синхронизация не проходила. Решением было в таблице "AOD\System Documentation\Tables\SqlDictionary" удаление этого поля(кстати Id у него был 20000)
Все. перестройка индексов и компиляция.
Но лучше - не нажимать Ctrl+A & Ctrl+S
;-)