|
|
|
xmltype проблемы форматирования и/или генерирования?
|
|||
|---|---|---|---|
|
#18+
открыли мне тут дивный мир типа данных xmltype для работы c dynamicSQL (работающим с переменным кол-ом столбцов в форме "табличного" результата) в виде sys_refcursor на объект. все здорово, но есть вопросы. и гугл с наскоку не порадовал.... Одно поле таблицы у меня - это NUMBER(4,2). Значением там, к примеру, "0,45". А вот после "превращения" таблицы в xmltype тип и его распечатке: "DBMS_OUTPUT.PUT_LINE(xt.getCLOBVal());" значением этого поля я вижу только ",45" - т.е. ведущий нуль исчез. КАК его вернуть? Похожая проблема с полем даты. В полученном xml - она полная, т.е. вида "DD.MM.YYYY HH24:MI:SS"? Хотя тут-то понятно - это полная форма для содержимого поля реального типа данных DATE из таблицы. НО я бы хотел получить только "DD.MM.YYYY". КАК это можно сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2016, 16:20:57 |
|
||
|
xmltype проблемы форматирования и/или генерирования?
|
|||
|---|---|---|---|
|
#18+
ПознающийКАК это можно сделать? to_char ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2016, 16:22:35 |
|
||
|
xmltype проблемы форматирования и/или генерирования?
|
|||
|---|---|---|---|
|
#18+
123ййПознающийКАК это можно сделать? to_char эмм. и где это можно вызвать? Код: plsql 1. вот так я получаю значение - оно там УЖЕ на выходе - просто строка ",45". Нет, конечно, со строкой можно много преобразований сделать, тот же ноль добавить... но смысл вопроса - как по дефолту, просто считывая значения из xmltype, получить строку с исходным значением "0,45" - таким, каким оно в таблице изначально видится и было внесено. Конечно, если отмену такого неявного преобразования сделать нельзя - ок, буду тогда строки парсить и "фиксить" на лету. Но странно, что в продукте зашита такая убогая логика, что число типа NUMBER (m,n) при переводе в XML надо сохранять БЕЗ ведущего нуля.... Скорее это какая-то настройка... чего-то, где-то... вот надо бы найти её. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2016, 16:46:35 |
|
||
|
xmltype проблемы форматирования и/или генерирования?
|
|||
|---|---|---|---|
|
#18+
ПознающийНо странно, что в продукте зашита такая убогая логика,Не отходи от зеркала. Познающийчто число типа NUMBER (m,n) при переводе в XML надо сохранять БЕЗ ведущего нуля...Советую смириться. В противном случае делать всё самому, без неявных преобразований xml-я. ПознающийСкорее это какая-то настройка... чего-то, где-то... вот надо бы найти её.NLS_* Что лишний раз подтверждает, что без году неделя с места в карьер ты бросился в дебри не понимая основ. Получится быдло-говно-кодище. Сорее неработающее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2016, 16:53:05 |
|
||
|
xmltype проблемы форматирования и/или генерирования?
|
|||
|---|---|---|---|
|
#18+
Elic, ну раз работает так КАК надо боссу и БЫСТРО - то всё всем нравится. NLS_* - я в курсе, что эти настройки есть, и в курсе, что они влияют на многие моменты работы функций оракла. НО вот что какая-то из поднастроек этой группы - может отфигачить напрочь ведущий нуль!? Эт я ни видел ни разу... И какая же ТОЧНО из поднастроек это может сделать? Или никакая - ибо это вшитая особенность "конвертации" в xml? Если так - то без сомнения это весьма нечеловечная реализация. Дату да - корректный NLS_* подправил для нужного мне вывода. Сенкс! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2016, 17:58:56 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=211&tid=1887867]: |
0ms |
get settings: |
6ms |
get forum list: |
26ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 328ms |

| 0 / 0 |
