Хех! А у меня похожая проблема, только с OLEDB.

Вызвать из отчёта функцию при ODBC подключении как раз получилось, именно благодаря этой теме (сплошные знаки вопроса в общем, жуть). Но оказалось, что ODBC весьма медленно работает при больших выборках. Поэтому решено было изучить как работает OLEDB.

И вот тут как раз загвоздка. Никак не могу найти какой синтаксис передачи параметров при вызовах процедур нужно использовать.

В результате вылезает:

автор** ERROR: Failed to parse statement: select *
from public."TestParameterGet" (TestString := @TestString, TestWord := @TestWord);

Как я только не пробовал. И "TestString := @TestString", и "TestString => @TestString", и просто перечисление параметров как у мс_сиквела (@TestString, @TestWord), и синтfксис ODBC.

А документацию найти тоже не могу. Поэтому прошу подсказать.

Оказалось, что синтаксис вполне стандартный, хоть и убогий. Почти такой же как в ODBC.


авторselect *
from public.TestParameterGet(?,?,?);

Где знаки вопроса - это параметры формы.

Почему не такой же, а почти? Потому что ODBC умеет распознать явное определение типа данных, а OLEDB нет!

авторselect *
from public.TestParameterGet(?::date,?::text,?::int);

Так OLEDB не может!

И вишенкой на торте, что по умолчанию все параметры считаются текстом... Т.е. по факту вы не можете использовать ничего кроме строковых параметров. Что делает использование OLEDB невозможным на практике, потому что большинство отчётов имеет среди параметров хотя бы одну дату...


В общем и целом вывод такой: если у вас есть хотя бы малейшая возможность избежать использования связки SSRS + Postgres воспользуйтесь ею.

P.S. Так же ODBC не понимает кавычки в имени сущности!


т.е. сделать

авторselect *
from "MyFunction" (?, ?)

не получится. Со всеми вытекающими.

Технически ничего. Но ввод данных, форматируемых на стороне клиента, придуман не зря. Люди же будут косячить неизбежно.