I'm trying to fine tune a reporting component for a web based application which I maintain, while trying to find out why retrieving large number of rows is taking to long I noticed that the wait_info value that describes the status of the currently running SQL statements is set to "ASYNC_NETWORK_IO" which suggests that SQL server is waiting to the client application to get the result back, and on the application side I keep seeing that the process is spending to much time on
ODBCSession>>SQLExtendedFetch:with:with:with:with: "which accesses C code that is deprecated long time ago"
my question is that is there any way to work around this? is there any plans to replace these deprecated C calls with better/newer alternatives? if not how can I call my ODBC function like SQLFetchScroll that is the alternative to SQLExtendedFetch?
This might be stating the obvious, but
not having a lot of information, I would make sure you don't have an indexing
issue with your database table(s). Selects can take a long time if
the whole table needs to be scanned, so you'll want to be sure you have
an index defined that is appropriate for the query you're doing. This
is easy enough to test with a command line query. We use the DB2EXDI
package on vw 7.7.1 and vw7.10 on aix, linux and windows and have no performance
thank you MarkPetersen for your input, I've already tried to do that and I think that there is no problem at the database side since the running processes show a wait type of "ASYNC_NETWORK_IO" which indicates that the client application is not retrieving the results as fast as SQL server is offering them.
> thank you MarkPetersen for your input, I've already tried to do that and I
> think that there is no problem at the database side since the running
> processes show a wait type of "ASYNC_NETWORK_IO" which indicates that the
> client application is not retrieving the results as fast as SQL server is
> offering them.
> View this message in context: http://forum.world.st/SQLExtendedFetch- performance-problem-tp4737617p4752453.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
Although I'm not sure whether the use of SQLExtendedFetch causes the
problem, we are evaluating the option of replacing the deprecated ODBC APIs
with the new ones. Since there will be quite some changes involved, it may
take some time or we may do it in multiple steps.
Please contact Cincom support if you want more information.