Hi All
I'm new to Crystal XI so have a basic question for you guys. I have a report with 3 subreports and sometimes some of the subreports run onto more than one page. I would like to be able to repeat the subreport header on each page when this happens. Any ideas?
Much appreciated
OzHello I have got the same problem but, I am using the version 8.5.0.217
I have a report with 3 subreports each one giving some totally different information from one to the other and only the Header of the main report has common information. I need to print a subreport header in each page this subreports needs
Example
TITLE
A.- details main rep
B.- subreport_1
b.0 Title Subreport_1
b.1 detail Subreport_1
C.- subreport_2
c.0 title subreport_2
c.1 detail Subreport_2
D.- subreport_3
d.0 title Subreport_3
d.1 detail Subreport_3
The page header involves TITLE + A (details main rep)
The report detail involves the different subreports (B+C+D).
I need this b.0 (Title Subreport_1) line at the top of each page (under the main report Page header) the Subreport 1 is displaying.
Do you have any idea about how to solve this? Thank you very much
Showing posts with label basic. Show all posts
Showing posts with label basic. Show all posts
Tuesday, March 20, 2012
Monday, March 12, 2012
Repeating a Matrix With Different Values
I have a basic matrix with a title in the top lef corner, a list of locations
down the left hand side and one column per day of reporting across the top.
My problem is that the title is actually data from another column of my
recordset. I am repeating the matrix several times and filtering on this
value to obtain the relevant records for that matrix.
What I want is to automatically repeat the matrix however many times is
necessary for the recordset to be fully output. I thought adding the matrix
to the detail row of a table would acheive this but ssrs won't allow me to do
this.
I'm relatively new to ssrs - is there any way of doing this?If i Understand your concern.
You want to show different matrices for each distinct value in the
Column of a Record set
why can't you have a list containing Matix and Group the List on column
name you want to
Group .Hope this will help you
if you want more detail
please reply
regards
Raj Deep.A
rocket salad wrote:
> I have a basic matrix with a title in the top lef corner, a list of locations
> down the left hand side and one column per day of reporting across the top.
> My problem is that the title is actually data from another column of my
> recordset. I am repeating the matrix several times and filtering on this
> value to obtain the relevant records for that matrix.
> What I want is to automatically repeat the matrix however many times is
> necessary for the recordset to be fully output. I thought adding the matrix
> to the detail row of a table would acheive this but ssrs won't allow me to do
> this.
> I'm relatively new to ssrs - is there any way of doing this?|||I've managed to get a list object to repeat the matrix. But I still can't set
the filter for the matrix to reference the list's filter's current value.
Help is much appreciated.
"rocket salad" wrote:
> I have a basic matrix with a title in the top lef corner, a list of locations
> down the left hand side and one column per day of reporting across the top.
> My problem is that the title is actually data from another column of my
> recordset. I am repeating the matrix several times and filtering on this
> value to obtain the relevant records for that matrix.
> What I want is to automatically repeat the matrix however many times is
> necessary for the recordset to be fully output. I thought adding the matrix
> to the detail row of a table would acheive this but ssrs won't allow me to do
> this.
> I'm relatively new to ssrs - is there any way of doing this?|||My test data only included one value, so the matrix didn't repeat. I had
assumed that when it did, it wouldn't automatically reference the list. As it
happens, since I've altered my source data it works fine.
Thanks.
"RajDeep" wrote:
> If i Understand your concern.
> You want to show different matrices for each distinct value in the
> Column of a Record set
> why can't you have a list containing Matix and Group the List on column
> name you want to
> Group .Hope this will help you
> if you want more detail
> please reply
> regards
> Raj Deep.A
>
> rocket salad wrote:
> > I have a basic matrix with a title in the top lef corner, a list of locations
> > down the left hand side and one column per day of reporting across the top.
> >
> > My problem is that the title is actually data from another column of my
> > recordset. I am repeating the matrix several times and filtering on this
> > value to obtain the relevant records for that matrix.
> >
> > What I want is to automatically repeat the matrix however many times is
> > necessary for the recordset to be fully output. I thought adding the matrix
> > to the detail row of a table would acheive this but ssrs won't allow me to do
> > this.
> >
> > I'm relatively new to ssrs - is there any way of doing this?
>|||So you are trying to catch something which is not in the scope.matrix
can be in Scope of list.But list cannot be in Scope of matrix
Try filter in the dataset tab.
Frankly to speak i didn't understand what exactly you are trying to do.
Filter on the Dataset will filter the records which is returned by the
datasource.
Regards
Raj Deep.A
rocket salad wrote:
> I've managed to get a list object to repeat the matrix. But I still can't set
> the filter for the matrix to reference the list's filter's current value.
> Help is much appreciated.
> "rocket salad" wrote:
> > I have a basic matrix with a title in the top lef corner, a list of locations
> > down the left hand side and one column per day of reporting across the top.
> >
> > My problem is that the title is actually data from another column of my
> > recordset. I am repeating the matrix several times and filtering on this
> > value to obtain the relevant records for that matrix.
> >
> > What I want is to automatically repeat the matrix however many times is
> > necessary for the recordset to be fully output. I thought adding the matrix
> > to the detail row of a table would acheive this but ssrs won't allow me to do
> > this.
> >
> > I'm relatively new to ssrs - is there any way of doing this?
down the left hand side and one column per day of reporting across the top.
My problem is that the title is actually data from another column of my
recordset. I am repeating the matrix several times and filtering on this
value to obtain the relevant records for that matrix.
What I want is to automatically repeat the matrix however many times is
necessary for the recordset to be fully output. I thought adding the matrix
to the detail row of a table would acheive this but ssrs won't allow me to do
this.
I'm relatively new to ssrs - is there any way of doing this?If i Understand your concern.
You want to show different matrices for each distinct value in the
Column of a Record set
why can't you have a list containing Matix and Group the List on column
name you want to
Group .Hope this will help you
if you want more detail
please reply
regards
Raj Deep.A
rocket salad wrote:
> I have a basic matrix with a title in the top lef corner, a list of locations
> down the left hand side and one column per day of reporting across the top.
> My problem is that the title is actually data from another column of my
> recordset. I am repeating the matrix several times and filtering on this
> value to obtain the relevant records for that matrix.
> What I want is to automatically repeat the matrix however many times is
> necessary for the recordset to be fully output. I thought adding the matrix
> to the detail row of a table would acheive this but ssrs won't allow me to do
> this.
> I'm relatively new to ssrs - is there any way of doing this?|||I've managed to get a list object to repeat the matrix. But I still can't set
the filter for the matrix to reference the list's filter's current value.
Help is much appreciated.
"rocket salad" wrote:
> I have a basic matrix with a title in the top lef corner, a list of locations
> down the left hand side and one column per day of reporting across the top.
> My problem is that the title is actually data from another column of my
> recordset. I am repeating the matrix several times and filtering on this
> value to obtain the relevant records for that matrix.
> What I want is to automatically repeat the matrix however many times is
> necessary for the recordset to be fully output. I thought adding the matrix
> to the detail row of a table would acheive this but ssrs won't allow me to do
> this.
> I'm relatively new to ssrs - is there any way of doing this?|||My test data only included one value, so the matrix didn't repeat. I had
assumed that when it did, it wouldn't automatically reference the list. As it
happens, since I've altered my source data it works fine.
Thanks.
"RajDeep" wrote:
> If i Understand your concern.
> You want to show different matrices for each distinct value in the
> Column of a Record set
> why can't you have a list containing Matix and Group the List on column
> name you want to
> Group .Hope this will help you
> if you want more detail
> please reply
> regards
> Raj Deep.A
>
> rocket salad wrote:
> > I have a basic matrix with a title in the top lef corner, a list of locations
> > down the left hand side and one column per day of reporting across the top.
> >
> > My problem is that the title is actually data from another column of my
> > recordset. I am repeating the matrix several times and filtering on this
> > value to obtain the relevant records for that matrix.
> >
> > What I want is to automatically repeat the matrix however many times is
> > necessary for the recordset to be fully output. I thought adding the matrix
> > to the detail row of a table would acheive this but ssrs won't allow me to do
> > this.
> >
> > I'm relatively new to ssrs - is there any way of doing this?
>|||So you are trying to catch something which is not in the scope.matrix
can be in Scope of list.But list cannot be in Scope of matrix
Try filter in the dataset tab.
Frankly to speak i didn't understand what exactly you are trying to do.
Filter on the Dataset will filter the records which is returned by the
datasource.
Regards
Raj Deep.A
rocket salad wrote:
> I've managed to get a list object to repeat the matrix. But I still can't set
> the filter for the matrix to reference the list's filter's current value.
> Help is much appreciated.
> "rocket salad" wrote:
> > I have a basic matrix with a title in the top lef corner, a list of locations
> > down the left hand side and one column per day of reporting across the top.
> >
> > My problem is that the title is actually data from another column of my
> > recordset. I am repeating the matrix several times and filtering on this
> > value to obtain the relevant records for that matrix.
> >
> > What I want is to automatically repeat the matrix however many times is
> > necessary for the recordset to be fully output. I thought adding the matrix
> > to the detail row of a table would acheive this but ssrs won't allow me to do
> > this.
> >
> > I'm relatively new to ssrs - is there any way of doing this?
Friday, March 9, 2012
Repeatable read. What is it exactly...
Sorry for such a basic question but what exactly is a Repeatable read as far
as transaction Isolation levels go. I understand the concept of serializable,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
Ant
Repeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant
|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant
|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
as transaction Isolation levels go. I understand the concept of serializable,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
Ant
Repeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant
|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant
|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
Repeatable read. What is it exactly...
Sorry for such a basic question but what exactly is a Repeatable read as far
as transaction Isolation levels go. I understand the concept of serializable
,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
AntRepeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
as transaction Isolation levels go. I understand the concept of serializable
,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
AntRepeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
Repeatable read. What is it exactly...
Sorry for such a basic question but what exactly is a Repeatable read as far
as transaction Isolation levels go. I understand the concept of serializable,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
AntRepeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
as transaction Isolation levels go. I understand the concept of serializable,
read committed & read uncommitted but i can't find any documentation that
describes the repeatable read level. How does this isolation level affect
concurrency. Sorry for such a stoopid question but it woud really help if I
got the low down once & for all. Many thanks in advance.
AntRepeatable read and serializable are very similar, and your question is far
from stupid.
In repeatable read, SQL Server will hold locks on the data you have read
until the end of the transaction. (Normally, in read committed, locks on
data you have read are released as soon as you are done reading.) So no one
can change change the data until you commit or rollback. Updates and deletes
are not permitted.
Serializable prevents INSERTS of new data that satisfy a condition that you
used for searching.
Example
BEGIN TRAN
SELECT * FROM titles
WHERE price < 5
-- suppose the above returns 2 rows; in repeatable read, those two rows are
now locked and no one can change them
-- until you commit or rollback; but someone in another connection could
insert a whole new row with price < 5
-- So, in serializable you are absolutely guaranteed that if you run the
exact SELECT again, you will get the same result:
SELECT * FROM titles
WHERE price < 5
-- But, in repeatable read, you might get more rows back, because of
inserts.
COMMIT TRAN
In repeatable read, SQL Server locks the data you read.
In serializable, SQL Server locks the data and the 'gaps' between the data.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:78571FC8-E575-4D1C-BA59-E07C2C176A80@.microsoft.com...
> Sorry for such a basic question but what exactly is a Repeatable read as
> far
> as transaction Isolation levels go. I understand the concept of
> serializable,
> read committed & read uncommitted but i can't find any documentation that
> describes the repeatable read level. How does this isolation level affect
> concurrency. Sorry for such a stoopid question but it woud really help if
> I
> got the low down once & for all. Many thanks in advance.
> Ant|||Kalen, thanks for your clear answer. I see the light! (I think)
So in fact, repeatable reads return more consistent data than read committed
as repeatable read locks the returning set until the transaction has either
been committed or rolled back,
:-
as opposed to read committed, which only locks the (committed) records
whilst the records are being read, therefore, the records in your recordset
may be updated by other transactions whilst it's sitting there in front of
you. correct?
Thanks for your help
Ant|||Hi Ant
We're only talking about shared locks here for data that has been read (with
a SELECT). So there really isn't a concept of the rows themselves being
committed.
Rows that are modified acquire EXCLUSIVE locks, and exclusive locks are
always held until the end of the transaction, no matter what isolation level
you are in.
But your final statement is true. In read committed level, you can read a
record, and someone can change it while you decide what to do with it.
On the other hand, if you are in repeatable read or serializable level, you
are preventing all access to that row, and that can have a negative impact
on performance.
There are always tradeoffs.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Ant" <Ant@.discussions.microsoft.com> wrote in message
news:7E7D398B-4FA9-4337-98CC-A0408FA2D494@.microsoft.com...
> Kalen, thanks for your clear answer. I see the light! (I think)
> So in fact, repeatable reads return more consistent data than read
> committed
> as repeatable read locks the returning set until the transaction has
> either
> been committed or rolled back,
> :-
> as opposed to read committed, which only locks the (committed) records
> whilst the records are being read, therefore, the records in your
> recordset
> may be updated by other transactions whilst it's sitting there in front of
> you. correct?
> Thanks for your help
> Ant
>
Monday, February 20, 2012
Rendering problem in browser
I have a basic report with 3 text boxes. The first text box contains a title
and two smaller text boxes. The two smaller textboxes contain a string
"Report Created:" and the date and time the report was created. The layout in
VS is correct, it is correct in the preview within in VS. When I export the
report to Adobe, Excel, etc. it is correct. However, when I deploy the report
it is not correct. The two smaller text boxes are below the main text box.
Below is an example of how I want it to look and how it looks in preview,
Adobe, Excel, etc..
|----|
| Report Title
|
|
|
|
|
| -- --
|
||Report Created:||Date and Time| |
| -- --
|
|
|
|----|
Table data
And this is how it looks in a browser:
|----|
| Report Title
|
|
|
|
|
|
|
|
|
|
|
|
|
|----|
|Report Created:|
|Date and Time|
Table data
Does anyone have any thoughts about what is going on or any suggestions on
how to correct this. I have deleted and recreated the report several times, I
have changed the properties on all the text boxes (grow, shrink, etc.) and no
luck.
Thanks.On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
<MAGrimsley@.discussions.microsoft.com> wrote:
>I have a basic report with 3 text boxes. The first text box contains a title
>and two smaller text boxes. The two smaller textboxes contain a string
>"Report Created:" and the date and time the report was created. The layout in
>VS is correct, it is correct in the preview within in VS. When I export the
>report to Adobe, Excel, etc. it is correct. However, when I deploy the report
>it is not correct. The two smaller text boxes are below the main text box.
>Below is an example of how I want it to look and how it looks in preview,
>Adobe, Excel, etc..
>|----|
>| Report Title
> |
>|
> |
>|
> |
>| -- --
> |
>||Report Created:||Date and Time| |
>| -- --
> |
>|
> |
>|----|
>Table data
>And this is how it looks in a browser:
>|----|
>| Report Title
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|----|
>|Report Created:|
> |Date and Time|
>Table data
>Does anyone have any thoughts about what is going on or any suggestions on
>how to correct this. I have deleted and recreated the report several times, I
>have changed the properties on all the text boxes (grow, shrink, etc.) and no
>luck.
>Thanks.
Your textboxes could be too close to each other. Either move them
apart, or use the header row(s) in your table instead. You can also
consolidate these 2 textboxes into 1 and set its value to:
= "Report created: " & Now()|||Thanks for your help, I combinded both textboxes to one and it stil shows up
under the main textbox.
"Usenet User" wrote:
> On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
> <MAGrimsley@.discussions.microsoft.com> wrote:
> >I have a basic report with 3 text boxes. The first text box contains a title
> >and two smaller text boxes. The two smaller textboxes contain a string
> >"Report Created:" and the date and time the report was created. The layout in
> >VS is correct, it is correct in the preview within in VS. When I export the
> >report to Adobe, Excel, etc. it is correct. However, when I deploy the report
> >it is not correct. The two smaller text boxes are below the main text box.
> >
> >Below is an example of how I want it to look and how it looks in preview,
> >Adobe, Excel, etc..
> >
> >|----|
> >| Report Title
> > |
> >|
> > |
> >|
> > |
> >| -- --
> > |
> >||Report Created:||Date and Time| |
> >| -- --
> > |
> >|
> > |
> >|----|
> >
> >Table data
> >
> >And this is how it looks in a browser:
> >
> >|----|
> >| Report Title
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|----|
> >
> >|Report Created:|
> > |Date and Time|
> >
> >Table data
> >
> >Does anyone have any thoughts about what is going on or any suggestions on
> >how to correct this. I have deleted and recreated the report several times, I
> >have changed the properties on all the text boxes (grow, shrink, etc.) and no
> >luck.
> >
> >Thanks.
>
> Your textboxes could be too close to each other. Either move them
> apart, or use the header row(s) in your table instead. You can also
> consolidate these 2 textboxes into 1 and set its value to:
> = "Report created: " & Now()
>|||On Tue, 25 Jan 2005 10:53:04 -0800, "MAGrimsley"
<MAGrimsley@.discussions.microsoft.com> wrote:
>Thanks for your help, I combinded both textboxes to one and it stil shows up
>under the main textbox.
>
Hmm, the example you provided showed Report Title on top and 2 smaller
textboxes underneath (i.e. in 2 rows) while after deployment you were
getting them in 3 rows...
Anyway, if spreading textboxes apart doesn't help (also make sure they
do not overlap), use a table instead - this is always a much cleaner
solution, no surprises. I stopped using textboxes a long time ago for
this very reason (flawed positioning), and only use them for
well-isolated fields and labels. Tables can have multiple header and
footer rows, plus you can have separate tables consisting only of
header and/or footer rows, which you can use to substitute report
headers/footers and page headers/footers.
>"Usenet User" wrote:
>> On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
>> <MAGrimsley@.discussions.microsoft.com> wrote:
>> >I have a basic report with 3 text boxes. The first text box contains a title
>> >and two smaller text boxes. The two smaller textboxes contain a string
>> >"Report Created:" and the date and time the report was created. The layout in
>> >VS is correct, it is correct in the preview within in VS. When I export the
>> >report to Adobe, Excel, etc. it is correct. However, when I deploy the report
>> >it is not correct. The two smaller text boxes are below the main text box.
>> >
>> >Below is an example of how I want it to look and how it looks in preview,
>> >Adobe, Excel, etc..
>> >
>> >|----|
>> >| Report Title
>> > |
>> >|
>> > |
>> >|
>> > |
>> >| -- --
>> > |
>> >||Report Created:||Date and Time| |
>> >| -- --
>> > |
>> >|
>> > |
>> >|----|
>> >
>> >Table data
>> >
>> >And this is how it looks in a browser:
>> >
>> >|----|
>> >| Report Title
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|----|
>> >
>> >|Report Created:|
>> > |Date and Time|
>> >
>> >Table data
>> >
>> >Does anyone have any thoughts about what is going on or any suggestions on
>> >how to correct this. I have deleted and recreated the report several times, I
>> >have changed the properties on all the text boxes (grow, shrink, etc.) and no
>> >luck.
>> >
>> >Thanks.
>>
>> Your textboxes could be too close to each other. Either move them
>> apart, or use the header row(s) in your table instead. You can also
>> consolidate these 2 textboxes into 1 and set its value to:
>> = "Report created: " & Now()
>>
and two smaller text boxes. The two smaller textboxes contain a string
"Report Created:" and the date and time the report was created. The layout in
VS is correct, it is correct in the preview within in VS. When I export the
report to Adobe, Excel, etc. it is correct. However, when I deploy the report
it is not correct. The two smaller text boxes are below the main text box.
Below is an example of how I want it to look and how it looks in preview,
Adobe, Excel, etc..
|----|
| Report Title
|
|
|
|
|
| -- --
|
||Report Created:||Date and Time| |
| -- --
|
|
|
|----|
Table data
And this is how it looks in a browser:
|----|
| Report Title
|
|
|
|
|
|
|
|
|
|
|
|
|
|----|
|Report Created:|
|Date and Time|
Table data
Does anyone have any thoughts about what is going on or any suggestions on
how to correct this. I have deleted and recreated the report several times, I
have changed the properties on all the text boxes (grow, shrink, etc.) and no
luck.
Thanks.On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
<MAGrimsley@.discussions.microsoft.com> wrote:
>I have a basic report with 3 text boxes. The first text box contains a title
>and two smaller text boxes. The two smaller textboxes contain a string
>"Report Created:" and the date and time the report was created. The layout in
>VS is correct, it is correct in the preview within in VS. When I export the
>report to Adobe, Excel, etc. it is correct. However, when I deploy the report
>it is not correct. The two smaller text boxes are below the main text box.
>Below is an example of how I want it to look and how it looks in preview,
>Adobe, Excel, etc..
>|----|
>| Report Title
> |
>|
> |
>|
> |
>| -- --
> |
>||Report Created:||Date and Time| |
>| -- --
> |
>|
> |
>|----|
>Table data
>And this is how it looks in a browser:
>|----|
>| Report Title
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|
> |
>|----|
>|Report Created:|
> |Date and Time|
>Table data
>Does anyone have any thoughts about what is going on or any suggestions on
>how to correct this. I have deleted and recreated the report several times, I
>have changed the properties on all the text boxes (grow, shrink, etc.) and no
>luck.
>Thanks.
Your textboxes could be too close to each other. Either move them
apart, or use the header row(s) in your table instead. You can also
consolidate these 2 textboxes into 1 and set its value to:
= "Report created: " & Now()|||Thanks for your help, I combinded both textboxes to one and it stil shows up
under the main textbox.
"Usenet User" wrote:
> On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
> <MAGrimsley@.discussions.microsoft.com> wrote:
> >I have a basic report with 3 text boxes. The first text box contains a title
> >and two smaller text boxes. The two smaller textboxes contain a string
> >"Report Created:" and the date and time the report was created. The layout in
> >VS is correct, it is correct in the preview within in VS. When I export the
> >report to Adobe, Excel, etc. it is correct. However, when I deploy the report
> >it is not correct. The two smaller text boxes are below the main text box.
> >
> >Below is an example of how I want it to look and how it looks in preview,
> >Adobe, Excel, etc..
> >
> >|----|
> >| Report Title
> > |
> >|
> > |
> >|
> > |
> >| -- --
> > |
> >||Report Created:||Date and Time| |
> >| -- --
> > |
> >|
> > |
> >|----|
> >
> >Table data
> >
> >And this is how it looks in a browser:
> >
> >|----|
> >| Report Title
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >|----|
> >
> >|Report Created:|
> > |Date and Time|
> >
> >Table data
> >
> >Does anyone have any thoughts about what is going on or any suggestions on
> >how to correct this. I have deleted and recreated the report several times, I
> >have changed the properties on all the text boxes (grow, shrink, etc.) and no
> >luck.
> >
> >Thanks.
>
> Your textboxes could be too close to each other. Either move them
> apart, or use the header row(s) in your table instead. You can also
> consolidate these 2 textboxes into 1 and set its value to:
> = "Report created: " & Now()
>|||On Tue, 25 Jan 2005 10:53:04 -0800, "MAGrimsley"
<MAGrimsley@.discussions.microsoft.com> wrote:
>Thanks for your help, I combinded both textboxes to one and it stil shows up
>under the main textbox.
>
Hmm, the example you provided showed Report Title on top and 2 smaller
textboxes underneath (i.e. in 2 rows) while after deployment you were
getting them in 3 rows...
Anyway, if spreading textboxes apart doesn't help (also make sure they
do not overlap), use a table instead - this is always a much cleaner
solution, no surprises. I stopped using textboxes a long time ago for
this very reason (flawed positioning), and only use them for
well-isolated fields and labels. Tables can have multiple header and
footer rows, plus you can have separate tables consisting only of
header and/or footer rows, which you can use to substitute report
headers/footers and page headers/footers.
>"Usenet User" wrote:
>> On Tue, 25 Jan 2005 09:15:04 -0800, "MAGrimsley"
>> <MAGrimsley@.discussions.microsoft.com> wrote:
>> >I have a basic report with 3 text boxes. The first text box contains a title
>> >and two smaller text boxes. The two smaller textboxes contain a string
>> >"Report Created:" and the date and time the report was created. The layout in
>> >VS is correct, it is correct in the preview within in VS. When I export the
>> >report to Adobe, Excel, etc. it is correct. However, when I deploy the report
>> >it is not correct. The two smaller text boxes are below the main text box.
>> >
>> >Below is an example of how I want it to look and how it looks in preview,
>> >Adobe, Excel, etc..
>> >
>> >|----|
>> >| Report Title
>> > |
>> >|
>> > |
>> >|
>> > |
>> >| -- --
>> > |
>> >||Report Created:||Date and Time| |
>> >| -- --
>> > |
>> >|
>> > |
>> >|----|
>> >
>> >Table data
>> >
>> >And this is how it looks in a browser:
>> >
>> >|----|
>> >| Report Title
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|
>> > |
>> >|----|
>> >
>> >|Report Created:|
>> > |Date and Time|
>> >
>> >Table data
>> >
>> >Does anyone have any thoughts about what is going on or any suggestions on
>> >how to correct this. I have deleted and recreated the report several times, I
>> >have changed the properties on all the text boxes (grow, shrink, etc.) and no
>> >luck.
>> >
>> >Thanks.
>>
>> Your textboxes could be too close to each other. Either move them
>> apart, or use the header row(s) in your table instead. You can also
>> consolidate these 2 textboxes into 1 and set its value to:
>> = "Report created: " & Now()
>>
Subscribe to:
Posts (Atom)