Система бизнес-аналитики Stimulsoft | Форум

Здравствуйте.
Много раз общался с вами по поводу сабжа в ICQ. Невозможно быстро в дизайнере сделать источник данных - всё приходится прописывать руками (десятки возвращаемых колонок в частном случае). Параметры вообще не работают. В порядке вещей такие запросы (при живых-то параметрах): Даже программку специально для вас писал с правильным функционалом. Ну сколько можно? ГОДЫ идут, а воз всё там же (по-моему, первые полемики больше 2 лет назад были). Неужели я один полноценно использую СУБД, процедуры, реализую срочные "приляпки" прямо в отчете скриптами в тексте запроса и т.п.? Кто-нибудь!!! Ну скажите им, а.... Уже с горя на сайт FR лажу - жду их .NET версию. Хорошо, понимаю - обратная совместимость. В таком случае можно сделать настройку движка - чтобы было 2 варинта: 1) как считают правильным разработчики FR; 2) как считает правильным человек, делающий отчет (т.е. без встроенной "аналитики" (вместо парсера самого SQL-сервера) текста запроса и далеко идущих выводов). Нельзя же расчитывать только на людей, которые оперируют исключительно построителем запросов и конкатенацией строк, с трудом понимая, что получится в итоге. Это моя последняя мольба. Больше не буду. Ну нафик.

PS
До кучи сброшу неотвеченные посты по багам (апрель). Честно - сейчас не проверял (если поправлено - простите)

* при ненулевом расстоянии между колонками _страницы_ заливка DataBand "наезжает" на разделительную полосу между колонками

*в PDF, сгенерированном на XP sp2, шрифты ок
в том же самом отчете, экспортированном в PDF на Win server 2003 r2 (.net 2.0) шрифты получаются мизерного размера (примерно троечка)
экспериментировал с внедрением шрифтов и т.п. - безрезультатно

в одном:
6 0 obj
<<
/Type /Page
/Parent 4 0 R
/MediaBox [ 0 0 1512 2138.4 ]

в другом:
6 0 obj
<<
/Type /Page
/Parent 4 0 R
/MediaBox [ 0 0 595.3 841.9 ]

т.е. если сделать в первом (где всё плохо)
/MediaBox [ 0 0 595.3 841.9 ]
то шрифты становятся правильного размера, но содержимое разъезжается


спасибо

Здравствуйте,

Много раз общался с вами по поводу сабжа в ICQ. Невозможно быстро в дизайнере сделать источник данных - всё приходится прописывать руками (десятки возвращаемых колонок в частном случае). Параметры вообще не работают. В порядке вещей такие запросы (при живых-то параметрах):

Код: Выделить всё

declare @ClID bigint 
set @ClID = case when {FaceID} = 0 then NULL else {FaceID} end 
exec GladeA.AccountsSummary @Date = '{Spell}', @FaceID = @ClID

Даже программку специально для вас писал с правильным функционалом. Ну сколько можно? ГОДЫ идут, а воз всё там же (по-моему, первые полемики больше 2 лет назад были). Неужели я один полноценно использую СУБД, процедуры, реализую срочные "приляпки" прямо в отчете скриптами в тексте запроса и т.п.? Кто-нибудь!!! Ну скажите им, а.... Уже с горя на сайт FR лажу - жду их .NET версию. Хорошо, понимаю - обратная совместимость. В таком случае можно сделать настройку движка - чтобы было 2 варинта: 1) как считают правильным разработчики FR; 2) как считает правильным человек, делающий отчет (т.е. без встроенной "аналитики" (вместо парсера самого SQL-сервера) текста запроса и далеко идущих выводов). Нельзя же расчитывать только на людей, которые оперируют исключительно построителем запросов и конкатенацией строк, с трудом понимая, что получится в итоге. Это моя последняя мольба. Больше не буду. Ну нафик.

К сожалению я слабо помню эту полемику. Если не ошибаюсь Ваше решение не работало для многих других пользователей, многие из которых не менее рьяно остаивают свои потребности. Если не сложно опишите более бодробно проблему и вариант ее решения с Вашей точки зрения. Мы внесем необходимые изменения для ее решения в наш код.

* при ненулевом расстоянии между колонками _страницы_ заливка DataBand "наезжает" на разделительную полосу между колонками

К сожалению это невозможно исправить в движке EngineV1. В EngineV2 все работает верно.

*в PDF, сгенерированном на XP sp2, шрифты ок
в том же самом отчете, экспортированном в PDF на Win server 2003 r2 (.net 2.0) шрифты получаются мизерного размера (примерно троечка)
экспериментировал с внедрением шрифтов и т.п. - безрезультатно

в одном:
6 0 obj
<<
/Type /Page
/Parent 4 0 R
/MediaBox [ 0 0 1512 2138.4 ]

в другом:
6 0 obj
<<
/Type /Page
/Parent 4 0 R
/MediaBox [ 0 0 595.3 841.9 ]

т.е. если сделать в первом (где всё плохо)
/MediaBox [ 0 0 595.3 841.9 ]
то шрифты становятся правильного размера, но содержимое разъезжается

Пришшлите пожалуйста mdc файд для этого отчета мы проверим еще раз. Также необходима пара скриншотов как это выглядит в Xp и 2003.

Спасибо.

