[python-sybase] problems with executing dynamically created queries.

[Erik Thiele]

On Fri, 23 Jul 2004 17:07:55 +1000
Dave Cole <djc@object-craft.com.au> wrote:

> Erik Thiele wrote:
> > On Fri, 23 Jul 2004 14:19:32 +1000
> > Dave Cole <djc@object-craft.com.au> wrote:
> > 
> > 
> >>Erik Thiele wrote:
> >>
> >>
> >>>and... why is there several styles in DB API 2.0? i mean the
> >>>Sybase.paramstyle thing. i thought DB API was there for
> >portability,>>and then i find out that different modules have
> >different ways to>>create sql queries. so there is absolute zero
> >portability. why?>
> >>You will have to ask the database vendors that one.
> > 
> > 
> > ah! so it's a problem with the database? i thought that this
> > parameter substitution thing was an issue of the DB API and every
> > python database driver programmer just decides which one to use. so
> > that's not true! actually there should be a wrapper function on top
> > of DB API that can transform one single paramstyle into all the
> > others. or is there a technical reason why that's not possible?
> > anyway once you maybe answer this question i will make a suggestion
> > to python DB guys to add this to the FAQ. i tried to figure out why
> > this is so for just too long time. also that FAQ entry must point
> > out why there is no wrapper, or where it is :)
> 
> I am not sure that it is that simple for all databases.  If at all 
> possible it is a good idea to pass binary parameters to the server and
> 
> let the binding of parameters to the SQL occur at the server. 
> Unfortunately each database vendor has decided upon different
> parameter placeholders.  Some databases do not support parameter
> passing so the client side must format the arguments into the SQL
> query sent to the server.
> 
> It might be a good idea if some very clever person developed a 
> bullet-proof SQL query formatter that worked for all SQL variants. 
> Then the DB-API would just need to include formatters for native
> database types that could yield strings to be used by the formatter. 
> Who knows - this might have already been done.

it would be the ultimate step in the direction of database independency
if there was only one paramstyle left. then the DB-API wins over the
other APIS finally. until now i have to do some assertion that the
paramstyle is correct, otherwise the program does not run. i cannot
quite understand why they didn't include it from the beginning. i don't
see a big problem in writing a function that converts the query in one
paramstyle into a query of another paramstyle. Am i missing something?


-- 
Erik Thiele