On Wed, Jun 29, 2011 at 03:28:19PM +0100, Martin J. Evans wrote:
> Don't know however, I am inclined to change the error to a warning as Tim
> suggested. It simplifies things for people who might be calling fetch on a
> non-select. However, it isn't going to happen soon unless someone screams for
Show, don't tell. Also, it's a little shorter now.
BEGIN THING TO INSERT
=head3 On use of non-C SQL in C methods
While some drivers support statements other than C in the
above-listed convenience functions, others do not: driver support for this
facility is not defined by the DBI interface stand
On 29/06/11 14:34, David Nicol wrote:
On Wed, Jun 29, 2011 at 3:02 AM, Martin J. Evans
wrote:
BEGIN THING TO INSERT
=head3 On use of non-CSQL in Cmethods
When you really don't know if the statement you have in a
variable is going
to be a C or not, unrolling the process into
C,C
On Wed, Jun 29, 2011 at 3:02 AM, Martin J. Evans
wrote:
>> BEGIN THING TO INSERT
>> =head3 On use of non-C SQL in C methods
>>
>> When you really don't know if the statement you have in a
>> variable is going
>> to be a C or not, unrolling the process into
>> C,C, and
>> a C called within a
On Wed, Jun 29, 2011 at 09:02:27AM +0100, Martin J. Evans wrote:
> On 24/06/11 16:17, David Nicol wrote:
>
> perl -le 'use DBI; my $h = DBI->connect(); my $s = $h->prepare("create table
> fred (a int)"); $s->execute; my $r = $s->fetch;'
> DBD::ODBC::st fetch failed: no select statement currently
On 24/06/11 16:17, David Nicol wrote:
On Sat, Jun 11, 2011 at 12:51 PM, Tim Bunce wrote:
Patch welcome.
Tim.
here's a revised new paragraph, to go right before the =head3 C.
BEGIN THING TO INSERT
=head3 On use of non-C SQL in C methods
While some drivers support statements other than C
On Sat, Jun 11, 2011 at 12:51 PM, Tim Bunce wrote:
> Patch welcome.
>
> Tim.
here's a revised new paragraph, to go right before the =head3 C.
BEGIN THING TO INSERT
=head3 On use of non-C SQL in C methods
While some drivers support statements other than C in the above-listed
convenience functi
On Fri, Jun 17, 2011 at 02:46:43PM +0100, Martin J. Evans wrote:
> >The only thing I'm not sure about is whether $sth->{NUM_OF_FIELDS} is always
> >set by $dbh->prepare, or whether some DBMS can't set it until you do
> >$sth->execute.
>
> Right now, I am unsure of that too.
Some can't at all, som
On 17/06/11 13:19, Jonathan Leffler wrote:
On Fri, Jun 17, 2011 at 04:11, David Nicol wrote:
Thanks-- the proposed docpatch was a trial balloon to get this answer.
Here's copy for a revised proposed patch:
When you really don't know if the statement you have in a variable is going
to be a C
On Fri, Jun 17, 2011 at 04:11, David Nicol wrote:
> Thanks-- the proposed docpatch was a trial balloon to get this answer.
> Here's copy for a revised proposed patch:
>
> When you really don't know if the statement you have in a variable is going
> to be a C or not, unrolling the process into
>
Thanks-- the proposed docpatch was a trial balloon to get this answer.
Here's copy for a revised proposed patch:
When you really don't know if the statement you have in a variable is going
to be a C or not, unrolling the process into C,C,
and some C variant called within an C block will always
On 11/06/11 22:49, David Nicol wrote:
I'm not 100% sure about the assertion about calling fetch on an
executed non-select statement handle being defined to reliably return
false, as in no-more-data as part of the standard. If C isn't
really defined to behave the same with a non-SELECT as with a
Otherwise,
... and some fetch variant called within an C block ...
> +=head3 On use of non-C SQL in C methods
> +
> +While some drivers support statements other than C in the
> above-listed
> +convenience functions, others do not. Requirement of this facility is
> not defined
> +by the DBI int
I'm not 100% sure about the assertion about calling fetch on an
executed non-select statement handle being defined to reliably return
false, as in no-more-data as part of the standard. If C isn't
really defined to behave the same with a non-SELECT as with a SELECT
that simply doesn't return any row
On Fri, Jun 10, 2011 at 10:13:09AM -0500, David Nicol wrote:
> in my opinion this facility should be formally defined as "undefined" and a
> note should go in the selectall* docs recommending "do" instead for
> non-select SQL.
+1
Patch welcome.
Tim.
in my opinion this facility should be formally defined as "undefined" and a
note should go in the selectall* docs recommending "do" instead for
non-select SQL.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Before I do that I'd like to be sure DBI/DBD should not support
> non-select statements in selectall_*.
I don't think it should, although we have to be careful about
perhaps differentiating between 'non-select' statements and statements
th
Is it ever legal (should be supported) to issue a non select in
selectall_arrayref?
Obviously I think not but I'd like to know what other people think. I'm
getting a few rts from the same person who I believe is moving existing
code from DBD::Sybase to DBD::ODBC. The recent one is
18 matches
Mail list logo
