Добавление финансовых аналитик в Оракле..

[MironovI]

Письмо дедушке Дамгарду и дедушке Ораклу..

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

Вторая фича, может быть связанная с некими настройками оракла - почему-то все условия в запросах выглядят вот так where SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER(:in1)) - т.е. ищется вхождение строки и все переводится в нижний регистр.. пока мне это не мешало, но тут выяснилось что с groupby(ItemId) дед Дамгард поступает так же, - возвращается все в нижнем регистре, и в отчеты так же и попадает в нижнем..

Пытаюсь глушить эмоции

[RVS]

Это вопрос? Или крик души?

[MironovI]

Наблюдения.. поскольку конкретныйх вопросов тут не поставить даже, напрашивается только вывод - не пользовать Оракл.. Мож кому поможет с выбором субд..

[RVS]

Цитата:

Загружаю проект в котором добавлены две финансовые аналитики

Что это за проект такой, интересно... Добавление аналитик хорошо описано в доке под названием AddDimensions.doc (есть на дистрибутиве Ax 3.0 CIS, например). Просто берете и добавляете...

Цитата:

Если удалить данные из таблицы - то она наконец синхронизаится.. но это не выход.

Выгрузить данные (средствами Axapta), синхронизировать все, что нужно, загрузить данные обратно - не катит?

Цитата:

Вторая фича, может быть связанная с некими настройками оракла...

Я бы RTFM почитал в подобном случае...

Цитата:

напрашивается только вывод - не пользовать Оракл...

Сильное заявление

[maximus]

Цитата:

напрашивается только вывод - не пользовать Оракл...

Поделитесь сокровенным, зачем Оракл используете? Обычно так делают потому как SQL-ная база дохнет на объемах. В таких случаях или на хранилище переходят 64 разрядное, или Оракл пользуют. Но от того, что отчеты кривые SQL живей не станет..

[MironovI]

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

[MironovI]

А по поводу выгрузить таблицы и снова загрузить - стандартными средствами выгружать нельзя точно - Recid при загрузке будут другие уже, хоть Best Practice нам кричит о том что связи по таблицам строить на Recid нетребо - в стандартном функционале таких связей туча.. можно было бы трансфером выкинуть куда-нить в соседнюю базку, потом обратно, но я лично делать это на рабочей базе побоюсь, к тому ж это базу останавливать придется, пока что упала все го лишь тестовая )

[RVS]

Странно все это... И вообще, если хотите инфу получить - опишите ситуацию. Версия Axapta, список ошибок... Тогда можно будет что-то по делу сказать. А так - "тема ... не раскрыта"

[MironovI]

Хе.. что Вам даст информация о том какой у меня сервис пак? Не знаю.. насчет вопросов пожалуй есть один - сейчас у меня в базе пять аналитик, но при синхронизации таблицы допустим LedgerJournalTrans она мне выдает (текст ниже) что не может дропнуть(!) пятую аналитику.. мало того что она ее не создала, так еще и убить пытается - совсем озверела

Error Синхронизация Невозможно выполнить команду языка определения данных в '' ('').
База данных SQL обнаружила ошибку.
Info Синхронизация Описание ошибки SQL: ORA-00904: "DIMENSION4_": недопустимый идентификатор

Info Синхронизация Оператор SQL: ALTER TABLE INVENTJOURNALTRANS DROP COLUMN DIMENSION4_
Error Синхронизация Ошибки во время синхронизации базы SQL со словарем данных системы.
Операция закончилась неудачно.
Info Синхронизация Синхронизация 1 таблиц закончилась неудачно

[Андре]

Цитата:

Описание ошибки SQL: ORA-00904: "DIMENSION4_": недопустимый идентификатор

ORA-00904: string: invalid identifier
Cause: The column name entered is either missing or invalid.
Action: Enter a valid column name. A valid column name must begin with a letter, be less than or equal to 30 characters, and consist of only alphanumeric characters and the special characters $, _, and #. If it contains other characters, then it must be enclosed in double quotation marks. It may not be a reserved word.

Цитата:

ALTER TABLE INVENTJOURNALTRANS DROP COLUMN DIMENSION4_

