Database Engines:odbc

Browsing tables Professional

To browse a table means to display tabular data and to allow for user-navigation within this data. The browse display includes a limited number of table records that can be scrolled up and down in the visible display area, record by record and/or page by page. The common implementation for a database browser in Xbase++ is based on the TBrowse or XbpBrowse class, both of which implement a navigational model based on single records, or table rows (the "skip" routines for theses browsers include DbSkip(-1), DbSkip(+1)).

"Single row" navigation is appropriate in the Xbase database model (DBF files), but it is not appropriate when tables are provided by a SQL DBMS. A DBMS does not transfer "single records" to a client application, but transfers multiple records at once, or entire "record sets". Therefore, a browser on the client side must be capable to handle "record sets" received from the DBMS. Otherwise the browser may reduce the performance of a client application by sending too many requests to the server. This can lead -in the worst case- to a situation where the DBMS is blocked by responding to only one client application.

To support the architecture of SQL DBMS best, an Xbase++ client application should only use browsers like XbpQuickBrowse. This browser class takes advantage of the DacPagedDataStore class to access the data source. The DacPagedDataStore class is capable of holding entire "record sets" in its cache (the "record sets" being sent from server to the client). The cache, in turn, allows for "single row" navigation on the client side (Xbase style), and reduces the workload on the server to a minimum when the user navigates through a table within the browser.

Feedback

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.