Problem with reading in packet mode

Hi Ovidiu,
First of all, I would like to confirm my understanding of your issue. From
your description, I understand that when you call SQLSetStmtOption() before
SQLExecDirect() the performance is quite poor. If there is any
misunderstanding, please feel free to let me know.
Yes, as you know, the SQLSetStmtOption can be called before/after
SQLExecDirect. However, from ODBC 3.x SQLSetStmtOption is deprecated. It
has been replaced by SQLSetStmtAttr. So I suggest you try to use
SQLSetStmtAttr to see if performance goes better. Please check the
following link for more information.
http://msdn.microsoft.com/library/d...-us/odbc/htm/od
bcsqlsetstmtoption.asp
If that still doens't work, please feel free to reply to the post.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."Hi Ovidiu,
What is the version of MDAC on your machine? Please try to upgrade to the
latest version MDAC 2.8 sp1 from the following link to see if it can
resolved the problem.
http://www.microsoft.com/downloads/...c895-efc2-4f8e-
a9e0-3a1afbd5922e&DisplayLang=en
Also I suggest you try to set to a larger packet size (e.g. 512).
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
Yes, I have the latest MDAC version: MDAC 2.8 SP1 on Windows XP SP2.
It's true, the performance gets much better when we increase the packet size
(we already knew that), as follows:
- for packet size 512 I get aprox. 7 secs (compared to 49 secs)
- increasing packet size over 512 won't improve performance anymore
The bottom line is: even when using larger values for the packet size,
performance is still poor compared
to the case when SQLSetStmtOption is called after SQLExecDirect (7 secs vs.
1 sec). Why is that happening ?
So, increasing packet size is a good workaround but up to a point.
There is the following bussiness impact: the customers using our application
are asking questions about this (strange) behaviour. Is there any
Microsoft doc, release note, etc. that refers to it ?
Could this issue be escalated such that, at least, we could get an official
answer from Microsoft regarding this behaviour. This would prove at
least that we are not misusing the ODBC API in any way (this was our main
concern in the first place because, actually, the order of ODBC
calls causes this strange behaviour).
Your help is appreciated.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:hYsGn42hFHA.944@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> What is the version of MDAC on your machine? Please try to upgrade to the
> latest version MDAC 2.8 sp1 from the following link to see if it can
> resolved the problem.
> [url]http://www.microsoft.com/downloads/details.aspx?FamilyID=78cac895-efc2-4f8e-[/ur
l]
> a9e0-3a1afbd5922e&DisplayLang=en
> Also I suggest you try to set to a larger packet size (e.g. 512).
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Here, I suggest you try to use 4096 as the packet size to see if there is
any performance increment.. To get an official answer from Microsoft, you
need to contact PSS for professional support. You can find the contact
information from the following link:
http://support.microsoft.com/common...=gp;en-us;offer
prophone
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
As I already specified in my previous reply, increasing packet size over a
certain limit won't improve performance anymore.
Thanks for your help. I will try to escalate this issue through PSS.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:clVPgQDiFHA.3120@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> Here, I suggest you try to use 4096 as the packet size to see if there is
> any performance increment.. To get an official answer from Microsoft, you
> need to contact PSS for professional support. You can find the contact
> information from the following link:
> [url]http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer[/ur
l]
> prophone
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Sorry that I could not provide further assistance on this issue. Good luck!
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."