Reportbuilder v9, is this possible ??? (In mind of Sql2005)
Hello,
In the Newfeatures list of v9 i've seen that there are some new
features for modifying the sql. At this moment we are doing this
already with some passtrhu functions. But, a question/remark arises
when thinking of Sql Server 2005...
It would be nice that we could just enter the sql-statement directly
with an editor (can be done already) but that we also could use the
:param notations and that out of these :params the autosearch values
are created automatically.
Why this question arround Sql2005. There are some superb new
enhancements in their sql that are not ANSI-standard so that will not
be implemented in your dade query generator, but if we want to use
them we could enter the code directly (working with a overlapping
view that hides the specific code and produces a regular ansi output
is not always very performant). But, when entering the code manually
we lose all benefits of the autosearch values. That other features
have to be disables ok, summing, grouping, ordering, calc's .. but
the autosearch could be kept when analyzing the :params.
Hope that this is a useless question and that this is provided in v9.
In the Newfeatures list of v9 i've seen that there are some new
features for modifying the sql. At this moment we are doing this
already with some passtrhu functions. But, a question/remark arises
when thinking of Sql Server 2005...
It would be nice that we could just enter the sql-statement directly
with an editor (can be done already) but that we also could use the
:param notations and that out of these :params the autosearch values
are created automatically.
Why this question arround Sql2005. There are some superb new
enhancements in their sql that are not ANSI-standard so that will not
be implemented in your dade query generator, but if we want to use
them we could enter the code directly (working with a overlapping
view that hides the specific code and produces a regular ansi output
is not always very performant). But, when entering the code manually
we lose all benefits of the autosearch values. That other features
have to be disables ok, summing, grouping, ordering, calc's .. but
the autosearch could be kept when analyzing the :params.
Hope that this is a useless question and that this is provided in v9.
This discussion has been closed.
Comments
I do see a lot of merit in what you are asking, and I too hope that DM
will improve this area in this or in future releases.
We have implemented similar functionality in one of our own
applications, so I wanted to convey to you that you can add this
functionality yourself, it is not trivial, but it is not overly
difficult. While some of our users are allowed to develop their own
queries using the built in query wizard, our application demands a
level of complexity that can't easily be written by end users, nor do
we want them to try!
So we have built in queries that are actually stored in the database
that include :stlye parameters. We use the built-in autosearch
functions to prompt the user at runtime and replace the query
parameters with the values form the autosearch dialogs.
I definitely see merit in DM providing this functionality as a built-in
part of their toolset, but it is also a tribute to their architecture
that we were able to add this to our own product.
That's why we work now with ReportBuilder, we have been running
Impropmty for Web (Cognos) en WebFocus (Information Builders), both
suberb applications that costs q whole lot more than Rb, although we
still have licenses and pay maintenance we stopped developping with
them.
You can do things with Rb that are impossible/very difficult with
other tools, but if we don't continue to ask for even more
possibilities, with an easier access the 'others' might catch up.
No, that's a joke, but what i asked here was a basic/general feature
where quite some users could benefit from.
We are also, with passtrhu functions modifying the Sql statements and
adding the autosearches, but it would have been nice to have ......
Thanks for the feedback.
For RB 9, the highest priority was to make runtime manipulation of TdaSQL
simpler from Delphi code and RAP code. The new TdaSQLBuilder class in
conjunction with the new Report events, OnInitializeParameters and
BeforeOpenDataPipelines, accomplishes this goal.
We have additional features that we would like to add and support for
:Parameter notation is high on the list.
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com