Devart Forums

how to prevent the dataset from being closed in case of loss of connection to the server?

I have the following scenario:
I am editing the data in a form with dbedits and a dbgrid, then the network drops, when I click on the record button I have the treatment:
   try
     FDQuery1.Post;
   except on E: Exception from
     begin
      ShowMessage ('Error writing letters' + sLineBreak + e.Message);
      Exit;
     end;
   end;

at that moment the network drops, and returns the message to the user above the exception, plus clicking OK in the message the dataset has already closed and dbgrid also no longer shows the data, it has to prevent this, and let the data stay in the screen?

To solve you issue, you can use the disconnected mode. More details can be found at https://www.devart.com/unidac/docs/?wor ... ctmode.htm

is there any way to use disconnected mode without having to enable cached updates and resolve this issue of the dataset close when the connection crashes?

To solve your task, you can use the disconnected mode without using cached updates. For this, you just need to set the TUniConnection.Options.DisconnectedMode property to True and, when an error occurs, call the TUniQuery.Cancel method.
Note, the recommendation of using Cached Updates with disconnected mode in our help serves to reduce the number of calls to the server and is advisory rather than mandatory.

because usually here the user is with a maximum of 1 record open, and all my screens of registers on the exit I make Query.close this would not be slow, every time that the user enter and leave a screen ?, how to get around this so that the close and open the query is faster?

Please write in more detail what is the essence of your previous post, and even better, if it does not complicate you, for a more accurate understanding of the question and an early reply to it, please send us via e-support form: https://www.devart.com/company/contactform.html a small sample to demonstrate the issue.

I just wanted to get one more doubt. in my system I use a lot of dbgrid and I have tables with many records, I noticed that if the user moves dbgrid to the end of the records, it has a lentidao, and I use it very close to closing the forms. open do not have this delay to bring the database records ?, I tried to use the connection pool did not resolve with firebird 2.5

The TUniQuery component has the FetchRows and SpecificOptions.Values['FetchAll'] properties, which default values for InterBase provider are 25 and False correspondingly. If FetchAll = False, only FetchRows of rows will be read during the fetch of the TUniQuery.Open method. The rest of the rows will be retrieved by necessity.
When in DBGrid you move to the last record, all the table records are fetched, that is the reason for the slowness. You can set the SpecificOptions.Values ['FetchAll'] property to True, then the data will be completely fetched when calling the TUniQuery.Open method, and further movement through the records will be fast.

I tried it, so the slowness when moving in dbgrid will go through the process of opening after fetchall = true, I think it has no way of solving it?
because tables with many records, will depend on the user to move or not, I tested with the dbgrid CRDBGRID plus it can not do miracles because the user move the pointer of the table to the last one.

in the cases that close the querys when user closes a form and after it enters again, I verified that even with connection pool it searches the records again as if it did not have cached nor poll, this gives to the reason of all close and open to bring the data of the server and not the cache?

1. Yes, you are right, as we wrote earlier, now the delay appears when the dataset is opened. The reason for the delay is all query data fetching (with FetchAll = False: the first 25 records were fetched, and the rest were fetched later when navigating; with FetchAll = True: all records were fetched as soon as they were opened).
2. Connection pool is not related to datasets, using a pooled connection can result in significant performance gains, because applications can save the overhead involved in making a connection: https://www.devart.com/unidac/docs/inde ... ooling.htm. When closing the dataset and re-opening it, the data will be re-fetched again.