DBIx::Recordset andLongNames error
I've run into an error with DBIx::Recordset and !LongNames. My query involves several tables: so_invoicebatch LEFT JOIN so_invoice USING (batchnr) LEFT JOIN so_orderhead ON (so_invoice.ordernr=so_orderhead.ordernr) LEFT JOIN co_custaddr_v USING (contact_id) LEFT JOIN co_country USING (country_id) and there are duplicated column names between the tables. So I turn !LongNames on, but then the values don't match the columns!! E.g. order total ends up as status! With LongNames turned off, the values match. I've tried both the CPAN version and 0.25 from Terence Brannon. I'd really like to be able to use table aliases, will this be in the future path for DBIx::Recordset ? Also, will the above query be updatable with DBIx::Recordset ? -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBIx::Recordset andLongNames error
Kaare Rasmussen wrote: I've run into an error with DBIx::Recordset and !LongNames. My query involves several tables: so_invoicebatch LEFT JOIN so_invoice USING (batchnr) LEFT JOIN so_orderhead ON (so_invoice.ordernr=so_orderhead.ordernr) LEFT JOIN co_custaddr_v USING (contact_id) LEFT JOIN co_country USING (country_id) Do you have the SQL that created these tables?. Do you have any sample data? Did you set $DBIx::Recordset::Debug to 4 and log the output? *DBIx::Recordset::LOG = \*LOG ; $DBIx::Recordset::Debug = 5 ; Are you using the new !Query method of inputting full SQL or are you !TabJoin or !TabRelation? Where is your code? Can I run it somehow? and there are duplicated column names between the tables. So I turn !LongNames on, but then the values don't match the columns!! E.g. order total ends up as status! With LongNames turned off, the values match. I've tried both the CPAN version and 0.25 from Terence Brannon. I'd really like to be able to use table aliases, will this be in the future path for DBIx::Recordset ? I think Angus Lees creates such a patch... I think I missed when upgrading Recordset though... Angus? Also, will the above query be updatable with DBIx::Recordset ? do you mean will recordset update across multiple tables? I can't remember. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBIx::Recordset andLongNames error
Hi > Can I run it somehow? I will compile a test case and send it to you. > I think Angus Lees creates such a patch... I think I missed when > upgrading Recordset though... Angus? This would add miles to the usability of DBIx::Recordset > do you mean will recordset update across multiple tables? I can't remember. Also this. Would be something of a dream, though I'm not sure its doable. -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBIx::Recordset andLongNames error
Kaare Rasmussen wrote: do you mean will recordset update across multiple tables? I can't remember. Also this. Would be something of a dream, though I'm not sure its doable. I think the big problem with doing something like this is that updates to multiple tables should be wrapped in a transaction. And I certainly don't think Recordset can do this at the moment.
Re: DBIx::Recordset : DBD::Pg 1.39 bind_param issues
On Sun, 28 Dec 2003, Terrence Brannon wrote:
> It looks like we are in some sort of (painful?) symbiotic relationship
> here. As I update my drivers to make sure that Recordset works before
> release, I keep having problems.
Looks like it. But hey, anything that finds bugs is a good thing, IMO.
> This time, I tried to do the following code which is part of Recordset:
>
> which shows two things about dbdimp.c in DBD::Pg's latest distro:
>
> (a) it should say DBD::Pg where it currently says DBD::ChurlPg:
That is my fault.
> /* // XXX this is broken: bind_param(1,1,{TYPE=>SQL_INTEGER}); */
My fault again.
> Any suggestions for fixing this are welcome!
>
How about a patch (subjoined). It is not as clean as I woould like, but
should take care of the problem while I work on cleaning up this section
of code.
Rudy
Index: dbdimp.c
===
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/dbdimp.c,v
retrieving revision 1.33
diff -u -r1.33 dbdimp.c
--- dbdimp.c21 Nov 2003 18:57:11 - 1.33
+++ dbdimp.c29 Dec 2003 20:41:50 -
@@ -739,7 +739,8 @@
char namebuf[30];
phs_t *phs;
sql_type_info_t *sql_type_info;
- int pg_type, bind_type;
+ int pg_type = 0;
+ int bind_type;
char *value_string;
STRLEN value_len;
@@ -789,38 +790,39 @@
}
- /* // 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");
-
- pg_type = SvIV(*svp);
-
-
+ if (attribs)
+ if((svp = hv_fetch((HV*)SvRV(attribs),"pg_type", 7, 0)) != NULL)
+ pg_type = SvIV(*svp);
+
+ if (sql_type && pg_type)
+ croak ("Cannot specify both sql_type and pg_type");
+
+
+ if (pg_type) {
if ((sql_type_info = pg_type_data(pg_type))) {
if (!sql_type_info->bind_ok) {
croak("Can't bind %s, pg_type %s not supported"
- "by DBD::ChurlPg",
- name,
sql_type_info->type_name);
+ "by DBD::Pg",
+ name, sql_type_info->type_name);
}
} else {
- croak("Cannot bind %s unknown sql_type %i", name,
sql_type);
+ croak("Cannot bind %s unknown pg_type %i",
+ name, pg_type);
}
bind_type = sql_type_info->type_id;
} else if (sql_type) {
if ((sql_type_info = sql_type_data(sql_type))) {
- /* always bind as pg_type, because we know we are inserting
-into a pg database... It would make no sense to quote
-something to sql semantics and break the insert.
- */
+ /* always bind as pg_type, because we know we are
+ inserting into a pg database... It would make no
+ sense to quote something to sql semantics and break
+ the insert.
+*/
bind_type = sql_type_info->type.pg;
} else {
- croak("Cannot bind %s unknown sql_type %i", name,
sql_type);
+ croak("Cannot bind %s unknown sql_type %i",
+ name, sql_type);
}
} else {
Index: t/03bind.t
===
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/t/03bind.t,v
retrieving revision 1.8
diff -u -r1.8 03bind.t
--- t/03bind.t 31 Oct 2003 16:45:34 - 1.8
+++ t/03bind.t 29 Dec 2003 20:41:50 -
@@ -1,9 +1,9 @@
use strict;
-use DBI;
+use DBI qw(:sql_types);
use Test::More;
if (defined $ENV{DBI_DSN}) {
-plan tests => 11;
+plan tests => 14;
} else {
plan skip_all => "DBI_DSN must be set: see the README file";
}
@@ -40,6 +40,10 @@
FROM dbd_pg_test
WHERE id = ?
AND name = ?
+ AND name = ?
+ AND name = ?
+ AND name = ?
+ AND name = ?
SQL
$sth = $dbh->prepare($sql);
ok(defined $sth,
@@ -55,6 +59,24 @@
ok($sth->bind_param(2, 'baz'),
'rebind string column with text'
);
+ok($sth->bind_param(3, 'baz', {TYPE=>SQL_VARCHAR}),
+ 'bind {TYPE=>SQL_VARCHAR}'
+ );
+
+eval {$sth->bind_param(4, 'baz', {TYPE=>SQL_VARCHAR, p
