I've been saying this for years ever since they integrated the SAP print engine.  Print speeds are our biggest complaint about Sage.  

I have a couple clients on 2023 with the same issue. The common denominator seems to be certain types of environments. Seems to be RDP's on VM's mostly.

Hi DeniseB and Mike Cook sorry to hear about this, I look after a number of Sage 300 RDS sites, some quite large, and have experienced and resolved this issue.  Its normally a problem with the "Follow Me Print" or "RDS Redirect" print driver, or a very bandwidth intensive print driver like PostScript.  Remember when using RDS's redirection options the job has to be spooled to the local machine in a generic format, converted, then printed seperately on the local print driver which is really inefficient.  To solve the slow print issue I would recommend trying the following:

1. Install local copies of printer drivers onto the RDS server itself, ensuring the RDS server can print directly to said printers in the office.  Then ensure the default printer set for users is the actual office printer they use installed directly on the RDS and NOT a redirected or "follow me" printer.  You can disable printer redirection on your published RemoteApp session collection or if using traditional desktop login to launch Sage, on the RDP connection icon users access.
2. If users are accessing Sage from non-domain joined computers at home or in branch offices where there is no WAN/LAN connection then you will need to continue using Printer Redirection.  In this case, encourage users to set an efficient local default driver for their printers like PCL6 instead of PostScript to significantly reduce bandwidth needs.  Particularly invoices with graphics are going to sending hundreds of megabytes per page through inefficient redirection.
3. Non-commercial printer drivers are problematic.  In recent years, due to high speed USB a lot of home/home office printers have very lazy generic drivers that when printing graphics just push gigabytes of bitmapped raster data down the USB cable to the printer with no on-board printer RAM - everything is soft managed on the computer itself.  This would have crashed PC's 20 years ago but is no issue now.  When using these printers over redirection and graphics are involved the network consequences, especially for users on Wifi or internet connections and not gigabit+ LAN can be horrific.  In this case try to see if the default printer these users have can be switched to a network friendly print driver.
4. Print spooler bugs - particularly when using older versions of Office there is a horrible bug with the virtual OneNote printer where when a user on the RDS accidentally has OneNote printer as their default printer and they send a job to it, the print spooler starts bleeding memory and CPU slowing everything down.  Try to remove any installed or redirected OneNote printers and ensure all users have their correct printers set as the default printer.
5. Avoid using the option to "Allow Windows to Manage my default printer" - always ensure users hard-set their correct printer on their RDS windows profile.

I know this advice is pretty random but I've encountered these issues in the wild so I hope one of these helps.  Let me know how you go and if we need to think of additional ideas if the above doesn't help.  Tim.

Would this affect Sage print preview as well? That's where I'm seeing the slowdown.

That is where I am seeing the slowdown as well. It seems to take a few seconds after I hit the Print Button in a report, then when the little spinner stops after a few seconds, it takes at least 17-20 seconds to render it to Preview. When you actually send it from the preview to the printer it is fast.

for us, it's been the actually spooling of the print preview not the actual time to send to a printer. We eliminated any sort of data constraints in the actual print as possible.  Plus it's the number of clicks and "ok" buttons to hit to print.  It is what it is.  It WAS much quicker before the SAP engine was integrated.

yea, that's where the slow down is, not the physical print.  it's the time it take to generate the preview.  Other people will just that it's you .rpt file and it's sub reports and it's your fault... but it's wrong.   You will also be told that it's not that big of a deal but when you processes hundreds of orders per day across multiple branches... it becomes a problem

But what I can't figure out is why the same report in SAMLTD prints fast while in a Live DB it takes so much time. There must be something I am missing here. Would there be anything in the SQL DB that needs to be tweaked?

Yes, this greatly affects the Print Preview as the Crystal Reporting engine uses the actual print driver to render the Print Preview.  This is why running the same report using different default printers can produce different results such as margin sizes and even slightly different fonts depending on the driver.  Also, you might notice when you render a print preview using a PDF virtual printer it might come out perfect but when using a print driver you see lines slightly out but then when you go ahead and convert it to PDF it turns out fine anyway.  It can be a little frustrating.  I think Crystal does this to ensure WYSIWYG if you actually print to paper.

