Changing the parameter of a Snapshot

I understand that a history can be created in Reporting Services. Is
it true that when you click on the "New Snapshot" button, you get a
report using the default parameter? If so, then the "history" feature
is pretty much useless as you can only generate one version of the
report. What we want is to be able to take snapshots of a report at a
give point in time with the desired parameters.
Thanks for any input here.Yes, snapshots in the history are taken with default values of parameters.
If you need to store snapshot with different parameter values, you need to
set different defaults and then take snapshot. Also, when you render that
snapshot, you can change values of parameters that are not used in query.
--
Dmitry Vasilevsky, SQL Server Reporting Services Developer
This posting is provided "AS IS" with no warranties, and confers no rights.
--
---
"Eugene" <primer200@.yahoo.com> wrote in message
news:6290d6d2.0407281559.735524cb@.posting.google.com...
> I understand that a history can be created in Reporting Services. Is
> it true that when you click on the "New Snapshot" button, you get a
> report using the default parameter? If so, then the "history" feature
> is pretty much useless as you can only generate one version of the
> report. What we want is to be able to take snapshots of a report at a
> give point in time with the desired parameters.
> Thanks for any input here.|||Dmitry,
From a user point of view, I changed the parameter and I want to take
a snapshot of what I did. That would be a fair enough request,
wouldn't it? The administrator can't give a user Content Manager right
for him to change the default. May be this can be included in
enhencement for the next release?
Regards
Eugene|||We consider this as a request, however, it is not as straightforward as it
seems.
1. Snapshots were not intended to be a replacement for a good Data
Warehouse. Every missing feature about snapshots (and even snapshots
themselves) can be "worked around" by setting a data warehouse that can
reconstruct result of a query for any given time.
2. History is bound to a report, not to a user. Items in history don't carry
any individual security. Anyone who have access to a report would be able to
render from history. Therefore, personal preferences of a anyone, creating
snapshot would affect all users.
3. When allowing defaults only we identify snapshots by creation time. If we
accept parameters, we would have to introduce other means to identify and
manage snapshots. It would be possible and reasonable to take multiple
snapshots at the same time.
4. In many cases, users can create a linked report, provide different
default values for parameters and take snapshot of that linked report.
Dmitry Vasilevsky, SQL Server Reporting Services Developer
This posting is provided "AS IS" with no warranties, and confers no rights.
--
---
"Eugene" <primer200@.yahoo.com> wrote in message
news:6290d6d2.0408012040.b062b04@.posting.google.com...
> Dmitry,
> From a user point of view, I changed the parameter and I want to take
> a snapshot of what I did. That would be a fair enough request,
> wouldn't it? The administrator can't give a user Content Manager right
> for him to change the default. May be this can be included in
> enhencement for the next release?
> Regards
> Eugene

Changing the data schema in Transactional replication

I am using concurrent snapshot - transactional replication. If I need to add
the column to the replicated table, do I need to drop and re-create
subscription everytime? The database is about 20Gb, it takes up to 4 hours to
re-create two subscriptions. Is there any easier way of changing the data
schema with this configuration?
Please look at sp_repladdcolumn in BOL. If you are using SQL Server 2005,
ALTER TABLE will do it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Nope, it will not help. The column need to be added into the table through
differnet software and then populated. I was doing drop article -
subscribtion then addarticle- subscription. But I had tables locked during
the snapshot creation. Then I unchecked the tables lock and received
concurrent snapshot. Drop article-subscription wokrs well, then add article
works too, but then when I add this article to the subscription I receive an
error message: needed to specify all articles? what about if I have about
100 tables-articles?
"Paul Ibison" wrote:

> Please look at sp_repladdcolumn in BOL. If you are using SQL Server 2005,
> ALTER TABLE will do it.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||Please can you post up the entire error message. Also, in order for me to
repro, can you tell me if there are any extra parts to the setup eg
anonymous subscribers that I need to know about. In fact, can you script out
the publication and I'll set up something similar tomorrow.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .

changing RDL of a snapshot?

