К сожалению я слабо помню эту полемику. Если не ошибаюсь Ваше решение не работало для многих других пользователей, многие из которых не менее рьяно отстаивают свои потребности. Если не сложно опишите более подробно проблему и вариант ее решения с Вашей точки зрения. Мы внесем необходимые изменения для ее решения в наш код.
У меня нет своего собственного решения какой-то проблемы, поскольку работа с SQL-сервером не является проблемой в принципе. Есть некоторая данность - и всё. Поясняю. Текст запроса является черным ящиком для всего и вся кроме
человека и
SQL-сервера. Существует великое разнообразие SQL-серверов, реализующих свои расширения языка SQL, и ваша попытка парсить запрос, чтобы
помочь пользователю за него решить, что он там написал, заведомо провальна! Иначе вам придется реализовывать логику парсеров всех поддерживаемых вами SQL-серверов (я не знаю, что делать с универсальным ODBC-источником данных).
Человек может взять на себя ответственность и сказать
вам (не серверу), что у него в запросе -
имя процедуры. И тогда
вы можете попытаться
запросить у сервера параметры указанного пользователем объекта базы. Потом только лишь из имени процедуры создается (провайдером данных) обычный запрос и скармливается серверу. Естественно, когда объекта базы нет, и
запрос является просто текстом, то вы никогда ниоткуда не сможете узнать, какие параметры в тексте задумал пользователь. Только пользователь руками может указать, какие параметры и их типы должны создаваться для команды. Результат же выполнения запроса к серверу вы не сможете предсказать никогда, поскольку
и процедура, и запрос прямым текстом могут вернуть абсолютно разные выборки, которые будут зависеть от параметров, контекста, даты, времени... чего угодно! И
только пользователь способен в дизайнере указать именно те параметры, при отработке запроса с которыми выборка будет содержать тот набор полей, что и при дальнейшем использовании в боевых условиях. Вы никогда не сможете однозначно угадать значения параметров для вытягивания метаданных результата, поэтому при автоматическом заполнении полей значения параметров должны браться те, которые указаны в дизайнере пользователем. Нет никакого смысла спорить с этими утверждениями и ссылаться на обратную совместимость, ибо
это - физика процесса. Необходимо просто сделать опцию и
дать возможность использовать правильное поведение.
Что получается у вас? Вы начинаете решать, что там написал пользователь. Путаете параметры с переменными, смущаетесь большинства способов вызова процедуры и тому подобное. И в итоге валятся глупые исключения про необходимость объявить скалярную переменную, что-то про неверный аргумент функции substring, ненужные поля из-за каких-то навеяных вам значений параметров и т.п. Реально, мне не удалось создать источник данных с классическим способом формирования запроса! Всё только через конкатенацию строк - частей запроса и параметров, что приводит к проблемам другого рода (из-за которых, как мне кажется, и были придуманы параметры). Речь о спец. символах, атаках SQL-injection и других гадостях. То есть, ваш генератор отчетов фактически вынуждает разработчиков зачастую создавать дыры в безопасности сервера (при ненадлежащих указания прав это именно так!).
В связи с наличием старых пользователей, которые налабали отчетов тяп-ляп, используют ваши "фичи" и рьяно отстаивают на них свои оплаченные законные права, мне хочется, чтобы (опционально) все ваши аналитические инициативы могли отключаться, и чтобы работа с СУБД осуществлялась по нормальным разумным правилам, давно реализованным во всех провайдерах данных, будь то .NET провайдеры, OLE DB, ODBC или еще какие-то. Там, прошу заметить, никто не посягает на реализацию сверхинтеллекта и не пытается конкурировать с парсерами СУБД, хотя времени на усовершенствование было предостаточно. Насчет конкретных приемов использования всего этого - могу кинуть ту программку еще раз, хотя всё есть в документации (просто там необходимый и достаточный для вас функционал).
Пожалуйста, вдумайтесь в выделенное жирным. Это важно.
К сожалению это невозможно исправить в движке EngineV1. В EngineV2 все работает верно.
Не в курсе насчет движков
А откуда берет начало EngineV2?
Пришшлите пожалуйста mdc файд для этого отчета мы проверим еще раз. Также необходима пара скриншотов как это выглядит в Xp и 2003.
Шаблон любой. Один и тот же отчет
строился в этих двух операционках (версия SR одна). Но результат оказался различным. В содержимом нашел разницу, которую указал. Особо сказать больше нечего.
