Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up &
restore the image data separately to the data in all your other tables,
which may or may not be handy for you).
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
robert madrian wrote:
>Hello,
>I must save up to 20GB of Image and Pdf's in a sqlserver db.
>Is it better to hold the table with these BLOB's in a seperate DB or
>in the same db where all the other tables are present (100 tables)?
>Are there a performance problem if the BLOB table ist in the same as
>the other data?
>Robert
>
>
|||The only reason I could imagine for putting the blobs, etc in a separate DB
is IF you wish to backup/restore them separately from the other database...
The price/penalty you pay for separating them is that you would have to use
DTC to do a single transaction which updates both databases.
I would put them together... ( SQL 2005 will allow separate backup restore
of filegroups anyway. ) so put them on a separate filegroup now, but in the
same database.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"robert madrian" <office@.madrian.at> wrote in message
news:uJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I must save up to 20GB of Image and Pdf's in a sqlserver db.
> Is it better to hold the table with these BLOB's in a seperate DB or
> in the same db where all the other tables are present (100 tables)?
> Are there a performance problem if the BLOB table ist in the same as
> the other data?
> Robert
>
|||In addition, try to describe the contents about the LOB as much as possible
with other data. I also typically segragate the LOBs from the primary data
into a segmented table and relate them 1 to 1 with the original table. This
way, I only have the JOIN ID and the LOB itself, in a table itself, in a
filegroup and file itself.
Why, because although SQL Server 2000 supports LOBS, it does a really lousy
job managing the space, especially if there are a lot of inserts and
deletes. The space reclaimation is lousy. Also, lets face it, LOBs have
nothing to do with the "descriptive" data of the database. It is just
convenient, high priced, storage and retreival. It should be segmented away
anyway.
Sincerely,
Anthony Thomas
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uVFN%23ROZFHA.3280@.TK2MSFTNGP09.phx.gbl...
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID group)
and create the image table on that filegroup. But having the image data
reside on the same disk as all the other tables shouldn't affect query
performance of those other tables (at least not in any noticeable way).
Putting it in a separate filegroup would really only give you a little more
flexibility with backup/restore strategies (as you could back up & restore
the image data separately to the data in all your other tables, which may or
may not be handy for you).
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W http://www.mallesons.com
robert madrian wrote:
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
sql
Showing posts with label pdf. Show all posts
Showing posts with label pdf. Show all posts
Monday, March 26, 2012
Images and PDF's in the same DB or in another DB?
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
RobertSame DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up &
restore the image data separately to the data in all your other tables,
which may or may not be handy for you).
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
robert madrian wrote:
>Hello,
>I must save up to 20GB of Image and Pdf's in a sqlserver db.
>Is it better to hold the table with these BLOB's in a seperate DB or
>in the same db where all the other tables are present (100 tables)?
>Are there a performance problem if the BLOB table ist in the same as
>the other data?
>Robert
>
>|||The only reason I could imagine for putting the blobs, etc in a separate DB
is IF you wish to backup/restore them separately from the other database...
The price/penalty you pay for separating them is that you would have to use
DTC to do a single transaction which updates both databases.
I would put them together... ( SQL 2005 will allow separate backup restore
of filegroups anyway. ) so put them on a separate filegroup now, but in the
same database.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"robert madrian" <office@.madrian.at> wrote in message
news:uJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I must save up to 20GB of Image and Pdf's in a sqlserver db.
> Is it better to hold the table with these BLOB's in a seperate DB or
> in the same db where all the other tables are present (100 tables)?
> Are there a performance problem if the BLOB table ist in the same as
> the other data?
> Robert
>|||In addition, try to describe the contents about the LOB as much as possible
with other data. I also typically segragate the LOBs from the primary data
into a segmented table and relate them 1 to 1 with the original table. This
way, I only have the JOIN ID and the LOB itself, in a table itself, in a
filegroup and file itself.
Why, because although SQL Server 2000 supports LOBS, it does a really lousy
job managing the space, especially if there are a lot of inserts and
deletes. The space reclaimation is lousy. Also, lets face it, LOBs have
nothing to do with the "descriptive" data of the database. It is just
convenient, high priced, storage and retreival. It should be segmented away
anyway.
Sincerely,
Anthony Thomas
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uVFN%23ROZFHA.3280@.TK2MSFTNGP09.phx.gbl...
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID group)
and create the image table on that filegroup. But having the image data
reside on the same disk as all the other tables shouldn't affect query
performance of those other tables (at least not in any noticeable way).
Putting it in a separate filegroup would really only give you a little more
flexibility with backup/restore strategies (as you could back up & restore
the image data separately to the data in all your other tables, which may or
may not be handy for you).
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W http://www.mallesons.com
robert madrian wrote:
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
RobertSame DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up &
restore the image data separately to the data in all your other tables,
which may or may not be handy for you).
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
robert madrian wrote:
>Hello,
>I must save up to 20GB of Image and Pdf's in a sqlserver db.
>Is it better to hold the table with these BLOB's in a seperate DB or
>in the same db where all the other tables are present (100 tables)?
>Are there a performance problem if the BLOB table ist in the same as
>the other data?
>Robert
>
>|||The only reason I could imagine for putting the blobs, etc in a separate DB
is IF you wish to backup/restore them separately from the other database...
The price/penalty you pay for separating them is that you would have to use
DTC to do a single transaction which updates both databases.
I would put them together... ( SQL 2005 will allow separate backup restore
of filegroups anyway. ) so put them on a separate filegroup now, but in the
same database.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"robert madrian" <office@.madrian.at> wrote in message
news:uJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I must save up to 20GB of Image and Pdf's in a sqlserver db.
> Is it better to hold the table with these BLOB's in a seperate DB or
> in the same db where all the other tables are present (100 tables)?
> Are there a performance problem if the BLOB table ist in the same as
> the other data?
> Robert
>|||In addition, try to describe the contents about the LOB as much as possible
with other data. I also typically segragate the LOBs from the primary data
into a segmented table and relate them 1 to 1 with the original table. This
way, I only have the JOIN ID and the LOB itself, in a table itself, in a
filegroup and file itself.
Why, because although SQL Server 2000 supports LOBS, it does a really lousy
job managing the space, especially if there are a lot of inserts and
deletes. The space reclaimation is lousy. Also, lets face it, LOBs have
nothing to do with the "descriptive" data of the database. It is just
convenient, high priced, storage and retreival. It should be segmented away
anyway.
Sincerely,
Anthony Thomas
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uVFN%23ROZFHA.3280@.TK2MSFTNGP09.phx.gbl...
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID group)
and create the image table on that filegroup. But having the image data
reside on the same disk as all the other tables shouldn't affect query
performance of those other tables (at least not in any noticeable way).
Putting it in a separate filegroup would really only give you a little more
flexibility with backup/restore strategies (as you could back up & restore
the image data separately to the data in all your other tables, which may or
may not be handy for you).
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W http://www.mallesons.com
robert madrian wrote:
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
Images and PDF's in the same DB or in another DB?
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
RobertThis is a multi-part message in MIME format.
--040906000104030808000509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up &
restore the image data separately to the data in all your other tables,
which may or may not be handy for you).
--
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
robert madrian wrote:
>Hello,
>I must save up to 20GB of Image and Pdf's in a sqlserver db.
>Is it better to hold the table with these BLOB's in a seperate DB or
>in the same db where all the other tables are present (100 tables)?
>Are there a performance problem if the BLOB table ist in the same as
>the other data?
>Robert
>
>
--040906000104030808000509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Same DB.<br>
<br>
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).<br>
<br>
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up
& restore the image data separately to the data in all your other
tables, which may or may not be handy for you).<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font> </span><b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"> <font face="Tahoma"
size="2">|</font><i><font face="Tahoma"> </font><font face="Tahoma"
size="2"> database administrator</font></i><font face="Tahoma" size="2">
| mallesons</font><font face="Tahoma"> </font><font face="Tahoma"
size="2">stephen</font><font face="Tahoma"> </font><font face="Tahoma"
size="2"> jaques</font><font face="Tahoma"><br>
</font><b><font face="Tahoma" size="2">T</font></b><font face="Tahoma"
size="2"> +61 (2) 9296 3668 |</font><b><font face="Tahoma"> </font><font
face="Tahoma" size="2"> F</font></b><font face="Tahoma" size="2"> +61
(2) 9296 3885 |</font><b><font face="Tahoma"> </font><font
face="Tahoma" size="2">M</font></b><font face="Tahoma" size="2"> +61
(408) 675 907</font><br>
<b><font face="Tahoma" size="2">E</font></b><font face="Tahoma" size="2">
<a href="http://links.10026.com/?link=mailto:mike.hodgson@.mallesons.nospam.com">
mailto:mike.hodgson@.mallesons.nospam.com</a> |</font><b><font
face="Tahoma"> </font><font face="Tahoma" size="2">W</font></b><font
face="Tahoma" size="2"> <a href="http://links.10026.com/?link=/">http://www.mallesons.com">
http://www.mallesons.com</a></font></span> </p>
</div>
<br>
<br>
robert madrian wrote:
<blockquote cite="miduJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl" type="cite">
<pre wrap="">Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
</pre>
</blockquote>
</body>
</html>
--040906000104030808000509--|||The only reason I could imagine for putting the blobs, etc in a separate DB
is IF you wish to backup/restore them separately from the other database...
The price/penalty you pay for separating them is that you would have to use
DTC to do a single transaction which updates both databases.
I would put them together... ( SQL 2005 will allow separate backup restore
of filegroups anyway. ) so put them on a separate filegroup now, but in the
same database.
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"robert madrian" <office@.madrian.at> wrote in message
news:uJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I must save up to 20GB of Image and Pdf's in a sqlserver db.
> Is it better to hold the table with these BLOB's in a seperate DB or
> in the same db where all the other tables are present (100 tables)?
> Are there a performance problem if the BLOB table ist in the same as
> the other data?
> Robert
>|||In addition, try to describe the contents about the LOB as much as possible
with other data. I also typically segragate the LOBs from the primary data
into a segmented table and relate them 1 to 1 with the original table. This
way, I only have the JOIN ID and the LOB itself, in a table itself, in a
filegroup and file itself.
Why, because although SQL Server 2000 supports LOBS, it does a really lousy
job managing the space, especially if there are a lot of inserts and
deletes. The space reclaimation is lousy. Also, lets face it, LOBs have
nothing to do with the "descriptive" data of the database. It is just
convenient, high priced, storage and retreival. It should be segmented away
anyway.
Sincerely,
Anthony Thomas
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uVFN%23ROZFHA.3280@.TK2MSFTNGP09.phx.gbl...
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID group)
and create the image table on that filegroup. But having the image data
reside on the same disk as all the other tables shouldn't affect query
performance of those other tables (at least not in any noticeable way).
Putting it in a separate filegroup would really only give you a little more
flexibility with backup/restore strategies (as you could back up & restore
the image data separately to the data in all your other tables, which may or
may not be handy for you).
--
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W http://www.mallesons.com
robert madrian wrote:
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
RobertThis is a multi-part message in MIME format.
--040906000104030808000509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up &
restore the image data separately to the data in all your other tables,
which may or may not be handy for you).
--
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
robert madrian wrote:
>Hello,
>I must save up to 20GB of Image and Pdf's in a sqlserver db.
>Is it better to hold the table with these BLOB's in a seperate DB or
>in the same db where all the other tables are present (100 tables)?
>Are there a performance problem if the BLOB table ist in the same as
>the other data?
>Robert
>
>
--040906000104030808000509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Same DB.<br>
<br>
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID
group) and create the image table on that filegroup. But having the
image data reside on the same disk as all the other tables shouldn't
affect query performance of those other tables (at least not in any
noticeable way).<br>
<br>
Putting it in a separate filegroup would really only give you a little
more flexibility with backup/restore strategies (as you could back up
& restore the image data separately to the data in all your other
tables, which may or may not be handy for you).<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font> </span><b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"> <font face="Tahoma"
size="2">|</font><i><font face="Tahoma"> </font><font face="Tahoma"
size="2"> database administrator</font></i><font face="Tahoma" size="2">
| mallesons</font><font face="Tahoma"> </font><font face="Tahoma"
size="2">stephen</font><font face="Tahoma"> </font><font face="Tahoma"
size="2"> jaques</font><font face="Tahoma"><br>
</font><b><font face="Tahoma" size="2">T</font></b><font face="Tahoma"
size="2"> +61 (2) 9296 3668 |</font><b><font face="Tahoma"> </font><font
face="Tahoma" size="2"> F</font></b><font face="Tahoma" size="2"> +61
(2) 9296 3885 |</font><b><font face="Tahoma"> </font><font
face="Tahoma" size="2">M</font></b><font face="Tahoma" size="2"> +61
(408) 675 907</font><br>
<b><font face="Tahoma" size="2">E</font></b><font face="Tahoma" size="2">
<a href="http://links.10026.com/?link=mailto:mike.hodgson@.mallesons.nospam.com">
mailto:mike.hodgson@.mallesons.nospam.com</a> |</font><b><font
face="Tahoma"> </font><font face="Tahoma" size="2">W</font></b><font
face="Tahoma" size="2"> <a href="http://links.10026.com/?link=/">http://www.mallesons.com">
http://www.mallesons.com</a></font></span> </p>
</div>
<br>
<br>
robert madrian wrote:
<blockquote cite="miduJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl" type="cite">
<pre wrap="">Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
</pre>
</blockquote>
</body>
</html>
--040906000104030808000509--|||The only reason I could imagine for putting the blobs, etc in a separate DB
is IF you wish to backup/restore them separately from the other database...
The price/penalty you pay for separating them is that you would have to use
DTC to do a single transaction which updates both databases.
I would put them together... ( SQL 2005 will allow separate backup restore
of filegroups anyway. ) so put them on a separate filegroup now, but in the
same database.
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"robert madrian" <office@.madrian.at> wrote in message
news:uJkNqFOZFHA.2688@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I must save up to 20GB of Image and Pdf's in a sqlserver db.
> Is it better to hold the table with these BLOB's in a seperate DB or
> in the same db where all the other tables are present (100 tables)?
> Are there a performance problem if the BLOB table ist in the same as
> the other data?
> Robert
>|||In addition, try to describe the contents about the LOB as much as possible
with other data. I also typically segragate the LOBs from the primary data
into a segmented table and relate them 1 to 1 with the original table. This
way, I only have the JOIN ID and the LOB itself, in a table itself, in a
filegroup and file itself.
Why, because although SQL Server 2000 supports LOBS, it does a really lousy
job managing the space, especially if there are a lot of inserts and
deletes. The space reclaimation is lousy. Also, lets face it, LOBs have
nothing to do with the "descriptive" data of the database. It is just
convenient, high priced, storage and retreival. It should be segmented away
anyway.
Sincerely,
Anthony Thomas
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uVFN%23ROZFHA.3280@.TK2MSFTNGP09.phx.gbl...
Same DB.
If you're concerned about IO performance at all you can always create
another filegroup consisting of a file on a different disk (or RAID group)
and create the image table on that filegroup. But having the image data
reside on the same disk as all the other tables shouldn't affect query
performance of those other tables (at least not in any noticeable way).
Putting it in a separate filegroup would really only give you a little more
flexibility with backup/restore strategies (as you could back up & restore
the image data separately to the data in all your other tables, which may or
may not be handy for you).
--
mike hodgson | database administrator | mallesons stephen jaques
T +61 (2) 9296 3668 | F +61 (2) 9296 3885 | M +61 (408) 675 907
E mailto:mike.hodgson@.mallesons.nospam.com | W http://www.mallesons.com
robert madrian wrote:
Hello,
I must save up to 20GB of Image and Pdf's in a sqlserver db.
Is it better to hold the table with these BLOB's in a seperate DB or
in the same db where all the other tables are present (100 tables)?
Are there a performance problem if the BLOB table ist in the same as
the other data?
Robert
Images and PDF Export POST SP2
I've come accross the same problem having also installed SP2. Still looking
for the answer.
I did notice that exporting via the preview window in Visual Studio works
perfectly. It's only exporting to pdf via a browser that causes the
scrambled images.
Does anyone have a work around, besides changing every report to read a png
image? We still need transparency.
Ryan
>On Follow Up.. this appears to be images other than JPEG's, which according
>to documentation are all rendered as PNG's.
>"Rob Johnson" wrote:
>> After installing RS SP2, images included in my reports display fine in
>> HTML
>> View, Excel View and TIFF View, but when exported to PDF they are not
>> displaying properly (they appear garbled, much like a scrambled TV
>> signal).
>>
>> Any ideas or thoughts?Same issue here, although my image is being converted at runtime to png via a
.Net assembly. I get the same results through the browser and VS IDE.
"Ryan Opfer" wrote:
> I've come accross the same problem having also installed SP2. Still looking
> for the answer.
> I did notice that exporting via the preview window in Visual Studio works
> perfectly. It's only exporting to pdf via a browser that causes the
> scrambled images.
> Does anyone have a work around, besides changing every report to read a png
> image? We still need transparency.
> Ryan
> >On Follow Up.. this appears to be images other than JPEG's, which according
> >to documentation are all rendered as PNG's.
> >"Rob Johnson" wrote:
> >> After installing RS SP2, images included in my reports display fine in
> >> HTML
> >> View, Excel View and TIFF View, but when exported to PDF they are not
> >> displaying properly (they appear garbled, much like a scrambled TV
> >> signal).
> >>
> >> Any ideas or thoughts?
>
>|||I use a custom centering/scaling function as the data source for my image
control. Converting the function's output to either GIF or JPEG eliminated
the problem for me. I have my image control's format set to JPEG. The
problem appears for me when the function's output is set to PNG.
"Ryan Opfer" wrote:
> I've come accross the same problem having also installed SP2. Still looking
> for the answer.
> I did notice that exporting via the preview window in Visual Studio works
> perfectly. It's only exporting to pdf via a browser that causes the
> scrambled images.
> Does anyone have a work around, besides changing every report to read a png
> image? We still need transparency.
> Ryan
> >On Follow Up.. this appears to be images other than JPEG's, which according
> >to documentation are all rendered as PNG's.
> >"Rob Johnson" wrote:
> >> After installing RS SP2, images included in my reports display fine in
> >> HTML
> >> View, Excel View and TIFF View, but when exported to PDF they are not
> >> displaying properly (they appear garbled, much like a scrambled TV
> >> signal).
> >>
> >> Any ideas or thoughts?
>
>|||I've tried a couple of images and didn't see PNG corruption when exporting
to PDF. Would one of you please email me a sample PNG that is exhibiting
this behavior so I can take a look? Thank you.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>I use a custom centering/scaling function as the data source for my image
> control. Converting the function's output to either GIF or JPEG
> eliminated
> the problem for me. I have my image control's format set to JPEG. The
> problem appears for me when the function's output is set to PNG.
> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>|||We don't currently support true color w/alpha PNG files, only indexed color
(color type 3). If your graphics editing program allows you to specify the
color type of your PNG and save it as a type 3 file you should be fine.
Prior to SP2, we converted all images to bitmaps which bloated the PDF file.
We now compress but have less flexibility on certain image types.
I've opened a bug for this issue so we can hopefully get it fixed in Yukon.
The easiest work-around for our SQL Server 2000 release is to save as a type
3 file or use a jpg.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
> Thanks Donovan for looking into this. Here is our logo
> (logoRenderedFromBrowser.png). It was originally a GIF image but when
> rendered to the browser it becomes a png image (perhaps a reason why we
> can export to PDF via visual studio but not from the browser). Also
> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
> directly after export to pdf via the browser.
> Again, prior to SP2 all reports exported as expected via the browser to
> pdf. One can only assume that there's been a change with sp2.
> Thanks in advance,
> Ryan
>
> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG. The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine
>> >> in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>
>|||Thanks Donovan for the information. I was in error when I had said that we
were originally using a GIF image and that RS was converting it when
rendering for the browser. We are indeed using png files at 24 bit.
I did save the image as png-8 (which I assume is color type 3) which does
fix this problem--although it's lousy quality.
So thanks again for the solution/work around.
Ryan
It is interesting though that you mention that RS doesn't currently support
true color w/alpha PNG files. I'm not even using PNG, it's RS that is
converting it to
"Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
> We don't currently support true color w/alpha PNG files, only indexed
> color (color type 3). If your graphics editing program allows you to
> specify the color type of your PNG and save it as a type 3 file you should
> be fine. Prior to SP2, we converted all images to bitmaps which bloated
> the PDF file. We now compress but have less flexibility on certain image
> types.
> I've opened a bug for this issue so we can hopefully get it fixed in
> Yukon. The easiest work-around for our SQL Server 2000 release is to save
> as a type 3 file or use a jpg.
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG. The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read
>> a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine
>> >> in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>>
>>
>|||Ah, OK. I couldn't quite understand the GIF part of your message. :)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
news:ep6g6EAXFHA.3348@.TK2MSFTNGP14.phx.gbl...
> Thanks Donovan for the information. I was in error when I had said that
> we were originally using a GIF image and that RS was converting it when
> rendering for the browser. We are indeed using png files at 24 bit.
> I did save the image as png-8 (which I assume is color type 3) which does
> fix this problem--although it's lousy quality.
> So thanks again for the solution/work around.
> Ryan
> It is interesting though that you mention that RS doesn't currently
> support true color w/alpha PNG files. I'm not even using PNG, it's RS
> that is converting it to
> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
> news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> We don't currently support true color w/alpha PNG files, only indexed
>> color (color type 3). If your graphics editing program allows you to
>> specify the color type of your PNG and save it as a type 3 file you
>> should be fine. Prior to SP2, we converted all images to bitmaps which
>> bloated the PDF file. We now compress but have less flexibility on
>> certain image types.
>> I've opened a bug for this issue so we can hopefully get it fixed in
>> Yukon. The easiest work-around for our SQL Server 2000 release is to save
>> as a type 3 file or use a jpg.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
>> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG.
>> The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read
>> a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display
>> >> fine in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>>
>>
>>
>|||One more export issue. When exporting to pdf using the 8 bit png image
(color type 3) from the browser, transparency doesn't work (and it use to
under SP1). As proof that the image is transparent, I can print using the
new print button and transparency works fine. Also when exporting to pdf
via Visual Studio transparency works fine as well (of course so did the 24
bit png).
At least it's not scrambled though!
Ryan
"Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
news:%23MmyV8AXFHA.2288@.TK2MSFTNGP14.phx.gbl...
> Ah, OK. I couldn't quite understand the GIF part of your message. :)
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
> news:ep6g6EAXFHA.3348@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for the information. I was in error when I had said that
>> we were originally using a GIF image and that RS was converting it when
>> rendering for the browser. We are indeed using png files at 24 bit.
>> I did save the image as png-8 (which I assume is color type 3) which does
>> fix this problem--although it's lousy quality.
>> So thanks again for the solution/work around.
>> Ryan
>> It is interesting though that you mention that RS doesn't currently
>> support true color w/alpha PNG files. I'm not even using PNG, it's RS
>> that is converting it to
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> We don't currently support true color w/alpha PNG files, only indexed
>> color (color type 3). If your graphics editing program allows you to
>> specify the color type of your PNG and save it as a type 3 file you
>> should be fine. Prior to SP2, we converted all images to bitmaps which
>> bloated the PDF file. We now compress but have less flexibility on
>> certain image types.
>> I've opened a bug for this issue so we can hopefully get it fixed in
>> Yukon. The easiest work-around for our SQL Server 2000 release is to
>> save as a type 3 file or use a jpg.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
>> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG.
>> The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>>> I've come accross the same problem having also installed SP2. Still
>>> looking
>>> for the answer.
>>>
>>> I did notice that exporting via the preview window in Visual Studio
>>> works
>>> perfectly. It's only exporting to pdf via a browser that causes the
>>> scrambled images.
>>>
>>> Does anyone have a work around, besides changing every report to
>>> read a
>>> png
>>> image? We still need transparency.
>>>
>>> Ryan
>>> >On Follow Up.. this appears to be images other than JPEG's, which
>>> >according
>>> >to documentation are all rendered as PNG's.
>>>
>>> >"Rob Johnson" wrote:
>>>
>>> >> After installing RS SP2, images included in my reports display
>>> >> fine in
>>> >> HTML
>>> >> View, Excel View and TIFF View, but when exported to PDF they are
>>> >> not
>>> >> displaying properly (they appear garbled, much like a scrambled
>>> >> TV
>>> >> signal).
>>> >>
>>> >> Any ideas or thoughts?
>>>
>>>
>>>
>>
>>
>>
>>
>
for the answer.
I did notice that exporting via the preview window in Visual Studio works
perfectly. It's only exporting to pdf via a browser that causes the
scrambled images.
Does anyone have a work around, besides changing every report to read a png
image? We still need transparency.
Ryan
>On Follow Up.. this appears to be images other than JPEG's, which according
>to documentation are all rendered as PNG's.
>"Rob Johnson" wrote:
>> After installing RS SP2, images included in my reports display fine in
>> HTML
>> View, Excel View and TIFF View, but when exported to PDF they are not
>> displaying properly (they appear garbled, much like a scrambled TV
>> signal).
>>
>> Any ideas or thoughts?Same issue here, although my image is being converted at runtime to png via a
.Net assembly. I get the same results through the browser and VS IDE.
"Ryan Opfer" wrote:
> I've come accross the same problem having also installed SP2. Still looking
> for the answer.
> I did notice that exporting via the preview window in Visual Studio works
> perfectly. It's only exporting to pdf via a browser that causes the
> scrambled images.
> Does anyone have a work around, besides changing every report to read a png
> image? We still need transparency.
> Ryan
> >On Follow Up.. this appears to be images other than JPEG's, which according
> >to documentation are all rendered as PNG's.
> >"Rob Johnson" wrote:
> >> After installing RS SP2, images included in my reports display fine in
> >> HTML
> >> View, Excel View and TIFF View, but when exported to PDF they are not
> >> displaying properly (they appear garbled, much like a scrambled TV
> >> signal).
> >>
> >> Any ideas or thoughts?
>
>|||I use a custom centering/scaling function as the data source for my image
control. Converting the function's output to either GIF or JPEG eliminated
the problem for me. I have my image control's format set to JPEG. The
problem appears for me when the function's output is set to PNG.
"Ryan Opfer" wrote:
> I've come accross the same problem having also installed SP2. Still looking
> for the answer.
> I did notice that exporting via the preview window in Visual Studio works
> perfectly. It's only exporting to pdf via a browser that causes the
> scrambled images.
> Does anyone have a work around, besides changing every report to read a png
> image? We still need transparency.
> Ryan
> >On Follow Up.. this appears to be images other than JPEG's, which according
> >to documentation are all rendered as PNG's.
> >"Rob Johnson" wrote:
> >> After installing RS SP2, images included in my reports display fine in
> >> HTML
> >> View, Excel View and TIFF View, but when exported to PDF they are not
> >> displaying properly (they appear garbled, much like a scrambled TV
> >> signal).
> >>
> >> Any ideas or thoughts?
>
>|||I've tried a couple of images and didn't see PNG corruption when exporting
to PDF. Would one of you please email me a sample PNG that is exhibiting
this behavior so I can take a look? Thank you.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>I use a custom centering/scaling function as the data source for my image
> control. Converting the function's output to either GIF or JPEG
> eliminated
> the problem for me. I have my image control's format set to JPEG. The
> problem appears for me when the function's output is set to PNG.
> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>|||We don't currently support true color w/alpha PNG files, only indexed color
(color type 3). If your graphics editing program allows you to specify the
color type of your PNG and save it as a type 3 file you should be fine.
Prior to SP2, we converted all images to bitmaps which bloated the PDF file.
We now compress but have less flexibility on certain image types.
I've opened a bug for this issue so we can hopefully get it fixed in Yukon.
The easiest work-around for our SQL Server 2000 release is to save as a type
3 file or use a jpg.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
> Thanks Donovan for looking into this. Here is our logo
> (logoRenderedFromBrowser.png). It was originally a GIF image but when
> rendered to the browser it becomes a png image (perhaps a reason why we
> can export to PDF via visual studio but not from the browser). Also
> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
> directly after export to pdf via the browser.
> Again, prior to SP2 all reports exported as expected via the browser to
> pdf. One can only assume that there's been a change with sp2.
> Thanks in advance,
> Ryan
>
> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG. The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine
>> >> in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>
>|||Thanks Donovan for the information. I was in error when I had said that we
were originally using a GIF image and that RS was converting it when
rendering for the browser. We are indeed using png files at 24 bit.
I did save the image as png-8 (which I assume is color type 3) which does
fix this problem--although it's lousy quality.
So thanks again for the solution/work around.
Ryan
It is interesting though that you mention that RS doesn't currently support
true color w/alpha PNG files. I'm not even using PNG, it's RS that is
converting it to
"Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
> We don't currently support true color w/alpha PNG files, only indexed
> color (color type 3). If your graphics editing program allows you to
> specify the color type of your PNG and save it as a type 3 file you should
> be fine. Prior to SP2, we converted all images to bitmaps which bloated
> the PDF file. We now compress but have less flexibility on certain image
> types.
> I've opened a bug for this issue so we can hopefully get it fixed in
> Yukon. The easiest work-around for our SQL Server 2000 release is to save
> as a type 3 file or use a jpg.
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG. The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read
>> a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display fine
>> >> in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>>
>>
>|||Ah, OK. I couldn't quite understand the GIF part of your message. :)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
news:ep6g6EAXFHA.3348@.TK2MSFTNGP14.phx.gbl...
> Thanks Donovan for the information. I was in error when I had said that
> we were originally using a GIF image and that RS was converting it when
> rendering for the browser. We are indeed using png files at 24 bit.
> I did save the image as png-8 (which I assume is color type 3) which does
> fix this problem--although it's lousy quality.
> So thanks again for the solution/work around.
> Ryan
> It is interesting though that you mention that RS doesn't currently
> support true color w/alpha PNG files. I'm not even using PNG, it's RS
> that is converting it to
> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
> news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> We don't currently support true color w/alpha PNG files, only indexed
>> color (color type 3). If your graphics editing program allows you to
>> specify the color type of your PNG and save it as a type 3 file you
>> should be fine. Prior to SP2, we converted all images to bitmaps which
>> bloated the PDF file. We now compress but have less flexibility on
>> certain image types.
>> I've opened a bug for this issue so we can hopefully get it fixed in
>> Yukon. The easiest work-around for our SQL Server 2000 release is to save
>> as a type 3 file or use a jpg.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
>> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG.
>> The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>> I've come accross the same problem having also installed SP2. Still
>> looking
>> for the answer.
>> I did notice that exporting via the preview window in Visual Studio
>> works
>> perfectly. It's only exporting to pdf via a browser that causes the
>> scrambled images.
>> Does anyone have a work around, besides changing every report to read
>> a
>> png
>> image? We still need transparency.
>> Ryan
>> >On Follow Up.. this appears to be images other than JPEG's, which
>> >according
>> >to documentation are all rendered as PNG's.
>> >"Rob Johnson" wrote:
>> >> After installing RS SP2, images included in my reports display
>> >> fine in
>> >> HTML
>> >> View, Excel View and TIFF View, but when exported to PDF they are
>> >> not
>> >> displaying properly (they appear garbled, much like a scrambled TV
>> >> signal).
>> >>
>> >> Any ideas or thoughts?
>>
>>
>>
>>
>>
>|||One more export issue. When exporting to pdf using the 8 bit png image
(color type 3) from the browser, transparency doesn't work (and it use to
under SP1). As proof that the image is transparent, I can print using the
new print button and transparency works fine. Also when exporting to pdf
via Visual Studio transparency works fine as well (of course so did the 24
bit png).
At least it's not scrambled though!
Ryan
"Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
news:%23MmyV8AXFHA.2288@.TK2MSFTNGP14.phx.gbl...
> Ah, OK. I couldn't quite understand the GIF part of your message. :)
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
> news:ep6g6EAXFHA.3348@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for the information. I was in error when I had said that
>> we were originally using a GIF image and that RS was converting it when
>> rendering for the browser. We are indeed using png files at 24 bit.
>> I did save the image as png-8 (which I assume is color type 3) which does
>> fix this problem--although it's lousy quality.
>> So thanks again for the solution/work around.
>> Ryan
>> It is interesting though that you mention that RS doesn't currently
>> support true color w/alpha PNG files. I'm not even using PNG, it's RS
>> that is converting it to
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:eXILSR1WFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> We don't currently support true color w/alpha PNG files, only indexed
>> color (color type 3). If your graphics editing program allows you to
>> specify the color type of your PNG and save it as a type 3 file you
>> should be fine. Prior to SP2, we converted all images to bitmaps which
>> bloated the PDF file. We now compress but have less flexibility on
>> certain image types.
>> I've opened a bug for this issue so we can hopefully get it fixed in
>> Yukon. The easiest work-around for our SQL Server 2000 release is to
>> save as a type 3 file or use a jpg.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ryan Opfer" <ropfer@.usa.ibs.org> wrote in message
>> news:%23IailDwWFHA.3584@.TK2MSFTNGP14.phx.gbl...
>> Thanks Donovan for looking into this. Here is our logo
>> (logoRenderedFromBrowser.png). It was originally a GIF image but when
>> rendered to the browser it becomes a png image (perhaps a reason why we
>> can export to PDF via visual studio but not from the browser). Also
>> attached is the scrambled logo (scrambledImage.jpg) screen shot taken
>> directly after export to pdf via the browser.
>> Again, prior to SP2 all reports exported as expected via the browser to
>> pdf. One can only assume that there's been a change with sp2.
>> Thanks in advance,
>> Ryan
>>
>> "Donovan Smith [MSFT]" <donovans@.online.microsoft.com> wrote in message
>> news:%23b0JjJnWFHA.2256@.TK2MSFTNGP14.phx.gbl...
>> I've tried a couple of images and didn't see PNG corruption when
>> exporting
>> to PDF. Would one of you please email me a sample PNG that is
>> exhibiting
>> this behavior so I can take a look? Thank you.
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Ken Fox" <KenFox@.discussions.microsoft.com> wrote in message
>> news:DF0704F5-B6DF-4BEF-A042-0DE8D7E0F30D@.microsoft.com...
>>I use a custom centering/scaling function as the data source for my
>>image
>> control. Converting the function's output to either GIF or JPEG
>> eliminated
>> the problem for me. I have my image control's format set to JPEG.
>> The
>> problem appears for me when the function's output is set to PNG.
>> "Ryan Opfer" wrote:
>>> I've come accross the same problem having also installed SP2. Still
>>> looking
>>> for the answer.
>>>
>>> I did notice that exporting via the preview window in Visual Studio
>>> works
>>> perfectly. It's only exporting to pdf via a browser that causes the
>>> scrambled images.
>>>
>>> Does anyone have a work around, besides changing every report to
>>> read a
>>> png
>>> image? We still need transparency.
>>>
>>> Ryan
>>> >On Follow Up.. this appears to be images other than JPEG's, which
>>> >according
>>> >to documentation are all rendered as PNG's.
>>>
>>> >"Rob Johnson" wrote:
>>>
>>> >> After installing RS SP2, images included in my reports display
>>> >> fine in
>>> >> HTML
>>> >> View, Excel View and TIFF View, but when exported to PDF they are
>>> >> not
>>> >> displaying properly (they appear garbled, much like a scrambled
>>> >> TV
>>> >> signal).
>>> >>
>>> >> Any ideas or thoughts?
>>>
>>>
>>>
>>
>>
>>
>>
>
Images and PDF Export POST SP2
After installing RS SP2, images included in my reports display fine in HTML
View, Excel View and TIFF View, but when exported to PDF they are not
displaying properly (they appear garbled, much like a scrambled TV signal).
Any ideas or thoughts?On Follow Up.. this appears to be images other than JPEG's, which according
to documentation are all rendered as PNG's.
"Rob Johnson" wrote:
> After installing RS SP2, images included in my reports display fine in HTML
> View, Excel View and TIFF View, but when exported to PDF they are not
> displaying properly (they appear garbled, much like a scrambled TV signal).
> Any ideas or thoughts?
View, Excel View and TIFF View, but when exported to PDF they are not
displaying properly (they appear garbled, much like a scrambled TV signal).
Any ideas or thoughts?On Follow Up.. this appears to be images other than JPEG's, which according
to documentation are all rendered as PNG's.
"Rob Johnson" wrote:
> After installing RS SP2, images included in my reports display fine in HTML
> View, Excel View and TIFF View, but when exported to PDF they are not
> displaying properly (they appear garbled, much like a scrambled TV signal).
> Any ideas or thoughts?
Image size
I have a SQL database that stores image files (pdf, doc, tif etc). Is it
possible to write a query that shows the size of the file being stored ?
Any help would be great.
Thanks
SiYou can get the bytes used with DATALENGTH -
SELECT DATALENGTH(YourImageColumn)
FROM YourTable
You can find more information on DATALENGTH in Books Online.
-Sue
On Mon, 31 Jul 2006 08:36:01 -0700, Simon
<Simon@.discussions.microsoft.com> wrote:
>I have a SQL database that stores image files (pdf, doc, tif etc). Is it
>possible to write a query that shows the size of the file being stored ?
>Any help would be great.
>Thanks
>Si
possible to write a query that shows the size of the file being stored ?
Any help would be great.
Thanks
SiYou can get the bytes used with DATALENGTH -
SELECT DATALENGTH(YourImageColumn)
FROM YourTable
You can find more information on DATALENGTH in Books Online.
-Sue
On Mon, 31 Jul 2006 08:36:01 -0700, Simon
<Simon@.discussions.microsoft.com> wrote:
>I have a SQL database that stores image files (pdf, doc, tif etc). Is it
>possible to write a query that shows the size of the file being stored ?
>Any help would be great.
>Thanks
>Si
Image size
I have a SQL database that stores image files (pdf, doc, tif etc). Is it
possible to write a query that shows the size of the file being stored ?
Any help would be great.
Thanks
SiYou can get the bytes used with DATALENGTH -
SELECT DATALENGTH(YourImageColumn)
FROM YourTable
You can find more information on DATALENGTH in Books Online.
-Sue
On Mon, 31 Jul 2006 08:36:01 -0700, Simon
<Simon@.discussions.microsoft.com> wrote:
>I have a SQL database that stores image files (pdf, doc, tif etc). Is it
>possible to write a query that shows the size of the file being stored ?
>Any help would be great.
>Thanks
>Si
possible to write a query that shows the size of the file being stored ?
Any help would be great.
Thanks
SiYou can get the bytes used with DATALENGTH -
SELECT DATALENGTH(YourImageColumn)
FROM YourTable
You can find more information on DATALENGTH in Books Online.
-Sue
On Mon, 31 Jul 2006 08:36:01 -0700, Simon
<Simon@.discussions.microsoft.com> wrote:
>I have a SQL database that stores image files (pdf, doc, tif etc). Is it
>possible to write a query that shows the size of the file being stored ?
>Any help would be great.
>Thanks
>Si
Friday, March 23, 2012
Image problem when exporting to PDF
Hi,
I am having a image problem when I export a report to PDF. The images
in the report are being pulled from the database. They appear just
fine in print preview and I can even export to a Tiff format without
any problem. When I export to PDF, I can open the document but when it
gets to certain images, it displays a "drawing error" message and the
rest of the report is blank (Reader 7). I upgraded to Adobe Reader 8,
and now I am getting the same type results, but the error message is
"Insufficient data for Image". I have even tried using the "Web" as
the image source and point to the actual images, but I still get the
same results when I export to PDF.
Any suggestions would be greatly appreciated.
Thanks,
Amy BoldenAmy wrote:
> Hi,
> I am having a image problem when I export a report to PDF. The images
> in the report are being pulled from the database. They appear just
> fine in print preview and I can even export to a Tiff format without
> any problem. When I export to PDF, I can open the document but when it
> gets to certain images, it displays a "drawing error" message and the
> rest of the report is blank (Reader 7). I upgraded to Adobe Reader 8,
> and now I am getting the same type results, but the error message is
> "Insufficient data for Image". I have even tried using the "Web" as
> the image source and point to the actual images, but I still get the
> same results when I export to PDF.
> Any suggestions would be greatly appreciated.
> Thanks,
> Amy Bolden
This is one of the strangest problems I have ever encountered, but at
least I was able to find a solution. For some strange reason, when I
would change all the jpg image to gif, the conversion to pdf worked
just fine. Weird.
Thanks,
Amy
I am having a image problem when I export a report to PDF. The images
in the report are being pulled from the database. They appear just
fine in print preview and I can even export to a Tiff format without
any problem. When I export to PDF, I can open the document but when it
gets to certain images, it displays a "drawing error" message and the
rest of the report is blank (Reader 7). I upgraded to Adobe Reader 8,
and now I am getting the same type results, but the error message is
"Insufficient data for Image". I have even tried using the "Web" as
the image source and point to the actual images, but I still get the
same results when I export to PDF.
Any suggestions would be greatly appreciated.
Thanks,
Amy BoldenAmy wrote:
> Hi,
> I am having a image problem when I export a report to PDF. The images
> in the report are being pulled from the database. They appear just
> fine in print preview and I can even export to a Tiff format without
> any problem. When I export to PDF, I can open the document but when it
> gets to certain images, it displays a "drawing error" message and the
> rest of the report is blank (Reader 7). I upgraded to Adobe Reader 8,
> and now I am getting the same type results, but the error message is
> "Insufficient data for Image". I have even tried using the "Web" as
> the image source and point to the actual images, but I still get the
> same results when I export to PDF.
> Any suggestions would be greatly appreciated.
> Thanks,
> Amy Bolden
This is one of the strangest problems I have ever encountered, but at
least I was able to find a solution. For some strange reason, when I
would change all the jpg image to gif, the conversion to pdf worked
just fine. Weird.
Thanks,
Amy
Image issues when Exporting to PDF
I'm using vb6 and Crystal 8.5.
I have a report that loads images from a database into OLE objects on the report ( 2 images, 2 different sections). In the format section of each section, I use the following routine to get/show the image.
Get an ID from a txt field in the header.
Feed the ID to a DLL that gets the Pic and returns it
Set oleObj.formattedpicture = pic
Works great in the report...But when I try to export to PDF. The resulting pdf will have the SAME PICTURE in every page of the report.
Help!
Thanks,Hi,
M not sure u got the answer for this question. Anyways, u need to install Crystal Reports SP3 to resolve this issue.
I have a report that loads images from a database into OLE objects on the report ( 2 images, 2 different sections). In the format section of each section, I use the following routine to get/show the image.
Get an ID from a txt field in the header.
Feed the ID to a DLL that gets the Pic and returns it
Set oleObj.formattedpicture = pic
Works great in the report...But when I try to export to PDF. The resulting pdf will have the SAME PICTURE in every page of the report.
Help!
Thanks,Hi,
M not sure u got the answer for this question. Anyways, u need to install Crystal Reports SP3 to resolve this issue.
Image in Report Header
I embeded an image in my report.When i export it to PDF and Excel,it works fine but in HTML in does not show..
Can anyone tel me why..
Thanks,
Plengski
This would be a SQL Server Reporting Services specific question, i would recommend asking it in this forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=82&SiteID=1
Thanks,
Othmane
Wednesday, March 21, 2012
Image in Report Header
I embeded an image in my report.When i export it to PDF and Excel,it works fine but in HTML in does not show..
Can anyone tel me why..
Thanks,
Plengski
This would be a SQL Server Reporting Services specific question, i would recommend asking it in this forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=82&SiteID=1
Thanks,
Othmane
Image Data - Where should it be stored
Been pondering the idea of putting 43 - 56K Pdf documents into a SQL DB but everything I've read only goes as far as to explain how the data is stored or manipulated.
I need to establish whether there are real performance issues or gains that will be experienced by doing this.
If indeed, performance would be a big issue, would storing the files in a Folder on another drive outside the Database be all that much faster (Let windows handle the fetch and carry instead of SQL Server).
The plan at the moment is to store all the image data in a separate data file or multiple data files. Using partitioned views is also a consideration.
Number of records per day (pdf's) would be somewhere around a 1000.You also need to think through the archiving requirements/possibilities. No matter where you end up storing it, no drive will be big enough aft certain period of time.
If Image field vs. physical file are your only choices, I'd go with the first one. Your documents will be safer there. Consider SQLLiteSpeed as your backup tool, so that you can still perform your backups successfully when the database size grows to a considerable number.|||My vote...
Store them on the server and store the path in the database...keep each as separate files...
MOO|||Originally posted by rdjabarov
You also need to think through the archiving requirements/possibilities. No matter where you end up storing it, no drive will be big enough aft certain period of time.
If Image field vs. physical file are your only choices, I'd go with the first one. Your documents will be safer there. Consider SQLLiteSpeed as your backup tool, so that you can still perform your backups successfully when the database size grows to a considerable number.
Agreed that doc's might be safer inside DB but the real issue is where long term performance will be the best. In or out?
Archiving or even removal of the pdf's after a set time is definitely a must and SQL Litespeed would be the only option once the DB gets bigger.
Maybe I should just put a few hundred thousand of these things into a test DB and see how it goes and then do the same with the Filesystem Option.
Thanks|||Originally posted by Brett Kaiser
My vote...
Store them on the server and store the path in the database...keep each as separate files...
MOO
We've used this approach on another project and so far there haven't been any complaints or problems. Data size for the images on that one is at around 11 Gigs.
Thanks|||Brett,
I highly respect your opinion, but have to force myself to disagree with you this time.
Having docs stored on the file system, while having their paths stored in a table(-s) not simplifies but rather complicates your application architecture. As per performance, - it will not be any different whether you have the actual document stored in the image field, or its path in a varchar/nvarchar field. In fact, in case you choose the latter, your performance WILL be worse because of the mere presence of that nvarchar field. Keep in mind, that field may have to be as big as 4000 in case with nvarchar (which will translate to the same size as varchar(8000)) because while the file name cannot exceed 128 characters, the total path may and possibly will.
Also, I don't think anybody would do any mass operation on that table that would involve the Image field, so, again, the performance will actually be better.|||I bow to your graciousness...
Now to be fair, I've played with porting images in and out, and found it to be painful (MOO to that)
Worked with a Contenet mangament app once and they stored all their images outside the db
Then there's Bills Articel
http://www.sqlteam.com/item.asp?ItemID=986
And probably many more...
EDIT:
And a more balanced opinion
http://www.aspfaqs.com/aspfaqs/ShowFAQ.asp?FAQID=172|||1000 PDF a day?!!!!! That's a fair number. Where I work, we image all the companies paper. SQL tables get large very fast, as we image several thousand pieces of paper a day. My whole point to this, if you can afford it, why not look into either a small, introductory imaging system (Kodax/kofax come to mind) or a small SAN?
Our setup consists of 5 scanning stations, 3 quality control stations and 2 release stations. Part of the business consists of scanning pages, creating pdf's and putting those pdf's on line, to be viewed over the intranet. The process is fast and easy. We keep pointers to scanned images in approx 100-125 SQL tables (Each business unit gets it's own folder. Images are stored as bin files and written to optical media on a continious basis.) We have approx 100-125 users that view documents from a web application.
Originally posted by glyve
Been pondering the idea of putting 43 - 56K Pdf documents into a SQL DB but everything I've read only goes as far as to explain how the data is stored or manipulated.
I need to establish whether there are real performance issues or gains that will be experienced by doing this.
If indeed, performance would be a big issue, would storing the files in a Folder on another drive outside the Database be all that much faster (Let windows handle the fetch and carry instead of SQL Server).
The plan at the moment is to store all the image data in a separate data file or multiple data files. Using partitioned views is also a consideration.
Number of records per day (pdf's) would be somewhere around a 1000.|||Hmm. Let's see what that recipe was...add one can gasoline...light match..
I am actually a bit split on this idea. I can afford that position, since I have not had to deal with any of these systems to a large extent.
Microsoft (in their finite wisdom) believes that files should be kept in the database. At least when it comes to Sharepoint Team Services. They claim it is easier to maintain one copy of the document, and have twnety server serve it up, than it is to have twenty webservers with the same document on it. This overlooks one small point, of course. Just how much network traffic is there on that one poor network card, if twenty servers are all clamoring for this one document? Also, Sharepoint is geared more for editing documents, so they do have a point there. Easier to maintain one copy of each living document, than try to keep a bunch of other servers up to date on even 1000 documents.
Now, are these documents of yours static? Then you can drop a pile of network traffic, because the problem of keeping a server farm up to date becomes trivial (or left as an excercise for the interested reader).
This is all fine and well, of course, if you are "swinging for the fence" (hey, baseball season starts in 47 days). If you are planning on only one web server and one DB server, you can go either way. Depending on your expected amount of traffic, scalability requirements, size of the disk on the web server, colour of your bosses toupee, etc..
I do not know of any reason why you would need (or want) to keep paths as nvarchar. Also, I have never seen a path of 4,000 characters. I assume rdjabarov has been bit bad by one of these, though. Main thing to keep in mind at the design time will probably be how in heck are you going to organize all of these documents?
One last thing to note. Microsoft put out the "TerraServer" way back in 98 or so. It was a terabyte database running on SQL 7.0. Naturally, it was all image data. I have no idea how much maintenance it required, but it was running everytime I went to see the website...at least, so they said ;-)
Opinions expressed above may not reflect those of the owners/operators of this website, or indeed anything coming close to being rational.|||I indeed may sound very pationate about the whole idea, but I not only experimented with both methods, but also had to switch from file-based to database-based mid-way through development (half of the app was already in prod) And it was done not on 2K or 7.0, but in 6.5, with VB client and RDO as a "data truck." And we too were storing images, TIFF scans of HCFA-1500 and UB-92 claims, along with all the values coming from them into corresponding tables. The volume exceeded 1000 total claims a day, but the membership was growing rapidly (rigfht up untill the company went broke, and not because of database-based image storage :))
Advantages: no need to search on image field, and no affect on performance; If your sysadmin decides to move folders around (except for data and log-related folders) you are not affected; if the whole server goes CAPUT and the only thing that is left in your hands is a last-night tape backup, - you lost NOTHING!!! Contrary to "path or URL" as suggested by one of the articles mentioned by Brett (cheers ;)), where not only you need a db backup, but also the folder(-s) backup in order to claim you're back in business.|||I feel your pain. Only database corruption I ever faced (outside of a disk controller going screwy) was in image data in SQL 6.5. Although, the fool application was attempting to use the image data as an encrypted jumble of all sorts of order information, so it was constantly updating the image data.
1000 claims per day does not sound too bad, though. For an 8 hour day, that comes out to 125 per hour...carry the one...2 per minute or so. Naturally, you would have gusts in there. Those users are never so polite as to put these things in in an orderly and uniform rate, eh? How did the application perform?|||Thanks People. Life seems a bit less obscure now.
BTW the documents will all be read only.|||It performed OK, the images were retrieved only when there was a dispute with a provider, or for case management purposes. Since the entire claim information was stored into appropriate table structure, there was never a need to even touch the original image, or do anything else with it. Purging was designed for a 2-year window back, after which the images were placed on microfilm, and the data was stored in an aggregate form of lag, MLR, Encounter summary, and other analytical reports.|||Originally posted by MCrowley
This is all fine and well, of course, if you are "swinging for the fence" (hey, baseball season starts in 47 days). .
Gotta be a sox fan....
They count the days you see......
Thank god for their football team, or the entire state would be in therapy...
:D
(Sorry Mcrowley, had to get a zinger in their)
And as far as the topic goes...I've only seen one system deliver content from a blob...and that was home grown and on Oracle (major internal differences).
Content management, Kodak imagining systems ( now weren't those platters expensive!), Self service apps, Peoplesodt (has the ability to store images)...and every implementation stored them on the server...
As to the backup question, sure it's not in the db, just another part of the nightly back up process..
Hey WHATEVER works for you...|||That is quite all right, Brett. I have had some fun at others' expense here, as well ;-).
Besides, THIS year, is THE YEAR...just like last year........and the year before that.........and uh, well, the year before that... ;-)|||Originally posted by MCrowley
That is quite all right, Brett. I have had some fun at others' expense here, as well ;-).
Besides, THIS year, is THE YEAR...just like last year........and the year before that.........and uh, well, the year before that... ;-)
LOL
Can you say A-ROD?|||Never store any image or pdf in your database just the linking name to where it is on ya server.
Simple and no hassle todo!|||...here we go again...OK, I give up. As a matter of fact the concept that I described earlier helped us pass TDI audit without a hickup, which would have occurred, and in fact did occur with other Texas plans at that time. They DID store original documents as files, and they could not prove that information there stayed intact. The only thing they could do was to see "who modified the file last?" That answer was not enough for TDI, and those plans had to acquire additional, and at that time very expensive add-ons to their OS to prevent external, non-application-initiated access to those documents.
So there you have it, do as you please ;)|||Originally posted by rdjabarov
So there you have it, do as you please ;)
It's like the Indiana Jones movie...
"Go ahead, blow up the ark...Do as you wish...."
and remeber...we are merley passing through History...but SQL server...is History...(well maybe someday)
:D
(And if Oracle has anything to say about it....)
:eek:|||LOL
Can you say A-ROD?
I can say it...I just don't want to ;-)
And the obligatory thread related answer type comment:
It depends.
Cons:
single point of failure.
concentrate network traffic on one server
potentially HUGE database
others?
Pros:
Security
Data is from a single source
No worries about synchronizing paths vs files
others?
I need to establish whether there are real performance issues or gains that will be experienced by doing this.
If indeed, performance would be a big issue, would storing the files in a Folder on another drive outside the Database be all that much faster (Let windows handle the fetch and carry instead of SQL Server).
The plan at the moment is to store all the image data in a separate data file or multiple data files. Using partitioned views is also a consideration.
Number of records per day (pdf's) would be somewhere around a 1000.You also need to think through the archiving requirements/possibilities. No matter where you end up storing it, no drive will be big enough aft certain period of time.
If Image field vs. physical file are your only choices, I'd go with the first one. Your documents will be safer there. Consider SQLLiteSpeed as your backup tool, so that you can still perform your backups successfully when the database size grows to a considerable number.|||My vote...
Store them on the server and store the path in the database...keep each as separate files...
MOO|||Originally posted by rdjabarov
You also need to think through the archiving requirements/possibilities. No matter where you end up storing it, no drive will be big enough aft certain period of time.
If Image field vs. physical file are your only choices, I'd go with the first one. Your documents will be safer there. Consider SQLLiteSpeed as your backup tool, so that you can still perform your backups successfully when the database size grows to a considerable number.
Agreed that doc's might be safer inside DB but the real issue is where long term performance will be the best. In or out?
Archiving or even removal of the pdf's after a set time is definitely a must and SQL Litespeed would be the only option once the DB gets bigger.
Maybe I should just put a few hundred thousand of these things into a test DB and see how it goes and then do the same with the Filesystem Option.
Thanks|||Originally posted by Brett Kaiser
My vote...
Store them on the server and store the path in the database...keep each as separate files...
MOO
We've used this approach on another project and so far there haven't been any complaints or problems. Data size for the images on that one is at around 11 Gigs.
Thanks|||Brett,
I highly respect your opinion, but have to force myself to disagree with you this time.
Having docs stored on the file system, while having their paths stored in a table(-s) not simplifies but rather complicates your application architecture. As per performance, - it will not be any different whether you have the actual document stored in the image field, or its path in a varchar/nvarchar field. In fact, in case you choose the latter, your performance WILL be worse because of the mere presence of that nvarchar field. Keep in mind, that field may have to be as big as 4000 in case with nvarchar (which will translate to the same size as varchar(8000)) because while the file name cannot exceed 128 characters, the total path may and possibly will.
Also, I don't think anybody would do any mass operation on that table that would involve the Image field, so, again, the performance will actually be better.|||I bow to your graciousness...
Now to be fair, I've played with porting images in and out, and found it to be painful (MOO to that)
Worked with a Contenet mangament app once and they stored all their images outside the db
Then there's Bills Articel
http://www.sqlteam.com/item.asp?ItemID=986
And probably many more...
EDIT:
And a more balanced opinion
http://www.aspfaqs.com/aspfaqs/ShowFAQ.asp?FAQID=172|||1000 PDF a day?!!!!! That's a fair number. Where I work, we image all the companies paper. SQL tables get large very fast, as we image several thousand pieces of paper a day. My whole point to this, if you can afford it, why not look into either a small, introductory imaging system (Kodax/kofax come to mind) or a small SAN?
Our setup consists of 5 scanning stations, 3 quality control stations and 2 release stations. Part of the business consists of scanning pages, creating pdf's and putting those pdf's on line, to be viewed over the intranet. The process is fast and easy. We keep pointers to scanned images in approx 100-125 SQL tables (Each business unit gets it's own folder. Images are stored as bin files and written to optical media on a continious basis.) We have approx 100-125 users that view documents from a web application.
Originally posted by glyve
Been pondering the idea of putting 43 - 56K Pdf documents into a SQL DB but everything I've read only goes as far as to explain how the data is stored or manipulated.
I need to establish whether there are real performance issues or gains that will be experienced by doing this.
If indeed, performance would be a big issue, would storing the files in a Folder on another drive outside the Database be all that much faster (Let windows handle the fetch and carry instead of SQL Server).
The plan at the moment is to store all the image data in a separate data file or multiple data files. Using partitioned views is also a consideration.
Number of records per day (pdf's) would be somewhere around a 1000.|||Hmm. Let's see what that recipe was...add one can gasoline...light match..
I am actually a bit split on this idea. I can afford that position, since I have not had to deal with any of these systems to a large extent.
Microsoft (in their finite wisdom) believes that files should be kept in the database. At least when it comes to Sharepoint Team Services. They claim it is easier to maintain one copy of the document, and have twnety server serve it up, than it is to have twenty webservers with the same document on it. This overlooks one small point, of course. Just how much network traffic is there on that one poor network card, if twenty servers are all clamoring for this one document? Also, Sharepoint is geared more for editing documents, so they do have a point there. Easier to maintain one copy of each living document, than try to keep a bunch of other servers up to date on even 1000 documents.
Now, are these documents of yours static? Then you can drop a pile of network traffic, because the problem of keeping a server farm up to date becomes trivial (or left as an excercise for the interested reader).
This is all fine and well, of course, if you are "swinging for the fence" (hey, baseball season starts in 47 days). If you are planning on only one web server and one DB server, you can go either way. Depending on your expected amount of traffic, scalability requirements, size of the disk on the web server, colour of your bosses toupee, etc..
I do not know of any reason why you would need (or want) to keep paths as nvarchar. Also, I have never seen a path of 4,000 characters. I assume rdjabarov has been bit bad by one of these, though. Main thing to keep in mind at the design time will probably be how in heck are you going to organize all of these documents?
One last thing to note. Microsoft put out the "TerraServer" way back in 98 or so. It was a terabyte database running on SQL 7.0. Naturally, it was all image data. I have no idea how much maintenance it required, but it was running everytime I went to see the website...at least, so they said ;-)
Opinions expressed above may not reflect those of the owners/operators of this website, or indeed anything coming close to being rational.|||I indeed may sound very pationate about the whole idea, but I not only experimented with both methods, but also had to switch from file-based to database-based mid-way through development (half of the app was already in prod) And it was done not on 2K or 7.0, but in 6.5, with VB client and RDO as a "data truck." And we too were storing images, TIFF scans of HCFA-1500 and UB-92 claims, along with all the values coming from them into corresponding tables. The volume exceeded 1000 total claims a day, but the membership was growing rapidly (rigfht up untill the company went broke, and not because of database-based image storage :))
Advantages: no need to search on image field, and no affect on performance; If your sysadmin decides to move folders around (except for data and log-related folders) you are not affected; if the whole server goes CAPUT and the only thing that is left in your hands is a last-night tape backup, - you lost NOTHING!!! Contrary to "path or URL" as suggested by one of the articles mentioned by Brett (cheers ;)), where not only you need a db backup, but also the folder(-s) backup in order to claim you're back in business.|||I feel your pain. Only database corruption I ever faced (outside of a disk controller going screwy) was in image data in SQL 6.5. Although, the fool application was attempting to use the image data as an encrypted jumble of all sorts of order information, so it was constantly updating the image data.
1000 claims per day does not sound too bad, though. For an 8 hour day, that comes out to 125 per hour...carry the one...2 per minute or so. Naturally, you would have gusts in there. Those users are never so polite as to put these things in in an orderly and uniform rate, eh? How did the application perform?|||Thanks People. Life seems a bit less obscure now.
BTW the documents will all be read only.|||It performed OK, the images were retrieved only when there was a dispute with a provider, or for case management purposes. Since the entire claim information was stored into appropriate table structure, there was never a need to even touch the original image, or do anything else with it. Purging was designed for a 2-year window back, after which the images were placed on microfilm, and the data was stored in an aggregate form of lag, MLR, Encounter summary, and other analytical reports.|||Originally posted by MCrowley
This is all fine and well, of course, if you are "swinging for the fence" (hey, baseball season starts in 47 days). .
Gotta be a sox fan....
They count the days you see......
Thank god for their football team, or the entire state would be in therapy...
:D
(Sorry Mcrowley, had to get a zinger in their)
And as far as the topic goes...I've only seen one system deliver content from a blob...and that was home grown and on Oracle (major internal differences).
Content management, Kodak imagining systems ( now weren't those platters expensive!), Self service apps, Peoplesodt (has the ability to store images)...and every implementation stored them on the server...
As to the backup question, sure it's not in the db, just another part of the nightly back up process..
Hey WHATEVER works for you...|||That is quite all right, Brett. I have had some fun at others' expense here, as well ;-).
Besides, THIS year, is THE YEAR...just like last year........and the year before that.........and uh, well, the year before that... ;-)|||Originally posted by MCrowley
That is quite all right, Brett. I have had some fun at others' expense here, as well ;-).
Besides, THIS year, is THE YEAR...just like last year........and the year before that.........and uh, well, the year before that... ;-)
LOL
Can you say A-ROD?|||Never store any image or pdf in your database just the linking name to where it is on ya server.
Simple and no hassle todo!|||...here we go again...OK, I give up. As a matter of fact the concept that I described earlier helped us pass TDI audit without a hickup, which would have occurred, and in fact did occur with other Texas plans at that time. They DID store original documents as files, and they could not prove that information there stayed intact. The only thing they could do was to see "who modified the file last?" That answer was not enough for TDI, and those plans had to acquire additional, and at that time very expensive add-ons to their OS to prevent external, non-application-initiated access to those documents.
So there you have it, do as you please ;)|||Originally posted by rdjabarov
So there you have it, do as you please ;)
It's like the Indiana Jones movie...
"Go ahead, blow up the ark...Do as you wish...."
and remeber...we are merley passing through History...but SQL server...is History...(well maybe someday)
:D
(And if Oracle has anything to say about it....)
:eek:|||LOL
Can you say A-ROD?
I can say it...I just don't want to ;-)
And the obligatory thread related answer type comment:
It depends.
Cons:
single point of failure.
concentrate network traffic on one server
potentially HUGE database
others?
Pros:
Security
Data is from a single source
No worries about synchronizing paths vs files
others?
Monday, March 19, 2012
image causing extra page in PDF export
HI
I have a report, on the first page I have:
Single Line of text
Single Line of text
IMage 2.04 " by 2.04 " (centered)
Single Line of Text
Single line of text
Looks fine in report viewer, but when exported to PDF, all the text lines are on the first page, and the image is on the second page by itself off center.
Any ideas?
Thanks
Bob
bump
Subscribe to:
Posts (Atom)