itsepainen

We've got a situation when we need update some data at production database. Project manager decided it takes too much time of Java developers to change current code model so he's made a suggestion to me about Apex application solving this problem. OK, though I've got a problem from the start: Apex is installed not in production server and I have to execute procedure which makes some data manipulation at production server.

What have I done?

With the help of DBA I've created:

1. A main function (at PRODUCTION server) which executes DML and produces some checks, error handling etc;
2. Brand new DB-user (at PRODUCTION server) which gets privileges to execute that function only;
3. DB Link (at APEX server) which connects to that new user (and so gets access to that function only);
4. Synonym (at APEX server) which makes name of the function a little bit shorter :)

Then I've just developed a little APEX-application which sets some UI-parmameters, runs the function with these parameters and then handles the result returned by function.

Very important thing is to not commit the transaction within function body (beacuse of db link it raises ORA-02064: distributed operation not supported)

I suppose one more security risk is that fact we can look the function code at APEX server though the function is actually at production server. However, we may wrap it.

Brand new error for me using AnalysisServices: 

Since this post, I've decided to write in English, maybe it will be more helpful all over the world :-)
So, some time ago I've created nice PL/SQL package for reporting from standard data scheme of a famous bug-tracker JIRA. Also it contains some good tricks for to work with date parts extraction. Hope this will be useful for someone.
( Code... )
You may (and you should! :-) ) change code anyhow you would like to. These samples are adopted for real working situation and  not try to pretend for common decision as well.

Also you may feel free to ask me for any questions about this code in comments.
Regards :)

ADD_MONTHS(LAST_DAY(SYSDATE), -TO_NUMBER(TO_CHAR(SYSDATE, 'MM'))) + 1

Вот таким извращённым способом я беру первое число текущего года для параметра по умолчанию в DatePicker на странице в Апексе. Есть ли способ проще, готовая функция какая-нибудь?

Интересный коленкор: есть измерение, использующее тип связи между атрибутами Parent-Child. И в этом измерении допустим есть узел, у которого только один подчинённый элемент. По умолчанию свойство AttributeHierarchyVisible при создании измерения выставляется в True. И в таком случае при выборе среза с любой мерой будут показаны агрегаты только для этого самого подчинённого элемента, а значение агрегата для корневого элемента останется где-то между мирами.

Например, есть уровень Web, и у него есть листок Partner Sales. Продажи показываются только для Partner Sales.

Чтобы значения агрегата корневого элемента также учитывались для корневого элемента рядом с подчинённым, нужно сделать свойство AttributeHierarchyVisible = False ключевого атрибута измерения. Тогда значение агрегата для корневого элемента "как бы" будут отображаться рядом с подчинённым.

Update. Ну и конечно свойство MembersWithData выводимого атрибута, организованного по принципу Parent-Child, должно быть выставлено в NonLeafDataVisible. Это даже более важно, чем текст выше.

Наткнулся в процессе решения очередной попаболи на охренительный ресурс:
http://ssas-wiki.com/w/Articles

Столкнулся в процессе переливки данных из Oracle в MS SQL Server с такой вот сумасшедшей ошибкой ETL-процедуры:
Err in line:1:(8114)Error converting data type DBTYPE_DBTIMESTAMP to datetime.:

Данные из Oracle не хотели заливаться во временную таблицу MS SQL, хотя типы данных были с обеих сторон корректные и эквивалентные. Исследование показало, что в Oracle в некоторых кортежах в одном из полей с типом DATE находились весьма странные значения, которые как TO_DATE(some_date, 'DD.MM.YYYY') выглядели вполне нормально, но как TO_CHAR(some_date, 'DD.MM.YYYY HH24:MI:SS') показывали полный и адовый трэш типа "00-000-00". Что это - битый сегмент на диске, где лежит оракловая база или какой-то софтовый глюк, неведомо.

Выкрутиться удалось следующим образом:
вместо явного перекладывания из ораклового DATE в эмэсовский SMALLDATETIME пришлось конвертить дату в текстовую дату в формате ISO.

Было:
CAST(h.POLICY_PROPOSAL_DATE as date) as DT_PRE
Стало:
 TO_CHAR(h.POLICY_PROPOSAL_DATE,''YYYY-MM-DD HH24:MI:SS'') AS dt_pre

Таким образом, строгая типизация потерялась (чему я противился до последнего) и конвертация даты из ISO-текста обратно в дату была отдана на откуп SQL серверу, с чем он в принципе успешно справляется, и проблема была решена (но осадок остался). Главное, что всё работает.

Случилась следующая оказия: в один прекрасный день некий справочник оракловой OLTP-базы пополнился длинными значениями в поле "Название" (например, обычными значениями были варианты типа "Ром", "Виски", "Вода" и вдруг появились такие представители как "Кисломолочный пятновыводитель 1854 года закладки в винокурнях его Императорскаго Величества").

По не очень понятным (но, в принципе, объяснимым - новых продуктов на момент заведения справочника в хранилище не было и не предвиделось, хотя всё равно такое определение гниловато) причинам, табличка-приёмник на стороне хранилища имела тип по этому полю VARCHAR(10 CHAR).

В результате при процессинге измерения, построенного на вьюхе из этой таблички, естественно, вылезала ошибка, мол, данные усекаются и т.п.
ОК, расширил тип поля в принимающем справочнике, пересоздал на всякий случай вьюху, зашёл в проект куба, обновил там Data Source View, ринулся процессить, лезет ошибка и всё тут, короткое поле в измерении для такого типа данных. Прыгал-прыгал, а дело было вот в чём: помимо всего вышеописанного необходимо по крайней мере в проектах MSAS 2005 заходить в свойства атрибута соответствующего измерения, который отвечает за вывод этого поля и там ручками, ручками проставлять соответствующий новой реальности размер данных для поля атрибута (после обновления DataSource View он, сволочь, не изменяется). На картинке ниже результат уже успешной манипуляции, изначальное значение равнялось 10.