As I understand it, once you snapshot a report, any changes to the RDL of the
report will not affect the snapshot. Let's say (using a purely hypothetical
situation ;-) that I misspelled the text of a column header. Has anyone
looked into messing with the stuff in the ChunkData table to go change a
piece of text in the RDL of the snapshotted report? Obviously this would be a
completely unsupported action as far as Microsoft is concerned... and I would
obviously proceed at my own risk.
Can anyone give me any hints about what format the ChunkData.Content column
is in so that I could read and modify a few bytes?You are right - this is an unsupported action.
BTW: you won't find *any* RDL XML in snapshots. Snapshots are output-format
independent, already processed reports. The risk is extremely high to get it
wrong when messing with them (in particular for compressed snapshots on
SP1). If you get it wrong, the snapshot is no longer usable and will result
in a fatal error "unexpected error during processing".
Keep in mind that you are on your own once you modify anything directly in
the report server databases.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"FurmanGG" <FurmanGG@.discussions.microsoft.com> wrote in message
news:BFBF8E3A-054F-473A-829B-5AB1798CCA04@.microsoft.com...
> As I understand it, once you snapshot a report, any changes to the RDL of
the
> report will not affect the snapshot. Let's say (using a purely
hypothetical
> situation ;-) that I misspelled the text of a column header. Has anyone
> looked into messing with the stuff in the ChunkData table to go change a
> piece of text in the RDL of the snapshotted report? Obviously this would
be a
> completely unsupported action as far as Microsoft is concerned... and I
would
> obviously proceed at my own risk.
> Can anyone give me any hints about what format the ChunkData.Content
column
> is in so that I could read and modify a few bytes?

Changing Isolation Level.

Changing Isolation Level to Snapshot or Snapshot Read Commited resolve all problems from deadlock ?

thanks

Many deadlock problems are solved because snapshot isolation prevents readers from blocking writers and writers from blocking readers and that is the main cause of deadlocks. Note: Writers still block writers.|||

In general - yes: switching to the new isolation levels with non-blocking read access somewhat helps reducing the likelihood of deadlock, but would not completely eliminate them.

However, you should remember that if the application behavior implicitly depends on the blocking semantics of the old isolation levels as implemented in the SQL Engine, the application may stop working correctly when switching to the versioning-based concurrency model. Ideally you should carefully analyze all the transactions in your application and make sure that you don't rely on the subtleties of the implementation of the specific engine and only after that consider switching to the versioning-based transaction isolation.

You should also remember that when using the Snapshot Isolation level your application should also be able to cope with snapshot update conflicts. In other words in this case you trade some deadlocks with (hopefully much less frequent) update conflicts. But again, it all depends on your application.

Pleas also note that despite the Read Committed Snapshot Isolation the SQL Engine never causes update conflicts, it only uses the non-blocking read semantics when accessing tables that are not being updated by the DML statement (unlike the 'normal' snapshot isolation level where all the access to all the tables is truly non-blocking and the data locks necessary for the update/delete are only acquired after the records has been finally selected by the predicate).

Which means that in case of single-table predicated UPDATE/DELETE statements, you don't really enjoy the benefits of the non-blocking access when searching the records to be affected and if most of the deadlock in your application are caused by plain single-table UPDATE/DELETE statements. If so, wou will hardly see any improvements when switching to the Read Committed Snapshot IL from the blocking Read Committed IL.

Of course, the things will most likely improve when switching from Repeatable Read or Serilizable, but since in a multi-statement transaction the Read Committed Snapshot is in fact provides much weaker consistency guarantees compare to either of the above, you have to prove first that the application correctness will not suffer after the switch.

Changing Isolation Level.

Changing Isolation Level to Snapshot or Snapshot Read Commited resolve all problems from deadlock ?

thanks

Many deadlock problems are solved because snapshot isolation prevents readers from blocking writers and writers from blocking readers and that is the main cause of deadlocks. Note: Writers still block writers.|||

In general - yes: switching to the new isolation levels with non-blocking read access somewhat helps reducing the likelihood of deadlock, but would not completely eliminate them.

However, you should remember that if the application behavior implicitly depends on the blocking semantics of the old isolation levels as implemented in the SQL Engine, the application may stop working correctly when switching to the versioning-based concurrency model. Ideally you should carefully analyze all the transactions in your application and make sure that you don't rely on the subtleties of the implementation of the specific engine and only after that consider switching to the versioning-based transaction isolation.

You should also remember that when using the Snapshot Isolation level your application should also be able to cope with snapshot update conflicts. In other words in this case you trade some deadlocks with (hopefully much less frequent) update conflicts. But again, it all depends on your application.

Pleas also note that despite the Read Committed Snapshot Isolation the SQL Engine never causes update conflicts, it only uses the non-blocking read semantics when accessing tables that are not being updated by the DML statement (unlike the 'normal' snapshot isolation level where all the access to all the tables is truly non-blocking and the data locks necessary for the update/delete are only acquired after the records has been finally selected by the predicate).

Which means that in case of single-table predicated UPDATE/DELETE statements, you don't really enjoy the benefits of the non-blocking access when searching the records to be affected and if most of the deadlock in your application are caused by plain single-table UPDATE/DELETE statements. If so, wou will hardly see any improvements when switching to the Read Committed Snapshot IL from the blocking Read Committed IL.

Of course, the things will most likely improve when switching from Repeatable Read or Serilizable, but since in a multi-statement transaction the Read Committed Snapshot is in fact provides much weaker consistency guarantees compare to either of the above, you have to prove first that the application correctness will not suffer after the switch.