Print button generates hugh spooled print files

Hi!
We are currently using a different third party tool to print out pdf-files
generated from SQL Server 2000 Reporting Services. We are a fairly large
international cooperation and have a centralized citrix it environment with
different band width to different places in the world. This makes the print
file size critical.
Because there havenâ't been any really good ways to print out reports before
sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
our test enviromnet and we are pretty disappointed.
It seems like the reports are converted to tiff-format and then printed and
the print file size is huge. We tested to print out a report with six pages
(A4-format) with different techniques and this is the result when it comes to
spooled print file sizes:
1. Using RS print button (14.1 MB)
2. Exporting to TIFF-format from RS and than print (14 MB)
3. Exporting to PDF-format and print with gsprint (ghostscript) using a
windows generic print driver (1.43 MB)
4. Exporting to PDF-format and print with gsprint (ghostscript) using a
print driver specialized for the current printer, hp laserjet (852 KB)
5. Exporting to PDF-format and print with acrobat reader (531 KB)
I have a couple of questions regarding this:
1. Is this right? Is the report converted to TIFF-format when pressing the
print button and is it right that the spooled print file should be this large
and in that case why is it done in this way?
2. Is there any work around for this? Is there any way to get a smaller file?
3. Is this the way it will be implemented in SQL Server 2005 as well?
Regards,
/MattiasHi Mattias,
I also noticed the problem and posted a while back but not got a reply yet
(we too also use Citrix and need to address the bandwidth issue!).
--
Ben
"MattiasT" wrote:
> Hi!
> We are currently using a different third party tool to print out pdf-files
> generated from SQL Server 2000 Reporting Services. We are a fairly large
> international cooperation and have a centralized citrix it environment with
> different band width to different places in the world. This makes the print
> file size critical.
> Because there havenâ't been any really good ways to print out reports before
> sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
> our test enviromnet and we are pretty disappointed.
> It seems like the reports are converted to tiff-format and then printed and
> the print file size is huge. We tested to print out a report with six pages
> (A4-format) with different techniques and this is the result when it comes to
> spooled print file sizes:
> 1. Using RS print button (14.1 MB)
> 2. Exporting to TIFF-format from RS and than print (14 MB)
> 3. Exporting to PDF-format and print with gsprint (ghostscript) using a
> windows generic print driver (1.43 MB)
> 4. Exporting to PDF-format and print with gsprint (ghostscript) using a
> print driver specialized for the current printer, hp laserjet (852 KB)
> 5. Exporting to PDF-format and print with acrobat reader (531 KB)
> I have a couple of questions regarding this:
> 1. Is this right? Is the report converted to TIFF-format when pressing the
> print button and is it right that the spooled print file should be this large
> and in that case why is it done in this way?
> 2. Is there any work around for this? Is there any way to get a smaller file?
> 3. Is this the way it will be implemented in SQL Server 2005 as well?
> Regards,
> /Mattias

Print button generates hugh print files

