Hi all,
I want block attempt to drop any objects(tables, sp, views...) of my data
base.
Have way to do this?
I did see same thing about DDL trigers, any one can sed-me one sample?
Thanks to allHi all,
Thanks,
I find one sample...
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
PRINT 'You must disable Trigger "safety" to drop or alter tables!'
ROLLBACK ;
Thanks again
"retf" <re.tf@.terra.com.br> escreveu na mensagem
news:%23cQ9yq6eGHA.1272@.TK2MSFTNGP03.phx.gbl...
> Hi all,
> I want block attempt to drop any objects(tables, sp, views...) of my data
> base.
> Have way to do this?
> I did see same thing about DDL trigers, any one can sed-me one sample?
> Thanks to all
>|||This should really be
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
BEGIN
RAISERROR('You must disable Trigger "safety" to drop or alter
tables!',16,1)
ROLLBACK ;
END
Without an error, a client may think the statement suceeded.
David
"retf" <re.tf@.terra.com.br> wrote in message
news:%23P2uRt6eGHA.3484@.TK2MSFTNGP02.phx.gbl...
> Hi all,
> Thanks,
> I find one sample...
> CREATE TRIGGER safety
> ON DATABASE
> FOR DROP_TABLE, ALTER_TABLE
> AS
> PRINT 'You must disable Trigger "safety" to drop or alter tables!'
> ROLLBACK ;
>
> Thanks again
> "retf" <re.tf@.terra.com.br> escreveu na mensagem
> news:%23cQ9yq6eGHA.1272@.TK2MSFTNGP03.phx.gbl...
>|||David Browne (davidbaxterbrowne no potted meat@.hotmail.com) writes:
> This should really be
>
> CREATE TRIGGER safety
> ON DATABASE
> FOR DROP_TABLE, ALTER_TABLE
> AS
> BEGIN
> RAISERROR('You must disable Trigger "safety" to drop or alter
> tables!',16,1)
> ROLLBACK ;
> END
> Without an error, a client may think the statement suceeded.
Quibble: there will be an error message without the RAISERROR. To
wit, in SQL 2005 a ROLLBACK in a trigger raises an error message.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Showing posts with label objects. Show all posts
Showing posts with label objects. Show all posts
Wednesday, March 7, 2012
Saturday, February 25, 2012
Blobs: File System or DB?
The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
Blobs: File System or DB?
The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T
"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas
|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T
"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas
|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
Blobs: File System or DB?
The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
--
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
--
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A
Tuesday, February 14, 2012
black rectangles appearing in PDF
I have suddenly started getting black rectangles appearing on the right hand
side of PDF output.
There are no rectangles or other objects in this area of the report.
Is this a known bug?By any chance, have you included column 2 as well, and a border, then you
will get this rectangles. check in the properties for column and the border
line for left,right etc... Just to make sure you have not done these things.
Amarnath
"adolf garlic" wrote:
> I have suddenly started getting black rectangles appearing on the right hand
> side of PDF output.
> There are no rectangles or other objects in this area of the report.
> Is this a known bug?|||Just to add, the rectangle is solid black and is the same height as the table
appearing in the report.
I took a copy of the report, deleted the table and the problem went away,
but now I don't have a table...
If I move the table up and down and redeploy, recreate PDF the black
rectangle moves up and down, always in line with the table.
If I move the table left and right, the size of the rectangle changes, when
the table is pushed right up against the right hand side of the body the
rectangle disappears.
The table has dynamically hidden columns based on whether or not there is
data to show. The black rectangle has not previously been a problem.
I'm not sure what you mean by "have you included column 2". The report has
more than 2 columns but there is only one table present. There are no other
hidden or other objects to the right of the table.
"Amarnath" wrote:
> By any chance, have you included column 2 as well, and a border, then you
> will get this rectangles. check in the properties for column and the border
> line for left,right etc... Just to make sure you have not done these things.
> Amarnath
> "adolf garlic" wrote:
> > I have suddenly started getting black rectangles appearing on the right hand
> > side of PDF output.
> >
> > There are no rectangles or other objects in this area of the report.
> >
> > Is this a known bug?|||The size/position of the black rectangle is
top of the rectangle is level with the top of the table
bottom of the rectangle is level with the bottom of the table
right hand side of the rectangle is level with the right hand margin
left hand side starts where the table ends in the designer, where all
columns appear and none are hidden)
e.g.
M M
MTTTTTTTTTTTHHHBBBM
MTTTTTTTTTTTHHHBBBM
MTTTTTTTTTTTHHHBBBM
M M
where M is margin, T is table, H is hidden table, B is bloody annoying black
rectangle
I am using vs2005 sp1
"adolf garlic" wrote:
> Just to add, the rectangle is solid black and is the same height as the table
> appearing in the report.
> I took a copy of the report, deleted the table and the problem went away,
> but now I don't have a table...
> If I move the table up and down and redeploy, recreate PDF the black
> rectangle moves up and down, always in line with the table.
> If I move the table left and right, the size of the rectangle changes, when
> the table is pushed right up against the right hand side of the body the
> rectangle disappears.
> The table has dynamically hidden columns based on whether or not there is
> data to show. The black rectangle has not previously been a problem.
> I'm not sure what you mean by "have you included column 2". The report has
> more than 2 columns but there is only one table present. There are no other
> hidden or other objects to the right of the table.
> "Amarnath" wrote:
> > By any chance, have you included column 2 as well, and a border, then you
> > will get this rectangles. check in the properties for column and the border
> > line for left,right etc... Just to make sure you have not done these things.
> >
> > Amarnath
> >
> > "adolf garlic" wrote:
> >
> > > I have suddenly started getting black rectangles appearing on the right hand
> > > side of PDF output.
> > >
> > > There are no rectangles or other objects in this area of the report.
> > >
> > > Is this a known bug?
side of PDF output.
There are no rectangles or other objects in this area of the report.
Is this a known bug?By any chance, have you included column 2 as well, and a border, then you
will get this rectangles. check in the properties for column and the border
line for left,right etc... Just to make sure you have not done these things.
Amarnath
"adolf garlic" wrote:
> I have suddenly started getting black rectangles appearing on the right hand
> side of PDF output.
> There are no rectangles or other objects in this area of the report.
> Is this a known bug?|||Just to add, the rectangle is solid black and is the same height as the table
appearing in the report.
I took a copy of the report, deleted the table and the problem went away,
but now I don't have a table...
If I move the table up and down and redeploy, recreate PDF the black
rectangle moves up and down, always in line with the table.
If I move the table left and right, the size of the rectangle changes, when
the table is pushed right up against the right hand side of the body the
rectangle disappears.
The table has dynamically hidden columns based on whether or not there is
data to show. The black rectangle has not previously been a problem.
I'm not sure what you mean by "have you included column 2". The report has
more than 2 columns but there is only one table present. There are no other
hidden or other objects to the right of the table.
"Amarnath" wrote:
> By any chance, have you included column 2 as well, and a border, then you
> will get this rectangles. check in the properties for column and the border
> line for left,right etc... Just to make sure you have not done these things.
> Amarnath
> "adolf garlic" wrote:
> > I have suddenly started getting black rectangles appearing on the right hand
> > side of PDF output.
> >
> > There are no rectangles or other objects in this area of the report.
> >
> > Is this a known bug?|||The size/position of the black rectangle is
top of the rectangle is level with the top of the table
bottom of the rectangle is level with the bottom of the table
right hand side of the rectangle is level with the right hand margin
left hand side starts where the table ends in the designer, where all
columns appear and none are hidden)
e.g.
M M
MTTTTTTTTTTTHHHBBBM
MTTTTTTTTTTTHHHBBBM
MTTTTTTTTTTTHHHBBBM
M M
where M is margin, T is table, H is hidden table, B is bloody annoying black
rectangle
I am using vs2005 sp1
"adolf garlic" wrote:
> Just to add, the rectangle is solid black and is the same height as the table
> appearing in the report.
> I took a copy of the report, deleted the table and the problem went away,
> but now I don't have a table...
> If I move the table up and down and redeploy, recreate PDF the black
> rectangle moves up and down, always in line with the table.
> If I move the table left and right, the size of the rectangle changes, when
> the table is pushed right up against the right hand side of the body the
> rectangle disappears.
> The table has dynamically hidden columns based on whether or not there is
> data to show. The black rectangle has not previously been a problem.
> I'm not sure what you mean by "have you included column 2". The report has
> more than 2 columns but there is only one table present. There are no other
> hidden or other objects to the right of the table.
> "Amarnath" wrote:
> > By any chance, have you included column 2 as well, and a border, then you
> > will get this rectangles. check in the properties for column and the border
> > line for left,right etc... Just to make sure you have not done these things.
> >
> > Amarnath
> >
> > "adolf garlic" wrote:
> >
> > > I have suddenly started getting black rectangles appearing on the right hand
> > > side of PDF output.
> > >
> > > There are no rectangles or other objects in this area of the report.
> > >
> > > Is this a known bug?
Subscribe to:
Posts (Atom)