|
Как и обещал - привожу способы решения задачи.
Итого:
При сохранении таблицы, вся она сохраняется в текущем слое. Итак, проблема в приложении. Таблицы переехали в 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
;-)
|