This reminds me - one thing you can try if not physically printing to paper is to simply install (if not already present) a local Print to PDF driver like Microsoft Print to PDF or CutePDF Writer onto the RDS server and use GP to set it as the default printer for all your users.  The speed difference is usually significant.

Finally, some reports are slow to preview if there is a lot of data and the data isn't well indexed in SQL.  Always ensure you're doing regular SQL index maintenance, I recommend the classic Ola Hallengren maintenance plan you can find here (provides a simple .SQL file).  Also use datapipe reports instead of table reports where possible if you think its a data volume issue.

Very possible, had this issue many times too - I just answered this in another comment.  Once your data indexes are fixed you might be surprised at the performance improvement.

I totally sympathize with you and won't blame the .rpt file.  The secret here is to try and find and customize a datapipe version of the same report suitable for your needs.  This guide explains the difference (although with your experience you're likely already aware) https://cdn.na.sage.com/docs/en/customer/300erp/2023/open/Sage300_CustomizingPrintedForms.pdf.  If you check the manual for your module i.e. User Guides -> Accounts Payable from https://cdn.na.sage.com/docs/en/customer/300erp/Documentation.htm you will be able to locate in the PDF a list of available reports - ODBC and Datapipe versions to help you select a more efficient template.  Datapipe reports are harder to customise but you can still do a lot of them.  The Sage300_CustomizingPrintedForms.pdf above will help and the performance improvement will be staggering.

I'm well ahead of you on that.  We made internal custom apps, I've made hundreds of custom reports and alerts, use IMAN and custom SQL scripts for processes.  I've be brought in to talk to our local Sage development team to educate their people on things that we do.  But at the end of the day, I can't control the time it takes to generate a print preview.   I've been doing this for almost 20 years now, so I'm pretty well versed in the how it all works.  I'm just not the server/hardware guy.

In summary, it won't be a simple fix but I think if you cover the three major bases you can get the performance of these reports greatly improved:

1. Ensure your databases are optimized and indexed regularly - fix those fragmented indexes.  This will cut down the time it takes for Crystal to get the data to collate.
2. Switch to Datapipe instead of ODBC reports where possible - this will greatly reduce the data sorting and collation time once Crystal receives the data.
3. Avoid redirected and follow-me print drivers from generating the print previews - especially for reports with hundreds of pages as the text might be flowing to the driver as hundreds of pages of bitmapped graphic instead of text, even though its just text.  This will cut down on the preview generation time once Crystal has collated and sorted the data.

Good luck!

I apologize Mike Cook being an open free-forum I don't know the clients here and their backgrounds.  It sounds like you know more about this than me!  I'm not sure how to help you from here, I really wish I could.   It sounds like you've done everything I do.  If you don't need report previews you could try running reports directly to file to analyze the data there, or avoid Crystal altogether and use an alternate Intelligence tool from the Sage family or PowerBI to generate the reports you need.  I know this is all great time and expense - just a thought.  Again, sorry I can't help.

all good, no apologies needed.  You have mentioned some good points so me and my IT guy that does the hardware/server side of things are going to try a few things.  Even if I have to create a custom print spec for my counter sales team that is hardwired to their printer.  At least that would help service customers quicker.  Your points are not a waste!

If you have any wins you would be happy to share back here I'm always grateful for any tips I can add to my troubleshooting notes.

After trying several things, in the end the fix was a DB Dump/Load. 

Hi DeniseB this makes sense, doing a dump/load will fix MANY indexing and performance issues without having to do any maintenance on the data.  Its always temping to migrate data to a new server doing SQL BAK and load to save time, but unfortunately it breaks all the indexes and leaves the data in a poorly performing state.  You won't notice this with small data sets so this must be a decent sized database!  Great work!