Re: [DB-SIG] client side sub queries

2007-05-24 Thread Carsten Haese
On Thu, 2007-05-24 at 15:10 -0500, Carl Karsten wrote: > > There is also Option 3: Use actual parameter passing to build a WHERE ... IN > > (...) clause: > > > > cSql = ("select ktbl2_fk from tbl3 where OtherKey IN (" > > +",".join("%s" for _ in cList) > > +")" ) > > cur.execute(cS

Re: [DB-SIG] client side sub queries

2007-05-24 Thread Carl Karsten
> There is also Option 3: Use actual parameter passing to build a WHERE ... IN > (...) clause: > > cSql = ("select ktbl2_fk from tbl3 where OtherKey IN (" > +",".join("%s" for _ in cList) > +")" ) > cur.execute(cSql, cList) Don't suppose you know off the top of your head how to co

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Carsten Haese wrote: > On Wed, 2007-05-23 at 13:13 -0500, Carl Karsten wrote: >> list = rows >> cSql = ("select ktbl2_fk from tbl3 where ktbl1_fk IN (" >>+",".join("%s" for _ in list) >>+")" ) >> print cSql >> cur.execute(cSql, list) > > Assuming that "rows" is the fetchall() result from y

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Chris Clark wrote: > Carl Karsten wrote: >> Carsten Haese wrote: >> >>> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >>> Or some such abomination of results of one query as a parameter of a 2nd. given my use case, I can understand why this isn't in the spec, a

Re: [DB-SIG] client side sub queries

2007-05-23 Thread M.-A. Lemburg
On 2007-05-23 20:37, Chris Clark wrote: > Carl Karsten wrote: >> Carsten Haese wrote: >> >>> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >>> Or some such abomination of results of one query as a parameter of a 2nd. given my use case, I can understand why this

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Chris Clark
Carl Karsten wrote: > Carsten Haese wrote: > >> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >> >>> Or some such abomination of results of one query as a parameter of a >>> 2nd. >>> >>> given my use case, I can understand why this isn't in the spec, and >>> why it may never be.

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carsten Haese
On Wed, 2007-05-23 at 13:13 -0500, Carl Karsten wrote: > list = rows > cSql = ("select ktbl2_fk from tbl3 where ktbl1_fk IN (" >+",".join("%s" for _ in list) >+")" ) > print cSql > cur.execute(cSql, list) Assuming that "rows" is the fetchall() result from your first query, try list = [x[0

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Carsten Haese wrote: > On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >> Or some such abomination of results of one query as a parameter of a >> 2nd. >> >> given my use case, I can understand why this isn't in the spec, and >> why it may never be. but it seems to come up more often that

Re: [DB-SIG] client side sub queries

2007-05-22 Thread Carsten Haese
On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote > Or some such abomination of results of one query as a parameter of a > 2nd. > > given my use case, I can understand why this isn't in the spec, and > why it may never be. but it seems to come up more often that I > would expect, so here

[DB-SIG] client side sub queries

2007-05-22 Thread Carl Karsten
Or some such abomination of results of one query as a parameter of a 2nd. given my use case, I can understand why this isn't in the spec, and why it may never be. but it seems to come up more often that I would expect, so here we go. My current problem: reconcile transaction details that are o