Showing posts with label approach. Show all posts
Showing posts with label approach. Show all posts

Sunday, March 11, 2012

"Parameters" approach to fill report header with source data doesn't work

It's well known issue, that one can't use any dataset fields in a

report header/footer directly. One of the approach is to create

query-based parameter that basically equals

=First(Fields!@.FieldName@..Value, "@.DataSetName@.") and use that

parameter value instead. But it doesn't work in my case!

My report displays some entity description and is parametrized with

EntityID param. Its header contains entity name that, according to the

approach, is queried from the data source through the EntityName

report parameter. There's important issue: the report is displayed in

ReportViewer control, that is embedded into my application and entity

ID parameter isn't ser by user in ReportViewer parameters area. Its

default value is changed by the application with SetReportParameters()

web method every time a user wants to view the report according to the

entity the user is exploring in the application. But after the report

has been rendered, its header always contains not actual (outdated)

entity name. Nevertheless, the report body contains actual data

(including entity name). If I alter entity ID parameter in ReportViewer

or in web-based Report Manager and refresh report, header displays

correct entity name.

What's wrong in the workflow described?Up! SSRS can't deal with data in hearders, can it?|||

There is a way:

You can make the header fields refere to databound fields which are location within the body of the reports- to get your results ie You can put a hidden text field in the body and reference that field!


|||

Hi Viral,

If we put the hidden textbox in the body and use those textbox value it works perfectly here the problem is if our result in 5 pages when we export this result to PDF , the problem here is for the first page only the textbox value in the header is displaying from next page onwards it is displaying null values eventhough we made the property of textbox "Repeat With" :table1(result set) set.

Thanks

Sunday, February 19, 2012

<NEWBIE>Move database from case sensitive to case insensitive servers

I know there are several ways to copy information from one machine to anothe
r, and from my research in the archives every approach has its adherents. I'
d just like a better idea of which is the best method for my particular case
.
There is a database residing on a remote server that has been set up as case
sensitive. I need to move the database to my own departmental server, which
is case insensitive (and the app vendor prefers this). Which is the best me
thod to move the system, wh
ere best means first, no errors and second, little effort on my part.
Right now I'm leaning toward detaching the database on the other machine and
copying its mdf and ldf files to the local machine and reattaching it. Will
the case sensitivity cause problems?
Thanks,
J"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1C256B86-16BD-4933-B081-264AC510F814@.microsoft.com...
> I know there are several ways to copy information from one machine to
another, and from my research in the archives every approach has its
adherents. I'd just like a better idea of which is the best method for my
particular case.
> There is a database residing on a remote server that has been set up as
case sensitive. I need to move the database to my own departmental server,
which is case insensitive (and the app vendor prefers this). Which is the
best method to move the system, where best means first, no errors and
second, little effort on my part.
> Right now I'm leaning toward detaching the database on the other machine
and copying its mdf and ldf files to the local machine and reattaching it.
Will the case sensitivity cause problems?
>
Are you running SQL Server 2000? Then that should work for you. Another
option, create the database on the target with the collation you need, then
run a RESTORE. For more information, see BOL "SQL Server Collation
Fundamentals".
Steve|||Do you want the database to be case sensitive or case insensitive on the new
server?
Watch out having different collations for you system databases vs. your
application database(s). If the app wasn't tested for this, you might get
error messages from the queries it submits (collation conflict messages).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1C256B86-16BD-4933-B081-264AC510F814@.microsoft.com...
> I know there are several ways to copy information from one machine to
another, and from my research in the archives every approach has its
adherents. I'd just like a better idea of which is the best method for my
particular case.
> There is a database residing on a remote server that has been set up as
case sensitive. I need to move the database to my own departmental server,
which is case insensitive (and the app vendor prefers this). Which is the
best method to move the system, where best means first, no errors and
second, little effort on my part.
> Right now I'm leaning toward detaching the database on the other machine
and copying its mdf and ldf files to the local machine and reattaching it.
Will the case sensitivity cause problems?
> Thanks,
> J

<NEWBIE>Move database from case sensitive to case insensitive servers

I know there are several ways to copy information from one machine to another, and from my research in the archives every approach has its adherents. I'd just like a better idea of which is the best method for my particular case.
There is a database residing on a remote server that has been set up as case sensitive. I need to move the database to my own departmental server, which is case insensitive (and the app vendor prefers this). Which is the best method to move the system, where best means first, no errors and second, little effort on my part.
Right now I'm leaning toward detaching the database on the other machine and copying its mdf and ldf files to the local machine and reattaching it. Will the case sensitivity cause problems
Thanks
J"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1C256B86-16BD-4933-B081-264AC510F814@.microsoft.com...
> I know there are several ways to copy information from one machine to
another, and from my research in the archives every approach has its
adherents. I'd just like a better idea of which is the best method for my
particular case.
> There is a database residing on a remote server that has been set up as
case sensitive. I need to move the database to my own departmental server,
which is case insensitive (and the app vendor prefers this). Which is the
best method to move the system, where best means first, no errors and
second, little effort on my part.
> Right now I'm leaning toward detaching the database on the other machine
and copying its mdf and ldf files to the local machine and reattaching it.
Will the case sensitivity cause problems?
>
Are you running SQL Server 2000? Then that should work for you. Another
option, create the database on the target with the collation you need, then
run a RESTORE. For more information, see BOL "SQL Server Collation
Fundamentals".
Steve|||Do you want the database to be case sensitive or case insensitive on the new
server?
Watch out having different collations for you system databases vs. your
application database(s). If the app wasn't tested for this, you might get
error messages from the queries it submits (collation conflict messages).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1C256B86-16BD-4933-B081-264AC510F814@.microsoft.com...
> I know there are several ways to copy information from one machine to
another, and from my research in the archives every approach has its
adherents. I'd just like a better idea of which is the best method for my
particular case.
> There is a database residing on a remote server that has been set up as
case sensitive. I need to move the database to my own departmental server,
which is case insensitive (and the app vendor prefers this). Which is the
best method to move the system, where best means first, no errors and
second, little effort on my part.
> Right now I'm leaning toward detaching the database on the other machine
and copying its mdf and ldf files to the local machine and reattaching it.
Will the case sensitivity cause problems?
> Thanks,
> J