| Subject | Re: [ib-support] IB server doesn't free memmory and my application turns extremely slow |
|---|---|
| Author | Helen Borrie |
| Post date | 2001-12-06T05:53:08Z |
Luciano,
At 12:40 AM 06-12-01 -0300, you wrote:
Delphi provides the TDatabase component as a container that encapsulates both a connection to the database and a single transaction. Usually in a database application, you would use this component, and connect all of your dataset components to it, via their DatabaseName property. In this way, you get to operate all of your data access in the context of a single transaction. Although this is not great for Firebird/InterBase or Oracle, which derive their greatest power from their ability to isolate tasks in multiple transactions, it is great for Paradox. The Delphi VCL DA components are, to put it bluntly, designed to make all RDBMSs behave like Paradox. That's why we have products like IB Objects, IBX, FIB-Plus and Oracle DOA to replace the VCL/BDE connectivity.
The native VCL's virtual TDataset is also capable of making spreadsheet files behave like database tables. Because there is no "database" to connect to, the TDataset components are able to work without a TDatabase component. Without one, they internally create a structure that behaves like a TDatabase. With datasets which actually do derive their data from database tables, this mechanism creates a database connection and (for RDBMSs that have transactions) a transaction for *each* TDataset object. This obviously undesirable.
You are using the IB Objects TIBOTable (a TDataset descendant) in this way, without a TIBODatabase or any TIBOTransactions. Each time you open your many TIBOTables, you are creating another separate connection and another separate transaction.
As was pointed out to you elsewhere, your problems are typical of the situation where the database resources are being progressively consumed and not re-used because of one or more long-running unresolved transactions, extinct database cursors being held open, etc. etc.
In other words, treating database tables as if they were Excel spreadsheets is not going to get you close to an effective client/server application. If you read up about transaction-based processing and concurrency, you will soon discover why you are seeing the problems you described.
As this forum is not for Delphi nor IBO problems, you will find a solution by using the resources available to Delphi and IBO programmers - online FAQ at www.ibobjects.com, Technical Info sheets at the same site, demo applications in the IBO installation directories and, especially, the ibobjects list forum, where you have posted related questions.
regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
At 12:40 AM 06-12-01 -0300, you wrote:
>i noticed that the application opens several transactions (about 250) for small amount of data (tables that contains less than 20 rows). is this amount of open transactions (which are never commited while the application is running) a cause for the ibserver to start working slowly after a couple of hours?From your postings here and elsewhere, I'm beginning to see that your problems stem from the way you are using Delphi, not from the database. Let me explain a little...
Delphi provides the TDatabase component as a container that encapsulates both a connection to the database and a single transaction. Usually in a database application, you would use this component, and connect all of your dataset components to it, via their DatabaseName property. In this way, you get to operate all of your data access in the context of a single transaction. Although this is not great for Firebird/InterBase or Oracle, which derive their greatest power from their ability to isolate tasks in multiple transactions, it is great for Paradox. The Delphi VCL DA components are, to put it bluntly, designed to make all RDBMSs behave like Paradox. That's why we have products like IB Objects, IBX, FIB-Plus and Oracle DOA to replace the VCL/BDE connectivity.
The native VCL's virtual TDataset is also capable of making spreadsheet files behave like database tables. Because there is no "database" to connect to, the TDataset components are able to work without a TDatabase component. Without one, they internally create a structure that behaves like a TDatabase. With datasets which actually do derive their data from database tables, this mechanism creates a database connection and (for RDBMSs that have transactions) a transaction for *each* TDataset object. This obviously undesirable.
You are using the IB Objects TIBOTable (a TDataset descendant) in this way, without a TIBODatabase or any TIBOTransactions. Each time you open your many TIBOTables, you are creating another separate connection and another separate transaction.
As was pointed out to you elsewhere, your problems are typical of the situation where the database resources are being progressively consumed and not re-used because of one or more long-running unresolved transactions, extinct database cursors being held open, etc. etc.
In other words, treating database tables as if they were Excel spreadsheets is not going to get you close to an effective client/server application. If you read up about transaction-based processing and concurrency, you will soon discover why you are seeing the problems you described.
As this forum is not for Delphi nor IBO problems, you will find a solution by using the resources available to Delphi and IBO programmers - online FAQ at www.ibobjects.com, Technical Info sheets at the same site, demo applications in the IBO installation directories and, especially, the ibobjects list forum, where you have posted related questions.
regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________