[egenix-users] cursor.executedirect configurable?

[Brad Allen]

Sorry for the delay in getting back to you on this...those Microsoft 
links are broken.

I will try to followup with you later this week on doing an ODBC trace.

M.-A. Lemburg wrote:
> On 2008-09-11 17:28, Brad Allen wrote:
>   
>> M.-A. Lemburg wrote:
>>     
>>> You have 8 '?' markers in your query, so that looks fine. However,
>>> the query is rather complicated with respect to all the joins, so
>>> it's possible that the ODBC driver doesn't parse the query correctly
>>> and perhaps misses out on some of the parameter markers.
>>>
>>> It may also get confused by the "_3" aliases. Why the quotes and why
>>> double-quotes instead of square brackets ?. What setting do you
>>> use for QUOTED_IDENTIFIERS ?
>>>   
>>>       
>> I those "_3" aliases were created by Storm's ClassAlias; I discovered a
>> parameter that would allow me to specify the name when creating the
>> ClassAlias instances. That got rid of the "_3" aliases in the query, and
>> there are no more quoted identifiers, and now the query is more
>> readable. However, it still fails when using cursor.execute and succeeds
>> when using cursor.executedirect.
>>     
>
> Very strange indeed.
>
>   
>>> Some more general questions:
>>>
>>> Are you using the most recent SQL Server Native client on the
>>> Windows machine ?
>>>   
>>>       
>> I was using the normal SQL Server driver; I changed to the SQL Server
>> native client but am still seeing the same behavior. As far as whether
>> it's the latest, it's the version that comes with Windows Server 2003
>> Standard Edition Service Pack 3.
>>     
>
> You can check the version number by looking at
>
> connection.driver_version
>
> I get 09.00.3042 for out installation of SQL Server native client.
> connection.driver_name is 'SQLNCLI.DLL'.
>
>   
>>> How are you converting the params before using them on
>>> cursor.execute() ?
>>>
>>>       
>>   
>> I think Storm is handling that by building a tuple of a tuple of
>> strings, just like we would normally pass to cursor.execute for bind
>> parameters. I haven't checked to see exactly what it is doing there, but
>> we aren't having any issues with parameter substitution for any of our
>> other queries.
>>     
>
> Ok, so it's not related to data conversion either.
>
> Could you please try to run the query on a fresh new cursor
> (ie. one that hasn't executed any queries yet) and see whether
> that makes a difference ?
>
> If that doesn't help, the next thing we could try is an
> ODBC trace. These are the instructions to enable such a trace
> on Windows:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsetting_tracing_options.asp
>
> If standard tracing doesn't work, you could try the
> Visual Studio Analyzer:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcenabling_visual_studio_analyzer.asp
>
> Note that tracing has to be enabled for the user account
> that the application is using in MDAC 2.8. There's a
> new option in MDAC 2.8 which also allows machine wide tracing
> (which was the only option in MDAC 2.7 and prior versions):
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;818489
>
> Please send us the trace snippet for the query in question.
>
> Thanks,
>   

-- 
ZeOmega
Open Minds' Open Solutions
3010 Gaylord Parkway, Ste. 210
Frisco TX, 75034
http://www.zeomega.com

Brad Allen
214-618-9880 (ext. 8006)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /mailman-archives/egenix-users/attachments/20080916/89598acf/attachment.htm