pdf size due to images

We have a report with a number of external images. When the report is run
and exported to pdf, the resulting document is over 2mb (regardless of
whether the report is run in VS or the ReportManager). When the images are
changed from external to embedded, the resulting pdf document is around
500kb. This is great since the 2mb was causing issues with our client's
email server. When the modified rdl is imported to our client's system, the
resulting document is still around 500kb.
When the original rdl is modified on the client's system using
ReportDesigner - and all of the images are changed from external to embedded
- the resulting pdf document is still over 2mb!! I've verified any number
of times that the images are of type embedded.
Both systems are have reporting services at sp1. The only obvious
difference is that our environment is a developer edition of SQL Server and
the client's is Standard.
Is the difference in SQL the reason? Any other ideas/suggestions'
ThanksThis is NOT an issue between external vs. embedded images. During testing
the wrong image file was being used.
It DOES appear to be an issue with the way images are rendered to PDF.
Using other document types such as Word results in a smaller overall document
size.
Any suggestions/ideas for rendering to pdf are appreciated.
"PD" wrote:
> We have a report with a number of external images. When the report is run
> and exported to pdf, the resulting document is over 2mb (regardless of
> whether the report is run in VS or the ReportManager). When the images are
> changed from external to embedded, the resulting pdf document is around
> 500kb. This is great since the 2mb was causing issues with our client's
> email server. When the modified rdl is imported to our client's system, the
> resulting document is still around 500kb.
> When the original rdl is modified on the client's system using
> ReportDesigner - and all of the images are changed from external to embedded
> - the resulting pdf document is still over 2mb!! I've verified any number
> of times that the images are of type embedded.
> Both systems are have reporting services at sp1. The only obvious
> difference is that our environment is a developer edition of SQL Server and
> the client's is Standard.
> Is the difference in SQL the reason? Any other ideas/suggestions'
> Thanks|||The issue was resolved by: (1) upgrading to SP2 AND (2) reducing the size of
jpg images that are used in the report. ONLY upgrading to SP2 DID NOT solve
the problem - the original images were simply distorted/gray AND without a
reduction in overall pdf document size. The size of the images were reduced
using MS Photo Editor, although other editors seem to work also.
"PD" wrote:
> This is NOT an issue between external vs. embedded images. During testing
> the wrong image file was being used.
> It DOES appear to be an issue with the way images are rendered to PDF.
> Using other document types such as Word results in a smaller overall document
> size.
> Any suggestions/ideas for rendering to pdf are appreciated.
>
> "PD" wrote:
> > We have a report with a number of external images. When the report is run
> > and exported to pdf, the resulting document is over 2mb (regardless of
> > whether the report is run in VS or the ReportManager). When the images are
> > changed from external to embedded, the resulting pdf document is around
> > 500kb. This is great since the 2mb was causing issues with our client's
> > email server. When the modified rdl is imported to our client's system, the
> > resulting document is still around 500kb.
> >
> > When the original rdl is modified on the client's system using
> > ReportDesigner - and all of the images are changed from external to embedded
> > - the resulting pdf document is still over 2mb!! I've verified any number
> > of times that the images are of type embedded.
> >
> > Both systems are have reporting services at sp1. The only obvious
> > difference is that our environment is a developer edition of SQL Server and
> > the client's is Standard.
> >
> > Is the difference in SQL the reason? Any other ideas/suggestions'
> > Thanks

Pausing Replication

Several times over the course of a month, our network admin team performs
necessary maintenance due to company moves and general growth. During this
time the connection between my Publisher and Distributor is disconnected. My
Subscriber and Distributor are on the same server. I have three
transactional publications set up and I would like to Pause them until the
connection is restored since I know when the connection is going down.
Is this the correct way to handle this?
From the Distributor in the enterprise manager drill down through the
replication monitor to the Distibution Agents and click on Stop Agent for
all of the publication that I have. Do I also have to Stop Agent on all of
the publications in the Log Reader Agents folder?
This also brings up the question of unplanned connection loss. If for some
reason the connection is lost late at night and I dont know about it until
the next morning do I have to recreate snapshots or re-initialize the
publication?
I would stop SQL Server agent, disable the jobs in the management folder and
then restart the agents. You should only have to stop the distributor or
merge agents.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Paul Butler via droptable.com" <forum@.nospam.droptable.com> wrote in
message news:4FFDFDD1EDC20@.droptable.com...
> Several times over the course of a month, our network admin team performs
> necessary maintenance due to company moves and general growth. During
> this
> time the connection between my Publisher and Distributor is disconnected.
> My
> Subscriber and Distributor are on the same server. I have three
> transactional publications set up and I would like to "Pause" them until
> the
> connection is restored since I know when the connection is going down.
> Is this the correct way to handle this?
> From the Distributor in the enterprise manager drill down through the
> replication monitor to the Distibution Agents and click on "Stop Agent"
> for
> all of the publication that I have. Do I also have to "Stop Agent" on all
> of
> the publications in the Log Reader Agents folder?
> This also brings up the question of "unplanned" connection loss. If for
> some
> reason the connection is lost late at night and I don't know about it
> until
> the next morning do I have to recreate snapshots or re-initialize the
> publication?
|||Does it matter what order I do this in?
|||no, you can disable the jobs first, which will mean that if they are
scheduled they won't run the next time they are scheduled. However if they
are in continuous mode, you must stop them before or after disabling them.
Then you should bounce SQL Server agent.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Paul Butler via droptable.com" <forum@.droptable.com> wrote in message
news:4FFEBB746E630@.droptable.com...
> Does it matter what order I do this in?

Pausing Log Shipping Plans

We are doing an IP Restructuring on our DR site over the weekend due to some business and management requirements.I actually have 2 questions. I have implemented log shipping plans for our databases. Which means I will have to pause (disable) my log shipping plans while this is being done and resume (re-enable) after everything is comlete.

Any insights on what else I need to do apart from these?

My second question is this. I am generating transaction log backups every 15 minutes and is averaging at 350MB (this much data every 15 minutes - not to mention that I've got around 40+ databases, all configured for log shipping just for this instance alone). My alert threshold is 45 minutes. My log shipping plan for one database starts failing probably because 15 minutes is not enough to transfer 300+MB-sized backup file over a WAN locate across the globe on a not-so-high bandwidth and restore it to the destination. Any recommendations on this apart from increasing the threshold? Your assistance is highly appreciated

Log shipping should not be affected by changing the IP addresses unless you change ones targetted directly by the log shipping jobs. For the WAN case, you can consider adding a step to compress the transaction log backups prior to copying them over the network. This typically improves the end-toend throughput over a WAN.

Regards,

Matt Hollingsworth

Sr. Program Manager

SQL Server High Availability

|||

Hi Matt,

Thanks for your reply. Actually, we will be changing the IPs of the destination servers You were mentioning compressing the transaction log backups prior to copying them over the network. I am using the Database maintenance plans to define my log shipping plans. The way I see it, the copy job does a "pull" method - the destination server is the one initiating the job. How do you insert a step to compress the transaction log backup files in the database maintenance plans? I am only allowed to use "Microsoft supported" procedures as per company policy

sql