[egenix-users] cursor.executedirect configurable?

[M.-A. Lemburg]

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,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 11 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611