From: | "Mace, Richard" <richard(dot)mace(at)Lorien(dot)co(dot)uk> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <olly(at)lfix(dot)co(dot)uk> |
Cc: | <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: |
Date: | 2003-12-18 15:37:25 |
Message-ID: | 07D7DD4F541A1743843C313080B3FB1A47A9A3@frdads01.lorien.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Thanks for your help everyone.
I have to admit to using the wrong DBD Driver; or copying an older script with
reference to an inferior version I used previously. Let that be a lesson to us
all !!
thanks once again,
Richard.
-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 18 December 2003 15:05
To: olly(at)lfix(dot)co(dot)uk
Cc: Mace, Richard; pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE]
Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> On Thu, 2003-12-18 at 08:40, Mace, Richard wrote:
>> This code works fine for a field that is always populated e.g. name in
>> place of telephone in line 1.
> If a cell is NULL, I think it is undefined in DBI
I'm not much of a DBI user, but one would hope that fetch() represents
null values by storing an undef, rather than failing. Anything else
would indicate utter brain death on the part of the DBI designers.
Richard's example code looks fine to me, but I wonder if it is an exact
copy of his real code. The error message ("Statement has no result to
bind") is pretty specific and it's hard to see how it would come out
from a bind operation on a SELECT statement. I am wondering about
simple typos like applying the bind_columns call to the wrong statement
handle.
regards, tom lane
**********************************************************************
The information contained in this email is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply email and then delete it from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person or store or copy this information in any medium. The views contained in this email are those of the author and not necessarily those of Lorien plc.
Thank you for your co-operation.
**********************************************************************
From | Date | Subject | |
---|---|---|---|
Next Message | Patrice Durosay | 2003-12-18 17:57:40 | Can't create lock file /tmp/.s.PGSQL.5432.lock |
Previous Message | Tom Lane | 2003-12-18 15:04:53 | Re: |