Давно заметил, что в момент первого деплоинга OWB просит зарегистрирывать "Oracle Location", которая характерезует расположение Target схемы.
Так вот выбрасывает он такое окно

http://wheel.kiev.ua/~klf/img1.jpg
прописываем в нём 1. имя целевой схемы 2. Пароль 3. И имя сервиса 4. Ствим хост и OK. Деплоим и всё ок. Но если во время введения данных допустить ошибку - то диплоинг не состоится. А исправить настройки регистриции непонятно где . Единственный выход - удалять Runtime Repository Connection и создавать новый - уже с другим названием. Заходить в него и уже внимательно заводить инфу для регитсации локации . Эта фича у OWB ещё с 9 ветки. . .

Внимание вопрос - может кто знает как это лечить ? Например, где может хранится эта инфа и как её поправить или вызвать наново это окно ?

Спасибо.

Parkhomets AndreyДавно заметил, что в момент первого деплоинга OWB просит зарегистрирывать "Oracle Location", которая характерезует расположение Target схемы.
Так вот выбрасывает он такое окно

http://wheel.kiev.ua/~klf/img1.jpg
прописываем в нём 1. имя целевой схемы 2. Пароль 3. И имя сервиса 4. Ствим хост и OK. Деплоим и всё ок. Но если во время введения данных допустить ошибку - то диплоинг не состоится. А исправить настройки регистриции непонятно где . Единственный выход - удалять Runtime Repository Connection и создавать новый - уже с другим названием. Заходить в него и уже внимательно заводить инфу для регитсации локации . Эта фича у OWB ещё с 9 ветки. . .

Внимание вопрос - может кто знает как это лечить ? Например, где может хранится эта инфа и как её поправить или вызвать наново это окно ?

Спасибо.

Поправка - лечится не пересозданием RRC а пересозданием Oracle Locaton

Andrew IFЕсли необходимо сменить имя схемы, то мой способ не подходит. Но, например, мне обычно приходися менять сервер и пароль, а имя схемы величина постоянная.

Да нет- проще сменить имя локации - с новыми настройками - а старую грохнуть. Т.е. зарегистрирывать свой дизайн как-бы для новой таргет схемы - но насам деле новая только регистрация. Вот бы найти где он хранит эти регистрации.... - а там ручками....

Andrew IFИМХО это относительно несложно.

1. Посчитать количество строк во всех таблицах дизайн и рантайм репозиториев.
2. Создать location.
3. Посчитать количество строк во всех таблицах дизайн и рантайм репозиториев.
4. Сравнить что было и что стало.

Но это теоретически. Практически мне подобный подход не очень нравится. Кто сможет гарантировать работоспособность после вмешательства в репозиторий "ручками"?
"О боги ...." Ну ты ж сам говриш - сравниваем и делаем вывод, смотрим на тригера и связи с другими таблицами - локализируем задачу и всё. Вот вам и гарантия. Но возюкатся с ютим не желания и времени. это имхо TAR.