I have posted this before with no luck so I try again and hope for an answer.
Hi!
We are currently using a different third party tool to print out pdf-files
generated from SQL Server 2000 Reporting Services. We are a fairly large
international cooperation and have a centralized citrix it environment with
different band width to different places in the world. This makes the print
file size critical.
Because there havenâ't been any really good ways to print out reports before
sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
our test enviromnet and we are pretty disappointed.
It seems like the reports are converted to tiff-format and then printed and
the print file size is huge. We tested to print out a report with six pages
(A4-format) with different techniques and this is the result when it comes to
spooled print file sizes:
1. Using RS print button (14.1 MB)
2. Exporting to TIFF-format from RS and than print (14 MB)
3. Exporting to PDF-format and print with gsprint (ghostscript) using a
windows generic print driver (1.43 MB)
4. Exporting to PDF-format and print with gsprint (ghostscript) using a
print driver specialized for the current printer, hp laserjet (852 KB)
5. Exporting to PDF-format and print with acrobat reader (531 KB)
I have a couple of questions regarding this:
1. Is this right? Is the report converted to TIFF-format when pressing the
print button and is it right that the spooled print file should be this large
and in that case why is it done in this way?
2. Is there any work around for this? Is there any way to get a smaller file?
3. Is this the way it will be implemented in SQL Server 2005 as well?
Regards,
/MattiasReports are definitely not output to TIFF format. They are rendered to GDI
(which is a vector format) to send to the printer. I'm not sure what is
behind the size explosion. I will investigate on our side.
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"MattiasT" <MattiasT@.discussions.microsoft.com> wrote in message
news:DA2CF65D-D76A-4867-AFED-5A22AB356967@.microsoft.com...
>I have posted this before with no luck so I try again and hope for an
>answer.
> Hi!
> We are currently using a different third party tool to print out pdf-files
> generated from SQL Server 2000 Reporting Services. We are a fairly large
> international cooperation and have a centralized citrix it environment
> with
> different band width to different places in the world. This makes the
> print
> file size critical.
> Because there haven't been any really good ways to print out reports
> before
> sp2 we have hoped a lot of the sp2 print functionality. Now it's installed
> in
> our test enviromnet and we are pretty disappointed.
> It seems like the reports are converted to tiff-format and then printed
> and
> the print file size is huge. We tested to print out a report with six
> pages
> (A4-format) with different techniques and this is the result when it comes
> to
> spooled print file sizes:
> 1. Using RS print button (14.1 MB)
> 2. Exporting to TIFF-format from RS and than print (14 MB)
> 3. Exporting to PDF-format and print with gsprint (ghostscript) using a
> windows generic print driver (1.43 MB)
> 4. Exporting to PDF-format and print with gsprint (ghostscript) using a
> print driver specialized for the current printer, hp laserjet (852 KB)
> 5. Exporting to PDF-format and print with acrobat reader (531 KB)
> I have a couple of questions regarding this:
> 1. Is this right? Is the report converted to TIFF-format when pressing the
> print button and is it right that the spooled print file should be this
> large
> and in that case why is it done in this way?
> 2. Is there any work around for this? Is there any way to get a smaller
> file?
> 3. Is this the way it will be implemented in SQL Server 2005 as well?
> Regards,
> /Mattias
>

Primary Key Analysis Tool

I have a client database where the users are experiencing very unpredictable behavior and I found after investigating that the majority of the tables don't have primary keys. :o

They were imported from an Access database and I think the table creator or the Access wizard itself added auto-number fields, so I know most of the tables have at least one column that could become the primary key.

Is there a free tool available that will allow me to analyze these tables to identify and list the tables that need primary keys and also help identify candidate columns for the primary key?

It would be helpful if I could automate some of the script generation to install the primary keys so I don't have to do them all manually.you should be able to work out a query using the information schema views.|||Is it a full moon toay?

Script out the database and look it over

Or do as Sean said and left join tables key_column_usage|||Is it a full moon toay?

Script out the database and look it over

Or do as Sean said and left join tables key_column_usage
No, sorry the moon was full on the 26th.

The reason I asked about a tool to help with this is I don't have time or patience to script and analyze about 500 tables. The key_column_usage view isn't helpful since none of the user tables have keys - there are only two entries for the master table keys.|||This script is beta, but it works pretty well. Supply a tablename and it will find all the natural keys in the data.|||I didn't open the blind dudes script, but I guess it's looking for cardiality of the data.

The more unique it is would be the key

But you could write your own

So lets' you find a column that all has unique values, I would use that as a key

But what if you have columns with 2 or 3 values?

Or mostly unique?

Was that app written to suppose to enforce RI

A lot of 3rd party apps I see do that

scrubs|||This script is beta, but it works pretty well. Supply a tablename and it will find all the natural keys in the data.
Exactly what I needed. :beer: