Member Login

Username
Password
Forget Password
New Sign Up
Search Forum

Buy Support
Incidents

If you can't find your answer in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us private or confidential information:

Click Here
If you can't login and post questions or you are having trouble viewing forum posts:
Click Here
Callback
Support

If you live in USA, UK, Canada, Australia or New Zealand, you can leave us details on your question and request us to call you back and discuss them with you personally  (charges apply).

Click Here
 
Buy Support
Incidents
If you can't find your answer in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us private or confidential information:
Click Here

Forum : Why is the FlexODBC driver so slow?Search Forum

Forum Home > FlexODBC - ODBC Driver for DataFlex Embedded DBMS > FlexODBC Frequently Asked Questions

 New Topic 
 
 Post Reply 
 Why is the FlexODBC driver so slow? 
 Author   Message 
  Tom 
  6c3c1_sdk-qodbc.gif
 Group: Administrator 
 Posts: 5510 
 Joined: 2006-02-17 
 Profile
 Posted : 2006-02-26 12:50:34
FlexODBC is a lightning fast driver for DataFlex files using ODBC. The driver works with all front-end applications, which can access ODBC, some of which are faster than others.

This question is almost never asked by our users using C as a front end language for ODBC, nor by report writer users with Crystal, or DBMS users with Delphi. These users will see immediately how fast the driver is because their applications are optimized for ODBC speed.

It is almost always asked by users of Microsoft Access, whose first operation is to open the largest file they have in their DataFlex system in a Datasheet. They notice that the grid comes up quickly, but if they page down to the next screen-full of records, it takes a while. Why Access is slow compared to other systems can be easily explained.

Access is overloaded with multi-user functionality, meaning that features like updating all stations when a record changes on-line and other features are easily accomplished by the native Access file format. When Access uses ODBC however, it attempts to do the same thing. For instance, when you open a multi-user grid on an ODBC data file, it must read the entire file into memory before continuing. This continues in the background, and when you press page-down, Access waits until the file has been completely read before beginning another query of the entire file, starting with the last record of the previous screen.

Other DBMS systems optimized for ODBC, such as Delphi, query only the number of records needed to fill the current screen with data, and does not continually refresh the database on the screen for no reason. Access only has this problem in Datasheet view, which is unfortunately the first thing people use with our driver. However, if you create a query and send it as input to a report, you will see how fast our driver can run under Access.

When programming with SQL (the transport language of ODBC drivers) it is a good idea to think of an SQL table as being a "cloud" of data with potentially unlimited records. You should therefore design queries and views of only the fields and records required for the current transaction or report, and not attempt to query all records in a given table, which may overload the system.

DataFlex programs are programmed in a single record orientation, while SQL/ODBC is set based. Access attempts to read each result from a data query into memory, as if your data were a spreadsheet, and DataFlex files tend to be very large. Applications built with Access should assume that large files will be used and show only the data appropriate to the current transaction in a grid control.

Microsoft Access is optimized to work with its built-in data manager only (MDB files), and any Access programmer who has used ODBC will tell you about the limitations Access has in this area. Other packages work very well with ODBC data drivers. When using MS Access, use unbound forms to bypass Access automatic record saving features and use the Visual Basic functions to display and process data using the inbuilt ActiveX Data Objects (ADO) programming model instead.

If you would like to see what Access is doing that makes it appear to "lock up" while running a query, you may like to turn on our debug control panel.
 

  Top 
 New Topic 
 
 Post Reply 

Jump to