Sage 100

 View Only
  • 1.  How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 13:48
    How was WAN printing managed prior to C/S ODBC? I have a client that printing was fine prior to the upgrade. The client still accesses through the same terminal server. Sage was moved to a new Virtual Instance in the same group of servers. They upgraded from 4.3 to 2017. Speed seems fine other than printing. I have asked to have the antivirus exclude the network drive. Waiting on that. Other suggestions?


  • 2.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 13:52
    Hi Larry - if they went from 4.3 to 2017, then the version of crystal changed and I think that is the performance issue....


  • 3.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 14:04
    That's the same thing we see over and over again - slow performance when printing. The last Advanced upgrade I did, I ran into issues setting up the C/S ODBC driver. When I talked with Sage support, they asked why I was even bothering. They said it really makes no difference.


  • 4.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 14:06
    It is horribly slow. It went onto a new server instance which usually helps. I have checked the resources. The numbers are low but performance does not seem to be maxed. Bother server and terminal server are in the same LAN so I should not need the C/S ODBC. I just don't get why it should be SOO much slower.


  • 5.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 14:11
    If you can print from the Sage server without issues, then it is absolutely network speed.


  • 6.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 18:04
    Two virtual servers. Connected to the same switch. Printing from the server is 7 seconds. Printing from terminal server 40 seconds. Client accessing terminal server is on the other side of the continent.


  • 7.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 18:10
    WAN printing prior to C/S ODBC was using Crystal Web Printing. So the Print Job ran on the server and the client saw a webpage with the crystal report showing. This ran fast and work great once setup. I think it evolved over time and Sage went the path of CS ODBC which was easier to setup with the results being identical if you were using it or not. Crystal runtime is now using .net which changed a few things with Fonts and such. Speed is usually not effected by the .net though. If they are all on the same network for the TS and Application server then why not run it non CS? I usually only run CS if the client and the application is over VPN or some Bridge connection. Exceptions may be with those sites with large file size which could benefit from filtering the data before it gets sent to the client. CS does run over a port so any firewall could be delaying it if it is inspecting it. That could be the case on the client or the server or any firewall in between.


  • 8.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-11-2017 18:12
    As far as previewing the print job the client accessing the TS from the other side of the continent doesn't really matter unless they are getting a screen refresh delay. Sending the print job through the connection to print to a local printer could take that long or longer since it is transferring a print job to the local machine over a great distance.


  • 9.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 04-12-2017 06:36
    Try installing a print object on the terminal server and having the client use that (instead of shared printers through the terminal connection). If that solves it, you know the problem is related to the print spooler, not Sage.


  • 10.  RE: How was WAN printing managed prior to C/S ODBC? I

    Posted 06-14-2017 16:52
    Went back and addressed this speed issue again. I have setup direct printer and just using paperless to try to bypass the issue. It still continues to be a VERY painful lag for the client.