ODBCLink/SE Reference Manual | Application Development |
Performance Considerations
Many users find ODBC access to their server very fast. You should however be aware of the following:
⊗If you are reading and sorting a large table, the host may not return control to the client until the entire data-base has been read and sorted. If this occurs, even restarting your Client PC will have no effect and you will have to manually abort the server, or terminate the connection with the ISQL “Terminate User” command.
⊗When you are opening a large table in MS-Access, the program typically displays a screenful of data and then seems to wait for user input. In many cases, however, it will actually be downloading data to the client in the background. You should think about this when giving your users ODBC access to large tables on the server. You may give or withhold access to certain tables with the ALLBASE/SQL GRANT and REVOKE commands. There is no way currently of limiting the number of rows or the time the server is allowed to execute a request.
⊗As a rule of thumb, ODBCLink/SE will not complete any request faster than ISQL will, and could be considerably slower due to network overhead. If you are writing your own SQL, you may want to verify in ISQL how ALLBASE/SQL optimizes your queries by reading the SYSTEM.PLAN pseudo-table.
⊗If you are writing your own SQL to do multi-row inserts or updates, you can speed up your application by using dynamic substitution parameters. See the ODBC SDK manual (from Microsoft Press) for details.
ODBCLink/SE | |
©M.B. Foster Associates Limited 1995-2000 | 29 |
