Hi Everyone;

   FWIW: I solved this issue a long time ago in my STD Framework for Appeon Mobile, Appeon Web (<= PS2022 releases)  and Client/ Server based Apps as well that all had these timeout challenges. This framework feature now also extends into the new 2021/2022 PowerClient and PowerSever "Cloud" based Apps as well. The feature that I put in place was similar to the old Distributed PB, Jaguar and EAServer feature which was known as a "heartbeat". The HB feature monitors your App's DML activity and if there is none, it "pings" the DBMS server. In the case of any PowerServer version that implements an N-Tier model, the Ping" is over to the middle tier (via a JSON request) that in turn causes DML activity between the PowerServer Web API middle tier and the target DBMS - thus negating both the IIS Session timeout, Application Pool timeout and DBMS timeout settings.  :-)

   The problem with the solutions that have been proposed in this thread  thus far is that they change the web server, DB driver and/or DBMS server timeout settings. This *might* be great for the problem App (or two) but may then cause transaction handling issues for other Apps. Not to also mention middle tier and / or DBMS problems depending on the processing needs of the other various PB App's requirements.

   The Hearbeat feature is implemented in my framework on the SQLCA ancestor and thus all transaction objects can have this feature active. You can enable, disable the HB feature or change the HB frequency for any App via its INI file. Thus, the HB needs for each App can be fine tuned to meet each individual App's transaction timeout requirements without affecting the N-tier ecosystem in general.

    The only trick to this implementation was making sure that the HB feature did not fire while any DBMS activity was in progress (ie: Active transactions in play). In that case, the HB feature does nothing and just goes back to sleep waiting for the next HB check.

     FYI: You can see the HB feature being used in the STD Framework's OrderEntry Demo App. The actual implementation is done via the "NS_SQLCA_Master" ancestor object located  in the STD_FC_BASE.pbl library.  http://chrispollach.blogspot.com/2023/03/framework.html

Food for thought ... HTH!

Regards ... Chris

What driver are you using? You might have better luck with a different driver.
If all else fails, try connecting with ODBC just to see if the timeout is occurring on the database side or on the client side.

Hi Tim,

Have you checked the Timeout settings for your project?
Please see here.

Regards,
Francisco

I have not enabled "Allow dynamic ..." . Users connect to the database using Windows Authentication.
I have selected Windows Authentication (Serer Credentials) and then that option becomes disabled.

Hi Tim;

  In the PS project for the SS connectivity Cache's "Advanced" settings, did you set the Connect Timeout and optionally, Connect Retry Count and/or any other relevant parameter to ensure that the PS => DBMS connection remains up at all times as per your App's Transaction Processing needs?

Regards ... Chris

Did you enable the dynamic login so that each user is having their own connection to the SQL Server database using their own username/password?  

The application uses both but for this test it is using a data window.  It is using SetTransObject.  I would say that within the 2 minute mark is when the connection fails.

LongConnection should not be needed

"when I run a query" - are you using datawindow/store or embedded sql ?  are you using settrans or settransobject?

"after a certain amount of time"   be specific (1 minute, .5 hour, 1 hour, ...)_

is it AFTER the timeout setting?