I've been using DBIx::Recordset for a while now, and it's been great.
However, just the other day I started adding some new functionality to
my program, and I've started getting this error message:
[Fri Dec 12 09:06:29 2003] [error] [client 4.63.107.173] Premature end
of script headers: purchas
Terrence Brannon wrote:
Daniel Brooks wrote:
I've been using DBIx::Recordset for a while now, and it's been great.
Yes, Recordset is great :)
However, just the other day I started adding some new functionality
to my program, and I've started getting this error message:
[Fri
db48x
Daniel Brooks wrote:
Terrence Brannon wrote:
Daniel Brooks wrote:
I've been using DBIx::Recordset for a while now, and it's been great.
Yes, Recordset is great :)
However, just the other day I started adding some new functionality
to my program, and I've started gettin
Rudy Lippan wrote:
On Mon, 15 Dec 2003, Daniel Brooks wrote:
Ok, DBD::ChurlPg must have been an earlier version of DBD::Pg or
something, because my copy of DBD::Pg has the exact same code.
That would be my fault. I created mine own copy of DBD::Pg
(DBD::ChurlyPg) for development, and when
I'm using DBIx::Record set to great effect, but I've discovered a bug
which annoys me. An SQL statement with joins in it doesn't need to name
any tables, but if I leave out the !Tables parameter it produces a
statement like 'SELECT * FROM', which the server rightly rejects with an
error. I'd li
Gerald Richter wrote:
I'm using DBIx::Record set to great effect, but I've
discovered a bug which annoys me. An SQL statement with joins
in it doesn't need to name any tables, but if I leave out the
!Tables parameter it produces a statement like 'SELECT *
FROM', which the server rightly rejects
