Привет всем.

Имею такой код:


В результате meta==null. В примерах обычно метадата берется после выполнения, но я хочу выяснить изменяемые параметры, чтобы выдать соответствующие registerOutParameter. Это возможно вообще?

Спасибо, исчерпывающий ответ :-)

База - Oracle 9+, родной драйвер.

Оказалось, что ResultSetMetaData пусто и после выполнения. В чем грабли? Нужно что-то указать уровне Connection или Datasource?

Ачипятка:

CallableStatement stmt = conn.prepareCall(sql);
ResultSetMetaData meta = stmt.getMetaData();
-----

Спасибо, нашел ParameterMetaData и сам, но Oracle дает только getParameterCount(). Т.е. он ВООБЩЕ не может дать более подробно? Или нужно другой класс драйвера указать? DD не годится, нет его у меня.

Ты о родных дровах говоришь или датадиректовских? Родные возвращают ParameterMetaData, но ни один метода там не имплементирован. Или у тебя другая информация?

Timm Сэмка
Спасибо, нашел ParameterMetaData и сам, но Oracle дает только getParameterCount(). Т.е. он ВООБЩЕ не может дать более подробно?
пнятно, оказываеццо не реализовано.
с другой стороны - в общем случае типы параметров в jdbc до выполнения (без разбора statement'a на клиенте) определить в принципе невозможно.

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

Это анонимный блок, в чистом JDBC используется конструкция { call <хранимая процедура> } и мне именно это и нужно. Могут быть, конечно, трудности с оверлоудингом, но без оного противовоказаний распарсить сразу нет. Ладно, придется использовать DatabaseMetaData.

Timm Сэмка Timm Сэмка
Спасибо, нашел ParameterMetaData и сам, но Oracle дает только getParameterCount(). Т.е. он ВООБЩЕ не может дать более подробно?
пнятно, оказываеццо не реализовано.
с другой стороны - в общем случае типы параметров в jdbc до выполнения (без разбора statement'a на клиенте) определить в принципе невозможно.

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

Спасибо, я в курсе, с Oracle 13 лет, поэтому и представляю прекрасно, что не сделано это исключительно из лени :-). DBMS_SQL справлялся с этим прекрасно еще в Oracle 6 (думаю, даже раньше). "Лайки" не сильно страшны: при отсутствии спецсимволов они чудесно превращаются в "равно" еще до выполнения. Странная вообще штука: родной драйвер не делает того, что 3-d party. Абыдна, да?

Timm СэмкаЭто анонимный блок, в чистом JDBC используется конструкция { call <хранимая процедура> } и мне именно это и нужно. Могут быть, конечно, трудности с оверлоудингом, но без оного противовоказаний распарсить сразу нет. Ладно, придется использовать DatabaseMetaData.

Ну и что?
Любой вызов в конечном счете превращается либо в SQL, либо в анонимный PL/SQL блок. другого не дано.
С DatabaseMetadata.getProcedureColumns я думаю надо бы поосторожнее - обращается в all_arguments, в условиях почти везде используются like :x.

Timm СэмкаСпасибо, я в курсе, с Oracle 13 лет, поэтому и представляю прекрасно, что не сделано это исключительно из лени :-).
Насчет параметров процедур - категорически не согласен. Это просто бессмысленно.
СэмкаDBMS_SQL справлялся с этим прекрасно еще в Oracle 6 (думаю, даже раньше)
Пример в студию, для такого вызова: begin :x:=:y+1; end;
СэмкаСтранная вообще штука: родной драйвер не делает того, что 3-d party. Абыдна, да?
Нисколько.

Ладно, с dbms_sql погорячился, давно не пользовался :-). Но где связь между параметрами процедур и связанными переменными анонимного блока ??? Последний компилируется перед выполнением, о нем ничего не известно и все параметры потенциально in out. Т.е. в моем случае это вообще не интересно.

То, что вызов конкретной хранимой процедуры превращается в выполнение произвольного анонимного блока - вопрос реализации. Я уже показал выше, что прояснить параметры для конкретной процедуры возможно, вопрос - какой ценой.

ЗЫ Бесмысленность - дело такое, на кой говорить, что следуешь спецификации, если что ни метод - то not implemented? Это вопрос не смысла, а качества продукта.