ComponentOne True DataControl 8.0
Optimizing Data access Performance

Performance Perils of Client-Side Cursors

Setting CursorType=adUseClient enables Microsoft Client Cursor Engine. This means that data will be fetched not directly from the database, but through a special cursor located on the client computer. Client cursors add some important functionality to ADO recordsets, such as Filter and Sort, but they also can lead to a substantial performance degradation if you fetch large amounts of data through the network. When you use client-side cursor, all the data is first fetched from the server to the client, and only then your recordset becomes active.

This performance alert is not specific to True DataControl. It is true for any other uses of ADO recordsets as well.

Note that CursorType=adUseClient by default.

Using SourceConnection to Minimize the Number of Database Connections

Some databases (for example, Oracle) are very sensitive to the number of simultaneously open database connections. Opening multiple connections can be a stress on resources with such databases. This is why, TData tries to reuse database connections with same ConnectionString settings, see Connection pooling. But in some cases, especially if you open and close a form with TData controls, connection pooling won’t work, connections may be removed from the pool when a form closes. Then you might want to use the SourceConnection property to set a pre-established connection for TData controls.

 

 


Copyright (c) GrapeCity, inc. All rights reserved.

Product Support Forum  |  Documentation Feedback