К сожалению я слабо помню эту полемику. Если не ошибаюсь Ваше решение не работало для многих других пользователей, многие из которых не менее рьяно отстаивают свои потребности. Если не сложно опишите более подробно проблему и вариант ее решения с Вашей точки зрения. Мы внесем необходимые изменения для ее решения в наш код.

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

К сожалению это невозможно исправить в движке EngineV1. В EngineV2 все работает верно.

Не в курсе насчет движков А откуда берет начало EngineV2?

Пришшлите пожалуйста mdc файд для этого отчета мы проверим еще раз. Также необходима пара скриншотов как это выглядит в Xp и 2003.

Шаблон любой. Один и тот же отчет строился в этих двух операционках (версия SR одна). Но результат оказался различным. В содержимом нашел разницу, которую указал. Особо сказать больше нечего.

Здравствуйте,

У меня нет своего собственного решения какой-то проблемы, поскольку работа с SQL-сервером не является проблемой в принципе. Есть некоторая данность - и всё. Поясняю. Текст запроса является черным ящиком для всего и вся кроме человека и SQL-сервера. Существует великое разнообразие SQL-серверов, реализующих свои расширения языка SQL, и ваша попытка парсить запрос, чтобы помочь пользователю за него решить, что он там написал, заведомо провальна! Иначе вам придется реализовывать логику парсеров всех поддерживаемых вами SQL-серверов (я не знаю, что делать с универсальным ODBC-источником данных). Человек может взять на себя ответственность и сказать вам (не серверу), что у него в запросе - имя процедуры. И тогда вы можете попытаться запросить у сервера параметры указанного пользователем объекта базы. Потом только лишь из имени процедуры создается (провайдером данных) обычный запрос и скармливается серверу. Естественно, когда объекта базы нет, и запрос является просто текстом, то вы никогда ниоткуда не сможете узнать, какие параметры в тексте задумал пользователь. Только пользователь руками может указать, какие параметры и их типы должны создаваться для команды. Результат же выполнения запроса к серверу вы не сможете предсказать никогда, поскольку и процедура, и запрос прямым текстом могут вернуть абсолютно разные выборки, которые будут зависеть от параметров, контекста, даты, времени... чего угодно! И только пользователь способен в дизайнере указать именно те параметры, при отработке запроса с которыми выборка будет содержать тот набор полей, что и при дальнейшем использовании в боевых условиях. Вы никогда не сможете однозначно угадать значения параметров для вытягивания метаданных результата, поэтому при автоматическом заполнении полей значения параметров должны браться те, которые указаны в дизайнере пользователем. Нет никакого смысла спорить с этими утверждениями и ссылаться на обратную совместимость, ибо это - физика процесса. Необходимо просто сделать опцию и дать возможность использовать правильное поведение.
Что получается у вас? Вы начинаете решать, что там написал пользователь. Путаете параметры с переменными, смущаетесь большинства способов вызова процедуры и тому подобное. И в итоге валятся глупые исключения про необходимость объявить скалярную переменную, что-то про неверный аргумент функции substring, ненужные поля из-за каких-то навеяных вам значений параметров и т.п. Реально, мне не удалось создать источник данных с классическим способом формирования запроса! Всё только через конкатенацию строк - частей запроса и параметров, что приводит к проблемам другого рода (из-за которых, как мне кажется, и были придуманы параметры). Речь о спец. символах, атаках SQL-injection и других гадостях. То есть, ваш генератор отчетов фактически вынуждает разработчиков зачастую создавать дыры в безопасности сервера (при ненадлежащих указания прав это именно так!).

Я понял о какой проблеме Вы говорите. Через несколько недель будет доступна переработанная версия GUI. В ней в том числе переработан механизм получения колонок из базы данных.

В связи с наличием старых пользователей, которые налабали отчетов тяп-ляп, используют ваши "фичи" и рьяно отстаивают на них свои оплаченные законные права, мне хочется, чтобы (опционально) все ваши аналитические инициативы могли отключаться, и чтобы работа с СУБД осуществлялась по нормальным разумным правилам, давно реализованным во всех провайдерах данных, будь то .NET провайдеры, OLE DB, ODBC или еще какие-то. Там, прошу заметить, никто не посягает на реализацию сверхинтеллекта и не пытается конкурировать с парсерами СУБД, хотя времени на усовершенствование было предостаточно. Насчет конкретных приемов использования всего этого - могу кинуть ту программку еще раз, хотя всё есть в документации (просто там необходимый и достаточный для вас функционал).
Пожалуйста, вдумайтесь в выделенное жирным. Это важно.

Здесь ситуация немного другая. Возможность встраивать выражения в текст sql запроса придумали не мы. Мы сделали это после многочисленных вопросов от пользователей как изменить текст запроса напрямую. Больше эта возможность не предназначена ни для чего. Да некоторые пользователи используют их для заполнения параметров, но это их право использовать продукт как им хочется.

Не в курсе насчет движков А откуда берет начало EngineV2?

Первые версии стали доступны в начале лета этого года.

Шаблон любой. Один и тот же отчет строился в этих двух операционках (версия SR одна). Но результат оказался различным. В содержимом нашел разницу, которую указал. Особо сказать больше нечего.

Можно все таки прислать mdc файл для любого отчета и два pdf файла - результата. Дело в том, что здесь многое зависит от используемых в отчете шрифтов.

Спасибо.