Showing posts with label definition. Show all posts
Showing posts with label definition. Show all posts

Tuesday, March 27, 2012

History of Report Definition File for Published Reports...

I would like to know if there is a way to maintain the history of changes to the reports that have been published to the report server?

I know that the report definitions get saved onto ReportServer database. But let's say a user makes a change to the published report and then saves it back to the server. And that the latest change was incorrect and I have to revert back to the previous version of the published report. Is there a way to do that? Does the report server maintain a history of previous versions.

There is a history for each report and I think that corresponds to the history of report executions (output data). But I am talking about the history of actual report definition.

Thanks for you help.

The report definition is stored as XML in the ReportServer database.

There is no concept of source management in Report Server. How would the user be making a change to the published report?

If they are accessing the report through Visual Studio, you would perform all source control operations there.

Otherwise you may be able to setup a trigger to copy the report definition to another table, though it would mean some hacking around with SQL profiler to determine what fields are required.

You could also setup a job that runs the RS Scripter utility to export definitions on a regular basis.

cheers,

Andrew

|||

I should have told "for reports created using the report builder". These reports are published to the report server. Once published, the users can open the report again from the report builder and then make changes to the report and then publish it again. In such a case, is there a way to track the history of changes in that published report? Because if some user edits a report and messes it up, how would I go back to the previous version of the report?

Thanks for your response.

Monday, March 26, 2012

Hints in Views

Can we use hints with in the view definition ?
Thanks in advance.
RajYes, just be sure that you really need the hint, as specifying the wrong
hint can impact performance negatively.
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Vish" <mocherla_v@.hotmail.com> wrote in message
news:ujpIbVeRDHA.3132@.tk2msftngp13.phx.gbl...
> Can we use hints with in the view definition ?
> Thanks in advance.
> Raj
>|||Raj,
I hope the below article helps...it is right from BOL.
View Hints
View hints can be used only for indexed views. (An indexed
view is a view with a unique clustered index created on
it.) If a query contains references to columns that are
present both in an indexed view and base tables, and
Microsoft SQL ServerT query optimizer determines that
using the indexed view provides the best method for
executing the query, then the optimizer utilizes the index
on the view. This function is supported only on the
Enterprise and Developer Editions of the Microsoft SQL
Server 2000.
However, in order for the optimizer to consider indexed
views, the following SET options must be set to ON:
ANSI_NULLS, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL,
ANSI_PADDING, ARITHABORT, QUOTED_IDENTIFIERS
In addition, the NUMERIC_ROUNDABORT option must be set to
OFF.
To force the optimizer to use an index for an indexed
view, specify the NOEXPAND option. This hint may be used
only if the view is also named in the query. SQL Server
2000 does not provide a hint to force a particular indexed
view to be used in a query that does not name the view
directly in the FROM clause; however, the query optimizer
considers the use of indexed views even if they are not
referenced directly in the query.
View hints are allowed only in SELECT statements; they
cannot be used in views that are the table source in
INSERT, UPDATE, and DELETE statements.
Syntax
< view_hint > ::={ NOEXPAND [ , INDEX ( index_val [ ,...n ] ) ] }
Arguments
NOEXPAND
Specifies that the indexed view is not expanded when the
query optimizer processes the query. The query optimizer
treats the view like a table with clustered index.
INDEX ( index_val [ ,...n ] )
Specifies the name or ID of the indexes to be used by SQL
Server when it processes the statement. Only one index
hint per view can be specified.
INDEX(0) forces a clustered index scan and INDEX(1) forces
a clustered index scan or seek.
If multiple indexes are used in the single hint list, the
duplicates are ignored and the rest of the listed indexes
are used to retrieve the rows of the indexed view. The
ordering of the indexes in the index hint is significant.
A multiple index hint also enforces index ANDing and SQL
Server applies as many conditions as possible on each
index accessed. If the collection of hinted indexes does
not contain all columns referenced in the query, a fetch
is performed after retrieving all the indexed columns.
DeeJay
>--Original Message--
>Can we use hints with in the view definition ?
>Thanks in advance.
>Raj
>
>.
>

Sunday, February 19, 2012

HideMemberIf OnlyChildWithParentName and member formula

Levels are defined using a SourceAttribute that points to an attribute used to create the level. In the definition of that attribute, the CustomRollupColumn points to a formula to be used in the custom rollup.

But if the level is hidden using HideMemberIf, does the level still participate - does that formula still get executed at query time?

In other words, are custom rollups still calculated, even if they are hidden using something like HideMemberIf?