Здравствуйте!
Подскажите пожалуйста, можно ли загружать данные из базы данных Оракл (из таблиц или представлений) без конвертирования данных например типа Number в Varchar2? Т.е. если у меня столбец например Цена имеет тип Number, то наши специалисты говорят что для того чтобы загрузить это в BW, обязательно нужно сделать этот столбец типом Varchar. Так ли это? Блин, ну не верю я в такой бред.

Преобразование типов можно сделать и на стороне BW(например в правилах переноса) и в оракловой вьюхе. Проблема наверное в том, что BW-никам как и Вам не хочется лишней работы ))

Дак я признаюсь что мне просто лень это делать. Но наши специалисты говорят что так сделать нельзя.

полный бред.. так сделать МОЖНО!

2 unique_saper
Мое мнение аналогично. Ну не может такого быть... Стоит задуматься о квалификации наших работников.

2 unique_saper
А как же быть с датами и русскими буквами? Разве их тоже можно без преобразования на стороне Oracle?
(вместо русских букв приходит ППППП, а даты приходят типа: -0.AN.20-J)
Если смотрим ноту 518241, то там как раз написано про преобразование.

каюсь, с русским не приходилось работать..

Интересно, русский язык удалось победить? В ноте 606359 написано, что САП не рекомендует использовать DB connect, если кодовые страницы различаются...

По поводу проблемы с русским шрифтом при импорте из Оракла - читайте ноту 808505. Если кратко - в инфо по соединению нужно прописать
TNSNAME:CHARSET:NCHARSET. Может помочь.

А что, вьюху в Оракле сделать нереально? И кодировки там учесть...

З.Ы. Не судите строго, я не спец по ораклу. Больше по MSSQL.

Создавать вьюхи на стороне БД - неправильно.

Любопытно, почему вы так считаете? Может быть поясните свою мысль - в чем криминал создания вьюшек на стороне оракла, чтобы из них тягать нужные данные?

Постараюсь объяснить. Вообще это не только к ораклу относится, а к любой БД. Администратор (если он толковый) вряд ли пойдёт на то, чтобы усложнять систему и создавать дополнительные сущности.
И это не проблема оракла в том, что САП система не видит некоторые объекты из-за специальных символов в имени или из-за того, что имя объекта больше 26 символов, кодировка корёжится, и т. д. и т. п.

Хм. Толковый админ говорите?

Знаете, есть бизнес - задача, по которой НАДО выгружать данные. И если бизнес - задача ТРЕБУЕТ создание дополнительный вьюшек, то либо админ будет выполнять требовния, либо доказывать свою толковость в другой компании.

Другое дело, что методы решения бывают разные. Естествнно, что если есть несколько путей решения, то надо выбирать тот, который наиболее надежен и прост в исполнении. И не факт, что создание вьюхи - единственно правильное решение. решения надо взвешивать и оценивать с разаных сторон.

Но если создание вьюшки/хранимой процедуры/таблицы в исходной системы - единственное решение, которое гарантирует правильность и своевременность передачи данных (не только сейчас но и через год два три и т.д.) - то не обессудьте, админ либо идет и грусно делает свою работу, либо идет и весело пишет заявление об уходе. Потому как от такого человека надо избавлятся сразу же, так как все таки не система для админа, а админ ОБСЛУЖИВАЕТ систему. И если бизнес - задача требует такого решения, то админ должен подчиниться.

2BW-ник
+1