Select Statement READ_WRITE

[MVF_MVF]

Hi, i checked firebird log (audit ativated),

Start
2021-08-24T16:35:52.9980 (4068:00E76310) PREPARE_STATEMENT
C:\PRGSGW\DATABASE\FEELFREE.FDB (ATT_7049, SYSDBA:NONE, UTF8, XNET:)
C:\PrgSGw\Server\MVF_ServerVCL\Win32\Debug\MVF_ServerVCL.exe:1324
(TRA_1975033, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 419:

SELECT A.Id AS A_Id, A.Description AS A_Description, A.DiscountPerc AS A_DiscountPerc, A.RecVersion AS A_RecVersion
FROM Discoun A
ORDER BY A.Description Asc
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN SORT (A NATURAL)
9 ms
End

Even for select Statement "READ_WRITE" is set, should be "READ_ONLY".
I set "FFDConnection.TxOptions.ReadOnly := True"
or
"FFDTransaction := TFDTransaction.Create(Self);"
"FFDTransaction.Options.ReadOnly := True;"

But if after a select Statement, i need to saveupdate some entity, i have to create another Manager with different sets,
"FFDConnection.TxOptions.ReadOnly := False" ?

I noticed to, that:
FFDConnection.Transaction := FFDTransaction;
FFDConnection.UpdateTransaction := FFDTransactionUpdate; //Aurelius implement this? like TFDQuery for update and insert?

Sorry, it's a very confused topic, but Server Administrator, said that the application cause a lot of load on disk and writes
even in operations that it's not supposed to like select statements

Thanks

[Farias_Anderson (Anderson Farias)]

Hi,

Short READ_WRITE transactions for SELECTS are NOT a big deal in Firebird. Not much different from READ ONLY.

And for this small piece of trace log you showed, it's not possible to see the source for "lot of load and writes". The problem may be elsewhere, not READ_WRITE transactions (except if the thansactions are kept active after the select statment execution -- no commit)

Regards,

[MVF_MVF]

Hi,
Send you, a screenshot from the server, as you can see Writes are always very High(Escrita) compared with Reads(Leitura) and it's not supposed

[wlandgraf (Wagner Landgraf)]

You can create another manager with different sets, yes, and evict objects from one manager to the other manager.
Or you can simply directly change the TxOptions in the underlying TFDConnection directly, before updating the objects.

[MVF_MVF]

Hi,
"Or you can simply directly change the TxOptions in the underlying TFDConnection directly, before updating the objects."
How to do that? something like:
TFDConnection(Manager.Connection).TxOptions.ReadOnly := True; //wrong
or
TFDConnection(Manager.Connection).Transaction.Options.ReadOnly := False;
How to get access to ReadOnly?

Thanks

[wlandgraf (Wagner Landgraf)]

The way you can reference the original connection from manager's IDBConnection is described here in documentation:
https://doc.tmssoftware.com/biz/aurelius/guide/database.html#referencing-original-component

var
  MyConnection: IDBConnection;
  FDConnection: TFDConnection;
{...}
  FDConnection := (MyConnection as IDBConnectionAdapter).AdaptedConnection as TFDConnection;

[MVF_MVF]

Ok,
thanks