Sage 100

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245
------------------------------

Got these results from the customer:


------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5
------------------------------

Original Message:
Sent: 01-21-2020 11:40
From: Bob Sosbee
Subject: Slow 1st link to Sage Premium (SQL)

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245
------------------------------

Any developer programming on the system ?

------------------------------
Jeff Fiddelman
Exeplex, LLC
------------------------------

Original Message:
Sent: 01-22-2020 07:08
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Got these results from the customer:

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5
------------------------------


Original Message:
Sent: 01-21-2020 11:40
From: Bob Sosbee
Subject: Slow 1st link to Sage Premium (SQL)

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245

Website Pipeline, a DSD extended solution, and some custom stuff Lee has done.  All were in place in the 2016 advanced version without these issues.

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5
------------------------------

Original Message:
Sent: 01-22-2020 07:13
From: Jeff Fiddelman
Subject: Slow 1st link to Sage Premium (SQL)

Any developer programming on the system ?

------------------------------
Jeff Fiddelman
Exeplex, LLC
------------------------------


Original Message:
Sent: 01-22-2020 07:08
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Got these results from the customer:

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5


Original Message:
Sent: 01-21-2020 11:40
From: Bob Sosbee
Subject: Slow 1st link to Sage Premium (SQL)

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245

I have a client with Premium 2019 that is providing the same feedback, that it is running slow.  IT installed everything and is now looking at us to figure it out.  In this case they have separated their SQL instance onto one server, and the application server onto another one.  We've done some troubleshooting with firewalls, antivirus settings but aren't seeing much in performance gains.  The domain server authentication mentioned is interesting and I'm going to take a look at that.

So tagging myself into this conversation and if I find something I'll pass it along.

------------------------------
Chris Mengerink
Director
DWD Technology Group
Fort Wayne IN
260-399-8653
------------------------------

Original Message:
Sent: 01-22-2020 08:48
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Website Pipeline, a DSD extended solution, and some custom stuff Lee has done.  All were in place in the 2016 advanced version without these issues.

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5
------------------------------


Original Message:
Sent: 01-22-2020 07:13
From: Jeff Fiddelman
Subject: Slow 1st link to Sage Premium (SQL)

Any developer programming on the system ?

------------------------------
Jeff Fiddelman
Exeplex, LLC


Original Message:
Sent: 01-22-2020 07:08
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Got these results from the customer:

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5


Original Message:
Sent: 01-21-2020 11:40
From: Bob Sosbee
Subject: Slow 1st link to Sage Premium (SQL)

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245

We have opened case 8007950896 with Sage.  If you have a case please mention that so they can't tell each of us we're the "only one with this problem".

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5
------------------------------

Original Message:
Sent: 01-22-2020 10:37
From: Chris Mengerink
Subject: Slow 1st link to Sage Premium (SQL)

I have a client with Premium 2019 that is providing the same feedback, that it is running slow.  IT installed everything and is now looking at us to figure it out.  In this case they have separated their SQL instance onto one server, and the application server onto another one.  We've done some troubleshooting with firewalls, antivirus settings but aren't seeing much in performance gains.  The domain server authentication mentioned is interesting and I'm going to take a look at that.

So tagging myself into this conversation and if I find something I'll pass it along.

------------------------------
Chris Mengerink
Director
DWD Technology Group
Fort Wayne IN
260-399-8653
------------------------------


Original Message:
Sent: 01-22-2020 08:48
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Website Pipeline, a DSD extended solution, and some custom stuff Lee has done.  All were in place in the 2016 advanced version without these issues.

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5


Original Message:
Sent: 01-22-2020 07:13
From: Jeff Fiddelman
Subject: Slow 1st link to Sage Premium (SQL)

Any developer programming on the system ?

------------------------------
Jeff Fiddelman
Exeplex, LLC


Original Message:
Sent: 01-22-2020 07:08
From: Phil McIntosh
Subject: Slow 1st link to Sage Premium (SQL)

Got these results from the customer:

------------------------------
Phil McIntosh
President
Friendly Systems, Inc.
Asheville NC
678.273.4010 ext 5


Original Message:
Sent: 01-21-2020 11:40
From: Bob Sosbee
Subject: Slow 1st link to Sage Premium (SQL)

I was talking about the reason to use mapped drives as it cached the security information in the mapping and sped up access when opening new channels.  You may have a related issue in that the login to SQL is controlled by the domain server authentication and rights.  Your domain server may be overloading with the calls for access to the SQL server.  Sage gets around a lot of this by using fixed user accounts, but every time you open a channel (and Sage opens a LOT of them), it will hit the domain server for authentication.  It is supposed to cache access, but that caching is by workstation...and in the new MS security regimen may be dropped after about 300 seconds.

The second issue that I've seen on slow SQL access is a shortage of resources on the SQL server, that ironically is cause by SQL itself.  SQL by default will take over every core and all of the memory it can get, starving the other processes in the SQL server.  I typically force SQL to leave at least one core free and a certain minimum amount of memory for non SQL processes, such as authentication.

------------------------------
Bob Sosbee
Senior Developer
Accounting Systems, Inc. (ASI)
Covina CA
803-252-6154 x245