SQLExtendedFetch performance problem

Hi guys,

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?

anyone?

What version of VisualWorks, and what version of Windows?

On Apr 2, 2014, at 8:22 AM, helwanif <[hidden email]> wrote:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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 problems.

Regards, Mark

Mark K. Petersen Senior Engineer, DMACS Team Lead Semiconductor R&D Center IBM Systems and Technology Group

Home Office: (319) 406-4165 Cell: (319) 483-8347 Internet email: [hidden email] Internal DMACS Community

 



From:        helwanif <[hidden email]>
To:        [hidden email],
Date:        04/02/2014 07:30 AM
Subject:        Re: [vwnc] SQLExtendedFetch performance problem
Sent by:        [hidden email]

---

anyone?



--
View this message in context: http://forum.world.st/SQLExtendedFetch-performance-problem-tp4737617p4752259.html
Sent from the VisualWorks mailing list archive at Nabble.com.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

it's VisualWorks 7.9.1 running on Windows Server 2008 R2

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.

helwanif <helwanif <at> hotmail.com> writes:

>
> 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.

Yuwei


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks Yuwei for your reply, I've submitted a case at Cincom support portal in this regards.

regards
Fahd