Смотрите определение этой таблицы в Аксапта. Смотрите определение этой таблицы в Oracle. Ищите различия. На основании различий делайте выводы. Может быть данные временно придется выгрузить. Выгрузить можно и средствами oracle - если в этот момент никто с системой не работает.

[RVS]

Мдя... Забавно у Вас (с)

Пробуем думать:

Синхронизация занимается тем ровно, что приводит в соотвествие определения (структуру) объектов в базе данных (SQL, Oracle - без разницы) с их, объектов, определениями в АОТ.

Таким образом, попытка удалить Dimension4_ означает 2 вещи:
- в AOT этого измерения уже нет.
- в базе данных оно есть (так считает Axapta)

Ошибка, возникаюшая при попытке удаления колонки, означает, что на самом деле в базе этой колонки нет...

Ну и что, казалось бы? База соответствует определению в AOT... Все славно... Что Вас смущает?

[MironovI]

Смущает то, что никакими ухищрениями теперь таблицу не синхронизовать - если аналитику удалить - то акса пытается ее честно удалить и выдает эту ошибку.. ладно, пробую добавить аналитику и... вот самое забавное - она опять пытается ее УДАЛИТЬ.. с какого.. не пойму, и как ее обмануть чтобы у нее мозги вправились тож пока не придумал.. хотя.. эврика! Можно же ее ручками добавить в таблицу, тогда мож ей полегчает при синхронизации, так кажется выход найден..

[Wamr]

Хочу всем напомнить, что Аксапте наплевать на структуру БД Oracle (впрочем как и MS SQL)!
Аксапта уверена, что структура базы соответствует информации в таблице SQLDictionary, и именно, исходя из различия этой таблы и AOT строит свои запросы по реорганизации БД.

[MironovI]

Цитата:

Изначально опубликовано Wamr
Хочу всем напомнить, что Аксапте наплевать на структуру БД Oracle (впрочем как и MS SQL)!
Аксапта уверена, что структура базы соответствует информации в таблице SQLDictionary, и именно, исходя из различия этой таблы и AOT строит свои запросы по реорганизации БД.

Кстати да, ценное замечание.. И на этом же оракле я пару раз сталкивался с самопроизвольным (это конечно еще вопрос..) рассыпанием этой таблицы, которое благо пока лечилось энным количеством запусков синхронизаций с проверкой.. Видимо кривизна связки Оракл-Аксапта кроется тут..

[MironovI]

Спасибо всем кого потревожил - вот такой незатейливый скриптец помог вправить мозги Ахапке, акбар как грится..

delete from sqldictionary where sqlname = 'DIMENSION4_'

[maximus]

Цитата:

А по поводу выгрузить таблицы и снова загрузить - стандартными средствами выгружать нельзя точно - Recid при загрузке будут другие уже, хоть Best Practice нам кричит о том что связи по таблицам строить на Recid нетребо - в стандартном функционале таких связей туча.. можно было бы трансфером выкинуть куда-нить в соседнюю базку, потом обратно, но я лично делать это на рабочей базе побоюсь, к тому ж это базу останавливать придется, пока что упала все го лишь тестовая )

Вот не помню такого.. Есть совет, что все поля recid должны иметь тип RefRecId и именно сцелью предотвращения смены recid при загрузке. Иначе система не считает его recid и связи по нему не постоит. Бред конечно.. но делать приходится.

Если бы таблицы в Аксапте были связаны по RecId скорость работы базы возрасла бы в разы (числовое поле против символьного).

[MironovI]

Эпопея продолжается, SqlDictionary я мозги вправил, но - у меня лицензия на 15 аналитик а при синхронизации акса заявляет "Слишком много элементов в типе Dimension".. , хочу пеерзагрузить личензионный файл - это не повлияет на настройки ConfigurayionKey интересно? Вроде не должно..

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

[RVS]

Вот ответ (косвенный)
http://www.axforum.info/forums/showt...&threadid=4183

А вообще - было письмо от MSBS, с год назад примерно, на ту же тему.
Количество аналитик ограничено допустимым количеством полей в индексе и наличием сложных индексов, в которые входит Dimension (о как )

[maximus]

А у Вас случаем мониторинг SQL запросов не включен?

[MironovI]

Цитата:

Изначально опубликовано maximus
А у Вас случаем мониторинг SQL запросов не включен?

Вообще выключен, а чем чревато?