Lazarus

Programming => Databases => Topic started by: egsuh on July 10, 2020, 11:48:17 pm

Title: TIBConnection.KeepConnection
Post by: egsuh on July 10, 2020, 11:48:17 pm
What is the role of this property?
Documents say that
Quote
Determines whether to keep the connection open once it is established and the first query has been executed.

Does this mean that the connection is closed once the first query has been executed if set false?
Title: Re: TIBConnection.KeepConnection
Post by: devEric69 on July 15, 2020, 02:35:29 pm
The property KeepConnection says whether the connection should be closed, or maintained even when no data set is active. So, theoretically:
- to false, the database connection is closed as soon as all its datasets are closed, executed.
- to true, the client's side of the connection is said to be "alive", "constant" or "persistent" with the database.

Above all, KeepConnection is especially useful if the application is on another machine, i.e. another server, depending on the accuracy, of the coded SQL queries.

• KeepConnection should be set to true, for applications that frequently open and close all datasets (applications that use queries with filters at best): this has the effect of reducing the network traffic of connection and disconnection prologues, also called database attachments and detachments.

• KeepConnection should be set to false, for applications that work a lot with filtering on the application side (typically, a TfpTable component with its Filtered property set to true, asks for all the data present in the SQL table, and then that data is filtered on the client application). KeepConnection should be set to false with applications which are designed with the "briefcase" development model (to take an example that everyone knows, it's a little bit similar with a GitHub repository management's model, from a replication point of view), using cached updating (Cf. the property CachedUpdates first at all, then ApplyUpdates, then "resolving strategies" a.k.a. replication\updates strategies of a same record that is different on the server and on a client, etc.).

Obviously, if a higher imperative dictates that the connection must be destroyed, for example due to a function's call which is requesting for the destruction of the current T{Web}Module containing the T{fp|IB}Connexion, T{fp|IB}Connexion.KeepConnection has no effect: the Free notification's mecanism obligates to close the database's connection.
Its implementation depends on the API of each type of client library: regular API-mysql_ping calls, in a loop with timout for MySQL\MarisDB, etc.

TinyPortal © 2005-2018