Hi Guys
I have an application which consists of a navigation bar and a frame.
When a user selects a hyperlink on the navigation bar that particular
report is displayed in the frame. Now these reports contains links
through which the user can jump to some other report which is not
present in the navigation bar. Now when the user clicks any other link
on the navigation bar the new report is starting up using the default
parameters set for that report. But i dont want this to happen. The
report viewer should take the latest parameters set in the report
viewer and pass them to the new report that will be generated when the
user clicks on the navigation bar. Can any body help with this aspect.
it is blowing up my brains. dont even know that whether this is
possible.
Also can we somehow get the url of the report being displayed in the
report viewer." i know that report viewer is an iframe which uses url
access beneath it to access the reports." Only the first report server
url is encoded in the application. But when the user navigated to some
other report through the links in reports how do i get access to that
particular report url .
any help will really be great. I am wondering is it really possible to
do the stuff i just mentioned above. Any tips on this will really save
me a lot of time.
Thanks in advance.../......
Passxunlimitedyou have to add some code to save the parameters and reuse them when you
open a new report.
you have to intercept some events (from the reportviewer control) to
retrieve the parameters when the first report is refreshed with new
parameters, save the values into a the session, in the page load event if
you open a new report change the values of the parameters of these reports
regarding what you have saved before.
its not complicated, the API is easy to use to do this.
"Passx" <passxunlimited@.gmail.com> wrote in message
news:1167432103.071025.84650@.a3g2000cwd.googlegroups.com...
> Hi Guys
> I have an application which consists of a navigation bar and a frame.
> When a user selects a hyperlink on the navigation bar that particular
> report is displayed in the frame. Now these reports contains links
> through which the user can jump to some other report which is not
> present in the navigation bar. Now when the user clicks any other link
> on the navigation bar the new report is starting up using the default
> parameters set for that report. But i dont want this to happen. The
> report viewer should take the latest parameters set in the report
> viewer and pass them to the new report that will be generated when the
> user clicks on the navigation bar. Can any body help with this aspect.
> it is blowing up my brains. dont even know that whether this is
> possible.
> Also can we somehow get the url of the report being displayed in the
> report viewer." i know that report viewer is an iframe which uses url
> access beneath it to access the reports." Only the first report server
> url is encoded in the application. But when the user navigated to some
> other report through the links in reports how do i get access to that
> particular report url .
> any help will really be great. I am wondering is it really possible to
> do the stuff i just mentioned above. Any tips on this will really save
> me a lot of time.
> Thanks in advance.../......
> Passxunlimited
>|||i was trying to do exactly the same thing . But could not find any
events associated with report viewer wherein i can catch the parameter
values or session state. Any idea or resources regarding this.
thanks
passx
Jeje wrote:
> you have to add some code to save the parameters and reuse them when you
> open a new report.
> you have to intercept some events (from the reportviewer control) to
> retrieve the parameters when the first report is refreshed with new
> parameters, save the values into a the session, in the page load event if
> you open a new report change the values of the parameters of these reports
> regarding what you have saved before.
> its not complicated, the API is easy to use to do this.
>
> "Passx" <passxunlimited@.gmail.com> wrote in message
> news:1167432103.071025.84650@.a3g2000cwd.googlegroups.com...
> > Hi Guys
> >
> > I have an application which consists of a navigation bar and a frame.
> > When a user selects a hyperlink on the navigation bar that particular
> > report is displayed in the frame. Now these reports contains links
> > through which the user can jump to some other report which is not
> > present in the navigation bar. Now when the user clicks any other link
> > on the navigation bar the new report is starting up using the default
> > parameters set for that report. But i dont want this to happen. The
> > report viewer should take the latest parameters set in the report
> > viewer and pass them to the new report that will be generated when the
> > user clicks on the navigation bar. Can any body help with this aspect.
> > it is blowing up my brains. dont even know that whether this is
> > possible.
> >
> > Also can we somehow get the url of the report being displayed in the
> > report viewer." i know that report viewer is an iframe which uses url
> > access beneath it to access the reports." Only the first report server
> > url is encoded in the application. But when the user navigated to some
> > other report through the links in reports how do i get access to that
> > particular report url .
> >
> > any help will really be great. I am wondering is it really possible to
> > do the stuff i just mentioned above. Any tips on this will really save
> > me a lot of time.
> >
> > Thanks in advance.../......
> > Passxunlimited
> >|||try the onunload event or any event after the rendering step.
"Passx" <passxunlimited@.gmail.com> wrote in message
news:1167942475.840285.10930@.51g2000cwl.googlegroups.com...
>i was trying to do exactly the same thing . But could not find any
> events associated with report viewer wherein i can catch the parameter
> values or session state. Any idea or resources regarding this.
>
> thanks
> passx
> Jeje wrote:
>> you have to add some code to save the parameters and reuse them when you
>> open a new report.
>> you have to intercept some events (from the reportviewer control) to
>> retrieve the parameters when the first report is refreshed with new
>> parameters, save the values into a the session, in the page load event if
>> you open a new report change the values of the parameters of these
>> reports
>> regarding what you have saved before.
>> its not complicated, the API is easy to use to do this.
>>
>> "Passx" <passxunlimited@.gmail.com> wrote in message
>> news:1167432103.071025.84650@.a3g2000cwd.googlegroups.com...
>> > Hi Guys
>> >
>> > I have an application which consists of a navigation bar and a frame.
>> > When a user selects a hyperlink on the navigation bar that particular
>> > report is displayed in the frame. Now these reports contains links
>> > through which the user can jump to some other report which is not
>> > present in the navigation bar. Now when the user clicks any other link
>> > on the navigation bar the new report is starting up using the default
>> > parameters set for that report. But i dont want this to happen. The
>> > report viewer should take the latest parameters set in the report
>> > viewer and pass them to the new report that will be generated when the
>> > user clicks on the navigation bar. Can any body help with this aspect.
>> > it is blowing up my brains. dont even know that whether this is
>> > possible.
>> >
>> > Also can we somehow get the url of the report being displayed in the
>> > report viewer." i know that report viewer is an iframe which uses url
>> > access beneath it to access the reports." Only the first report server
>> > url is encoded in the application. But when the user navigated to some
>> > other report through the links in reports how do i get access to that
>> > particular report url .
>> >
>> > any help will really be great. I am wondering is it really possible to
>> > do the stuff i just mentioned above. Any tips on this will really save
>> > me a lot of time.
>> >
>> > Thanks in advance.../......
>> > Passxunlimited
>> >
>
Showing posts with label bar. Show all posts
Showing posts with label bar. Show all posts
Saturday, February 25, 2012
capturing reportviewer parameters
Labels:
application,
bar,
capturing,
consists,
database,
frame,
guys,
hyperlink,
microsoft,
mysql,
navigation,
oracle,
parameters,
particular,
reportviewer,
selects,
server,
sql,
user
Thursday, February 16, 2012
capitalized queries shower?
Hi all,
One of my co-workers claims that a capitalized query like "SELECT foo FROM
bar" would run slower than "select foo from bar." This sounds absurd to me,
and since I can't find any reference that claims his statement is true, I've
decided to ask the community.
Your help is appreciated.
-Oleg.Can you give me the name of that co-worker? I have a bridge to sell ;-)
--
Jacco Schalkwijk
SQL Server MVP
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
I agree 100%. I prefer queries where the keywords are capitalized; much
easier to parse and dissect visually.
--
http://www.aspfaq.com/
(Reverse address to reply.)|||No, that's totally untrue.
But I highly recommend that you take advantage of the situation by making a
very large bet with your co-worker and force this person to prove it
unequivocally in order to win the bet.
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||> But I highly recommend that you take advantage of the situation by making
a
> very large bet with your co-worker and force this person to prove it
> unequivocally in order to win the bet.
And hopefully, you've already shut off his NNTP access so he doesn't stumble
upon the common sense brought up here. ;-)|||"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:e3bbHeEYEHA.2816@.TK2MSFTNGP11.phx.gbl...
> I agree 100%. I prefer queries where the keywords are capitalized; much
> easier to parse and dissect visually.
I will concur on that one... All caps is easier for ME to read, but
certainly not a computer :)|||If you open SQL Profiler, from the tools in enterprise manager, do the 2
types of select in query analyzer, you will see that the duration for the
lowercase select will be lower than the uppercase select.
I would assume that the compiler has to convert the uppercase to lowercase
to compile the code first.
It is only a minimal speed difference, but there is a difference.
Jay Freeman
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||"Jay Freeman" <j.freeman@.halcyonsoftware.com> wrote in message
news:%23jEpJvEYEHA.1264@.TK2MSFTNGP11.phx.gbl...
> If you open SQL Profiler, from the tools in enterprise manager, do the 2
> types of select in query analyzer, you will see that the duration for the
> lowercase select will be lower than the uppercase select.
Looks the same to me, using this:
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
SELECT * FROM PUBS..AUTHORS
go
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
select * from pubs..authors
go
Parse and compile time was 0ms both times.
One of my co-workers claims that a capitalized query like "SELECT foo FROM
bar" would run slower than "select foo from bar." This sounds absurd to me,
and since I can't find any reference that claims his statement is true, I've
decided to ask the community.
Your help is appreciated.
-Oleg.Can you give me the name of that co-worker? I have a bridge to sell ;-)
--
Jacco Schalkwijk
SQL Server MVP
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
I agree 100%. I prefer queries where the keywords are capitalized; much
easier to parse and dissect visually.
--
http://www.aspfaq.com/
(Reverse address to reply.)|||No, that's totally untrue.
But I highly recommend that you take advantage of the situation by making a
very large bet with your co-worker and force this person to prove it
unequivocally in order to win the bet.
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||> But I highly recommend that you take advantage of the situation by making
a
> very large bet with your co-worker and force this person to prove it
> unequivocally in order to win the bet.
And hopefully, you've already shut off his NNTP access so he doesn't stumble
upon the common sense brought up here. ;-)|||"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:e3bbHeEYEHA.2816@.TK2MSFTNGP11.phx.gbl...
> I agree 100%. I prefer queries where the keywords are capitalized; much
> easier to parse and dissect visually.
I will concur on that one... All caps is easier for ME to read, but
certainly not a computer :)|||If you open SQL Profiler, from the tools in enterprise manager, do the 2
types of select in query analyzer, you will see that the duration for the
lowercase select will be lower than the uppercase select.
I would assume that the compiler has to convert the uppercase to lowercase
to compile the code first.
It is only a minimal speed difference, but there is a difference.
Jay Freeman
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>|||"Jay Freeman" <j.freeman@.halcyonsoftware.com> wrote in message
news:%23jEpJvEYEHA.1264@.TK2MSFTNGP11.phx.gbl...
> If you open SQL Profiler, from the tools in enterprise manager, do the 2
> types of select in query analyzer, you will see that the duration for the
> lowercase select will be lower than the uppercase select.
Looks the same to me, using this:
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
SELECT * FROM PUBS..AUTHORS
go
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
select * from pubs..authors
go
Parse and compile time was 0ms both times.
capitalized queries shower?
Hi all,
One of my co-workers claims that a capitalized query like "SELECT foo FROM
bar" would run slower than "select foo from bar." This sounds absurd to me,
and since I can't find any reference that claims his statement is true, I've
decided to ask the community.
Your help is appreciated.
-Oleg.
Can you give me the name of that co-worker? I have a bridge to sell ;-)
Jacco Schalkwijk
SQL Server MVP
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
I agree 100%. I prefer queries where the keywords are capitalized; much
easier to parse and dissect visually.
http://www.aspfaq.com/
(Reverse address to reply.)
|||No, that's totally untrue.
But I highly recommend that you take advantage of the situation by making a
very large bet with your co-worker and force this person to prove it
unequivocally in order to win the bet.
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||> But I highly recommend that you take advantage of the situation by making
a
> very large bet with your co-worker and force this person to prove it
> unequivocally in order to win the bet.
And hopefully, you've already shut off his NNTP access so he doesn't stumble
upon the common sense brought up here. ;-)
|||"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:e3bbHeEYEHA.2816@.TK2MSFTNGP11.phx.gbl...
> I agree 100%. I prefer queries where the keywords are capitalized; much
> easier to parse and dissect visually.
I will concur on that one... All caps is easier for ME to read, but
certainly not a computer
|||If you open SQL Profiler, from the tools in enterprise manager, do the 2
types of select in query analyzer, you will see that the duration for the
lowercase select will be lower than the uppercase select.
I would assume that the compiler has to convert the uppercase to lowercase
to compile the code first.
It is only a minimal speed difference, but there is a difference.
Jay Freeman
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||"Jay Freeman" <j.freeman@.halcyonsoftware.com> wrote in message
news:%23jEpJvEYEHA.1264@.TK2MSFTNGP11.phx.gbl...
> If you open SQL Profiler, from the tools in enterprise manager, do the 2
> types of select in query analyzer, you will see that the duration for the
> lowercase select will be lower than the uppercase select.
Looks the same to me, using this:
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
SELECT * FROM PUBS..AUTHORS
go
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
select * from pubs..authors
go
Parse and compile time was 0ms both times.
One of my co-workers claims that a capitalized query like "SELECT foo FROM
bar" would run slower than "select foo from bar." This sounds absurd to me,
and since I can't find any reference that claims his statement is true, I've
decided to ask the community.
Your help is appreciated.
-Oleg.
Can you give me the name of that co-worker? I have a bridge to sell ;-)
Jacco Schalkwijk
SQL Server MVP
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
I agree 100%. I prefer queries where the keywords are capitalized; much
easier to parse and dissect visually.
http://www.aspfaq.com/
(Reverse address to reply.)
|||No, that's totally untrue.
But I highly recommend that you take advantage of the situation by making a
very large bet with your co-worker and force this person to prove it
unequivocally in order to win the bet.
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||> But I highly recommend that you take advantage of the situation by making
a
> very large bet with your co-worker and force this person to prove it
> unequivocally in order to win the bet.
And hopefully, you've already shut off his NNTP access so he doesn't stumble
upon the common sense brought up here. ;-)
|||"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:e3bbHeEYEHA.2816@.TK2MSFTNGP11.phx.gbl...
> I agree 100%. I prefer queries where the keywords are capitalized; much
> easier to parse and dissect visually.
I will concur on that one... All caps is easier for ME to read, but
certainly not a computer
|||If you open SQL Profiler, from the tools in enterprise manager, do the 2
types of select in query analyzer, you will see that the duration for the
lowercase select will be lower than the uppercase select.
I would assume that the compiler has to convert the uppercase to lowercase
to compile the code first.
It is only a minimal speed difference, but there is a difference.
Jay Freeman
"Oleg Ogurok" <oleg@.ogurok.com.ihatespammers.ireallydo.co> wrote in message
news:10eauif311sp32f@.corp.supernews.com...
> Hi all,
> One of my co-workers claims that a capitalized query like "SELECT foo FROM
> bar" would run slower than "select foo from bar." This sounds absurd to
me,
> and since I can't find any reference that claims his statement is true,
I've
> decided to ask the community.
>
> Your help is appreciated.
> -Oleg.
>
|||"Jay Freeman" <j.freeman@.halcyonsoftware.com> wrote in message
news:%23jEpJvEYEHA.1264@.TK2MSFTNGP11.phx.gbl...
> If you open SQL Profiler, from the tools in enterprise manager, do the 2
> types of select in query analyzer, you will see that the duration for the
> lowercase select will be lower than the uppercase select.
Looks the same to me, using this:
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
SELECT * FROM PUBS..AUTHORS
go
set statistics time off
dbcc dropcleanbuffers
dbcc freeproccache
go
set statistics time on
select * from pubs..authors
go
Parse and compile time was 0ms both times.
Subscribe to:
Posts (Atom)