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.

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?

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?

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.