Re: DBIx::Recordset error message
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.
Confusing. Anyway, does anyone have any idea how to fix it? It just
looks like DBIx::Recordset is generating an SQL statement that DBD::Pg
can't deal with.
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 getting this error message:
[Fri Dec 12 09:06:29 2003] [error] [client 4.63.107.173] Premature
end of script headers: purchase.pl
[Fri Dec 12 09:06:29 2003] [error] [client 4.63.107.173] [Fri Dec 12
09:06:29 2003] purchase.pl: Error executing run mode 'add_item':
DBD::ChurlPg
ChurlPg ah:
http://archives.postgresql.org/pgsql-interfaces/2003-02/msg5.php
You know, now that you mention it, I thought I was using DBD::Pg. I'll
have to check my setup, since this is test machine is a bit newer than
my production machines.
only knows about the pg_type attribute at
/usr/lib/perl5/site_perl/5.8.0/DBIx/Database.pm line 148.
That message is coming from DBD::ChurlPg's dbdimp.c
// XXX this is broken: bind_param(1,1,{TYPE=>SQL_INTEGER});
if (attribs) {
if (sql_type)
croak ("Cannot specify both sql_type and pg_type");
if ((svp = hv_fetch((HV*)SvRV(attribs),"pg_type", 7, 0))==NULL)
croak("DBD::ChurlPg only knows about the pg_type attribute");
I wish we had a confess so we could actually trace the execution stack
closer.
Sure. How do I get a stack trace?
Anyone know what's going on?
A lot of what Recordset does depends on what driver you use. I don't
know what's going on but it might have to do with not knowing anything
about ChurlPg.
db48x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DBIx::Recordset 0.25 - ok for CPAN?
Well, I have made it back from my train trip and am ready to upload 0.25 to CPAN if there are no complaints about it. We can integrate Kee Hinckley's stuff into 0.26 when he gets back from his plane trips. Please test this before I upload it to CPAN: http://www.urth.org/~metaperl/DBIx-Recordset-0.25.tar.gz It was tested on MySQL, Postgres and SQLite only. I am taking a 4-day train trip tonight so I will not be able to respond to email until 5 or so days from now. It is checked into svn, so patches can be applied. NEW FUNCTIONALITY (Kee Hinckley, Cameron Prince, Terrence Brannon) * Full SQL Query input via the !Query option to Search() * added the '$makesql' flag to Search() so that generated SQL can be returned instead of executed. It will remain undocumented until it is supported for Update(), Delete(), and Insert(). It was added in order that the SQL generated for the test "Order, Group, Append" would pass on Postgres which finds the generated SQL invalid. BUGFIXES (Angus Lees, Terrence Brannon, Gerald Richter) * when building the FROM clause for LEFT JOINs Recordset placed parentheses around it, like this: SELECT dbixrs1.id,dbixrs1.name,dbixrs1.value1,dbixrs1.addon,dbixrs2.value2 FROM (dbixrs1 left join dbixrs2 on dbixrs1.id = dbixrs2.id) WHERE dbixrs1.id IN (2, 5, 10); but this caused a syntax error in sqlite, so a new leftjoin type of 4 was introduced to support LEFT JOIN with no parentheses around the join * Fixed a bug that cause TableAttr with value zero not to work correctly. Patch from Rene Seindal * Made sure that filters given by name override filters given by type. * Fixed PreFetchIfExpires() so that it works for a specified time period as well as for a CODE ref * Added support to DBIx::Compat so that the pseudo-type "counter" was converted to SERIAL when DBD::Pg is in use - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto disable embperl log?
At Thu, 11 Dec 2003 17:19:45 +0200, Michael Stepanov wrote:
> Thank you very much, Angus. I've found a place where defined
> default debug mode. This is a patch to the file embperl.h:
>
> --- /home/misha/tmp/orig/Embperl-2.0b9/embperl.h2003-02-15
> 22:46:31.0 +0200
> +++ /home/misha/tmp/Embperl-2.0b9/embperl.h 2003-12-11
> 16:05:05.0 +0200
> @@ -106,7 +106,7 @@
>
> enum dbg
> {
> -dbgStd = 1,
> +dbgStd = 0,
> dbgMem = 2,
> dbgEval= 4,
> dbgCmd = 8,
>
> When we rebuild Embperl again with this patch, debug mode will be ZERO.
> This is useful when Embperl is used in another modules:
Err, this only works because you've redefined what the default value
is set to (dbgStd) to 0, you haven't properly set the default value to
0 -- if that makes any sense. Basically, you are unable to set DEBUG
to dbgStd anymore, which is probably not good.
Try this patch instead:
--- epdefault.c.orig2003-12-13 14:10:41.0 +1100
+++ epdefault.c 2003-12-13 14:13:32.0 +1100
@@ -43,7 +43,7 @@
#else
pCfg -> sLog= "/tmp/embperl.log" ;
#endif
-pCfg -> bDebug = dbgStd ;
+pCfg -> bDebug = 0 ;
pCfg -> nMailErrorsResetTime = 60 ;
pCfg -> nMailErrorsResendTime = 60 * 15 ;
}
@@ -95,7 +95,7 @@
static void embperl_DefaultComponentConfig (/*in*/ tComponentConfig *pCfg)
{
-pCfg -> bDebug = dbgStd ;
+pCfg -> bDebug = 0 ;
/* pCfg -> bOptions = optRawInput | optAllFormData ; */
pCfg -> nEscMode = escStd ;
pCfg -> bCacheKeyOptions = ckoptDefault ;
--
- Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBIx::Recordset error message
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 decided to release the patch against DBD::Pg, I must have missed one. > Confusing. Anyway, does anyone have any idea how to fix it? It just > looks like DBIx::Recordset is generating an SQL statement that DBD::Pg > can't deal with. > It looks like you are passing a hashref into bind_param(), but not including the pg_type, so DBD::Pg is bailing because it no longer knows how to bind the placeholder. Rudy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBIx::Recordset error message
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 decided to release the patch against DBD::Pg, I must have missed one. Ah, ok. Confusing. Anyway, does anyone have any idea how to fix it? It just looks like DBIx::Recordset is generating an SQL statement that DBD::Pg can't deal with. It looks like you are passing a hashref into bind_param(), but not including the pg_type, so DBD::Pg is bailing because it no longer knows how to bind the placeholder. That makes sense. Any idea why DBIx::Recordset is doing that?. db48x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
