RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-22 Thread Joe Tebelskis
nal Message- From: Jeff Urlwin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 6:21 PM To: Joe Tebelskis; Jeff Urlwin; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Tim Bunce Subject: RE: Multiple Result sets in DBD::ODBC (and others?) > > Hi, I'm back from vacation. I see you

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-22 Thread Joe Tebelskis
eff Urlwin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 9:03 AM To: [EMAIL PROTECTED]; Jeff Urlwin Cc: [EMAIL PROTECTED]; Joe Tebelskis; Tim Bunce Subject: RE: Multiple Result sets in DBD::ODBC (and others?) > > On 20-Aug-2002 Jeff Urlwin wrote: > > I've been think

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-21 Thread Jeff Urlwin
> > Hi, I'm back from vacation. I see you and Martin have been > discussing my latest reported bug at length. I don't understand > the full discussion, but I think I get the gist of the problem, > i.e., that there's a fundamental probem in DBD::ODBC when a > stored procedure performs heterogeneo

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread Jeff Urlwin
> > On 20-Aug-2002 Jeff Urlwin wrote: > > I've been thinking a bit more about this. > > > > It *may* be a "reasonable" thing, for now, to: > > - "silently" eat result sets without columns (i.e. count of rows > > inserted/deleted/updated) > > Presumably, you mean here ignore a result

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread martin
On 20-Aug-2002 Jeff Urlwin wrote: > I've been thinking a bit more about this. > > It *may* be a "reasonable" thing, for now, to: > - "silently" eat result sets without columns (i.e. count of rows > inserted/deleted/updated) Presumably, you mean here ignore a result if there are no

Re: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread Tim Bunce
On Tue, Aug 20, 2002 at 09:35:41AM -0400, Jeff Urlwin wrote: > I think if this is not stable enough or if I make the time to rework the > whole thing to: > [...] > > Thoughts/comments welcome! I like it. Tim.

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread Jeff Urlwin
I've been thinking a bit more about this. It *may* be a "reasonable" thing, for now, to: - "silently" eat result sets without columns (i.e. count of rows inserted/deleted/updated) - provide multiple result sets to the user via the odbc_more_results attributed - automatical

Re: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread Tim Bunce
On Tue, Aug 20, 2002 at 09:26:17AM +0100, [EMAIL PROTECTED] wrote: > PHP gets around this with odbc_close() which I believe $stmt->finish() could be > used for. The main problem would then be requiring scripts to call finish which > I guess would be undesirable. > > I'm not sure but I'd guess the

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-20 Thread martin
; -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On >> Behalf Of [EMAIL PROTECTED] >> Sent: Monday, August 19, 2002 1:35 PM >> To: Jeff Urlwin >> Cc: [EMAIL PROTECTED]; Joe Tebelskis >> Subject: RE: Multiple Result sets in DBD::ODBC

Re: Multiple Result sets in DBD::ODBC (and others?)

2002-08-19 Thread Tim Bunce
I agree. Tim. On Mon, Aug 19, 2002 at 06:34:32PM +0100, [EMAIL PROTECTED] wrote: > > On 19-Aug-2002 Jeff Urlwin wrote: > > Martin, > > > > I think you and I are basically saying the same thing (semantic differences, > > I think): > > 1) the user should be responisble to check for more re

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-19 Thread Jeff Urlwin
- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, August 19, 2002 1:35 PM > To: Jeff Urlwin > Cc: [EMAIL PROTECTED]; Joe Tebelskis > Subject: RE: Multiple Result sets in DBD::ODBC (and others?) > > > > On 19-Aug-20

RE: Multiple Result sets in DBD::ODBC (and others?)

2002-08-19 Thread martin
On 19-Aug-2002 Jeff Urlwin wrote: > Martin, > > I think you and I are basically saying the same thing (semantic differences, > I think): > 1) the user should be responisble to check for more results > > 2) DBD::ODBC shouldn't "silently" eat up result sets. > > 3) even no-colu