Re: [Patch] Minor Patch for DBD::ExampleP
Thanks. But when/why is $sth-{NAME_lc} undefined?
I suspect the right fix is to change $sth-{NAME_lc}
to $sth-FETCH('NAME_lc') to trigger the magic that
handled the _lc suffix. Could you try that for me?
Tim.
On Thu, Sep 11, 2003 at 08:15:28AM -0400, Thomas A. Lowery wrote:
Tim,
Here's a minor patch for DBD::ExampleP to fix:
https://rt.cpan.org/Ticket/Display.html?id=2192
Use of uninitialized value in array dereference at
/opt/perl_5.8.0/lib/sun4-solaris-thread-multi/DBD/ExampleP.pm line 360.
Tom
--- ExampleP.pm.orig 2003-09-11 07:41:25.0 -0400
+++ ExampleP.pm 2003-07-29 20:53:22.0 -0400
@@ -357,10 +357,15 @@
# In reality this would interrogate the database engine to
# either return dynamic values that cannot be precomputed
# or fetch and cache attribute values too expensive to prefetch.
+
if ($attrib eq 'TYPE'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::stattypes{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'PRECISION'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::statprec{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'ParamValues') {
Re: [Patch] Minor Patch for DBD::ExampleP
Yep it worked. Here's a new patch:
--- ExampleP.pm.orig2003-09-11 07:41:25.0 -0400
+++ ExampleP.pm 2003-09-11 22:28:13.0 -0400
@@ -358,10 +358,10 @@
# either return dynamic values that cannot be precomputed
# or fetch and cache attribute values too expensive to prefetch.
if ($attrib eq 'TYPE'){
- return [ @DBD::ExampleP::stattypes{ @{ $sth-{NAME_lc} } } ];
+ return [ @DBD::ExampleP::stattypes{ @{ $sth-FETCH(q{NAME_lc}) } } ];
}
elsif ($attrib eq 'PRECISION'){
- return [ @DBD::ExampleP::statprec{ @{ $sth-{NAME_lc} } } ];
+ return [ @DBD::ExampleP::statprec{ @{ $sth-FETCH(q{NAME_lc}) } } ];
}
elsif ($attrib eq 'ParamValues') {
my $dbd_param = $sth-{dbd_param} || [];
On Thu, Sep 11, 2003 at 05:11:32PM +0100, Tim Bunce wrote:
Thanks. But when/why is $sth-{NAME_lc} undefined?
I suspect the right fix is to change $sth-{NAME_lc}
to $sth-FETCH('NAME_lc') to trigger the magic that
handled the _lc suffix. Could you try that for me?
Tim.
On Thu, Sep 11, 2003 at 08:15:28AM -0400, Thomas A. Lowery wrote:
Tim,
Here's a minor patch for DBD::ExampleP to fix:
https://rt.cpan.org/Ticket/Display.html?id=2192
Use of uninitialized value in array dereference at
/opt/perl_5.8.0/lib/sun4-solaris-thread-multi/DBD/ExampleP.pm line 360.
Tom
--- ExampleP.pm.orig2003-09-11 07:41:25.0 -0400
+++ ExampleP.pm 2003-07-29 20:53:22.0 -0400
@@ -357,10 +357,15 @@
# In reality this would interrogate the database engine to
# either return dynamic values that cannot be precomputed
# or fetch and cache attribute values too expensive to prefetch.
+
if ($attrib eq 'TYPE'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::stattypes{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'PRECISION'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::statprec{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'ParamValues') {
Re: Problem connecting to non-default db
Hi,
Thanks, use dbA works. It doesn't work as part of a do statement (i.e. $dbh-
do(use dbA)), but it looks like it's working when I prep and execute use
dbA using a statement handle.
I'm using DBD::Sybase v1.01, so I guess there's still an issue with DBI only
connecting to the default db. I've cc'd dbi-dev since they might like to know
about this bug.
Thanks and take care,
Bilal
Quoting Chuck Fox [EMAIL PROTECTED]:
Bilal,
Try just executing use dbA after the connection is made. Another
option is to directly reference the db in the query by using select *
from dbA.dbo.array. A table can be referenced as tableName or
ownerName.tableName or as databaseName.ownerName.tableName. Insofar as
the bug, try ugrading to the latest dbd, I believe that 1.01 was just
released. We are using 1.0 and the issue with the db disappeared
there. I think the fix was in the 0.94 release.
Chuck
[EMAIL PROTECTED] wrote:
Hi,
Do you mean replace dbname=dbA with dbname=dbB in my connect string?
I've tried that. Is there another way to switch the data source to
another db?
Is there any fix for this DBD::Sybase bug?
Thanks,
Bilal
On Thu, 11 Sep 2003, Chuck Fox wrote:
[EMAIL PROTECTED] wrote:
Hi,
Hello,
I'm trying to connect to two ms sqlserver 2000 databases with the same
schema
(let's call them
dbA and dbB) using the following code:
my $connect_string = dbi:Sybase:dbname=dbA:server=MyServer;
$connect_string .= ;host=192.168.0.2;port=1433;
my $dbh = DBI-connect($connect_string, $username, $userpass, {PrintError
=
0});
die Unable for connect to server $DBI::errstr
unless $dbh;
and in my freetds.conf I have:
[MyServer]
host = 192.168.0.2
port = 1433
tds version = 4.2
try domain login = no
try server login = yes
I have read access to both dbA and dbB. However if dbB is my default db
and I
specify dbA as the dbname (as in the example above), or vice versa, when
my
script executes the following:
Why not just use dbB or whichever is appropriate to the query ? I
seem to remember some bug in Sybase DBD that prevented it from
using/processing the database specified in the connect string.
$sth = $dbh-prepare(select count(*) from array);
die Unable for connect to server $DBI::errstr unless $sth;
if($sth-execute) {
while(my @dat = $sth-fetchrow) {
print @dat\n;
}
}
the data is retrieved from the default db rather than the one I specified
(btw,
yes, i know for sure that the select count(*) from array on both db's
should
return different numbers). So I think that DBI's only connecting to the
default db.
As well, the statment
print Data sources: . ($dbh-data_sources()) . \n $DBI::errstr\n;
prints out no data sources.
The DBD I'm using is DBD::Sybase running on the freetds library. My
script's
running on a linux box and the sqlserver 2000 db's are on a windows 2000
adv
server box.
So any ideas on how I may get around this problem? I would really
appreciate
any help.
Thanks,
Take care,
Bilal
HTH,
Chuck Fox
Principal DBA
America Online, INC
DBD::Pg Release Candidate 1.31_5
Good day, DBD::Pg 1.31_5 is now on CPAN. The last(?) blocker was fixed by Jeremy Yoder, and Mark Stosberg was kind enough to bundle up this version. http://search.cpan.org/CPAN/authors/id/R/RU/RUDY/DBD-Pg-1.31_5.tar.gz Please try this version and report back to the list if you have any problems with it. If there are no problems this will probably become 1.31. Rudy Changes since 1.22: - Raised required versions to Perl 5.6.1 and DBI 1.35 - Fix syntax error related to pg_server_version (CPAN bugs #2492 and #27 55) - Cache multiple calls to pg_server_version. - Notice messages generated by the database now use the perl warning mechanism instead of going to stderr. [Dominic Mitchell [EMAIL PROTECTED]] - $dbh-prepare() rewrites the SQL statement into an internal for striping out comments and whitespace, and if PostgreSQL 7.3 ta kes the stripped statement and passes that to Postgres' PREPARE statemen t, then rewrites the statement as 'EXECUTE DBD::PG::cached_query n ($1, $2, ... $n, $n+1)' for DBD::Pg's execute. -- Currently disabled until PREPARE works a little better - Allows the use of :n and :foo bind params. So: (SELECT * FROM foo WHERE 1 = :this and 2 = :that) will now work. - Complains on execute when unbound bind params are submitted (instead of defaulting to NULL) - Switched over to use driver.xst. - pg_error() only removes \n's don't truncate message on first \n - Fixed statement scan problem where the preparse of SELECT foo[3:33] from bar was scanning :33 as a placeholder - Moved the quoting of bind values out of execute() and into bind -- as there is no need to requote the value every time exec ute is called. - :veryverylongplaceholdername == Long walk. Sort pier -- fixed. - quote() is now in C and uses same code as bind_param. - Quoting and dequoting now use libpq quoting functions where available (I still need to take the libpq functions swiped out of quote.c and move it into libpqswip.c with license info c., and switch ifndefs to ifdefs) - bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is PGBOOLOID. - Fixed many heap buffer overruns. - Added support for the get_info() method [Greg Sabino Mullane] - Added tests for POD validation [Mark Stosberg]
Re: What to do with UTF-8 data?
On Thu, Sep 11, 2003 at 08:29:50AM +0200, Jochen Wiedmann wrote: Hi, Steve, The problem is: How do I trap all input/output to/from DBI to do these conversions? I've asked about this on the dbi-users mailing list, and the answer (from Tim Bunce, no less) was that it is really the responsibility of the DBD driver to perform such conversions if the data in question is UTF-8. That's not quite right. I wasn't talking about any _conversions_ at all. after letting my thoughts settle I come to the conclusion that I do not agree completely. I think that DBI should do 80% of the job and leave about 20% to the driver authors. For a full solution yes, I agree - and I've written about this in the past. For now I'm just talking about the specific but fairly common situation of fetching data that is utf8 encoded but it doesn't get flagged as such by the driver. For that case the driver just needs to know when to do a SvUTF8_on(sv). Tim.
Re: What to do with UTF-8 data?
Tim Bunce wrote:
On Thu, Sep 11, 2003 at 08:29:50AM +0200, Jochen Wiedmann wrote:
Hi, Steve,
The problem is: How do I trap all input/output to/from DBI to do these
conversions?
I've asked about this on the dbi-users mailing list, and the answer
(from Tim Bunce, no less) was that it is really the responsibility of
the DBD driver to perform such conversions if the data in question is UTF-8.
That's not quite right. I wasn't talking about any _conversions_ at all.
I'm sorry if I mis-quoted you. I meant setting the UTF-8 flag on an
octet sequence that can be interpreted as UTF-8, rather than leaving it
unflagged and treated as Latin-1. Thus, the data is in some sense
converted from Latin-1 to UTF-8.
after letting my thoughts settle I come to the conclusion that I do not
agree completely. I think that DBI should do 80% of the job and leave
about 20% to the driver authors.
For a full solution yes, I agree - and I've written about this in the past.
For now I'm just talking about the specific but fairly common
situation of fetching data that is utf8 encoded but it doesn't
get flagged as such by the driver.
For that case the driver just needs to know when to do a SvUTF8_on(sv).
Exactly.
What about data going _into_ the database? In my examples of doing the
conversion manually with Encode::{en|de}code_utf8(), I was converting
the Perl strings to octet sequences that could later be interpreted as
UTF-8 before insertion into the database. That way I could guarantee
that all data retrieved from the database can be converted to UTF-8, in
fact (as you pointed out) by simply turning the UTF-8 flag on.
If all the data that I insert really is UTF-8 then I guess it will just
get serialised as a sequence of octets, and everything will be OK.
But what if the data I'm inserting isn't all UTF-8? The problem is:
1. Perl's internal format isn't just UTF-8 -- it defaults to Latin-1 (or
whatever) for strings in which every character can be represented in
Latin-1;
2. The 8-bit characters of Latin-1 are represented as two-byte
characters in UTF-8.
So, if I have the string Copyright © Fred Bloggs in Perl then it will
not be UTF-8: the © is stored as one byte, not two not, and the UTF-8
flag is off. If I insert that straight into the database without
running it through Encode::encode_utf8() first, then © itself, rather
than its two-byte UTF-8 representation gets stored in the database, so
when it gets retrieved from the database later you can't just turn the
UTF-8 flag on -- you would need to run it through Encode::decode_utf8().
In other words, just having the driver switching the UTF-8 on and off
will only work if I guarantee that all the strings I feed it to start
with really are UTF-8, even when Perl would not normally have
represented them as such.
It would be cool if something akin to binmode STDOUT, ':utf8'; could
be applied when sending data to the driver -- i.e. my data is in Perl's
internal format, whether that be Latin-1 or UTF-8 in the case of the
string at hand, and it all gets automagically upgraded to UTF-8 if
necessary before insertion into the database. Then you only need to
turn the flag on when retrieving it again.
At least, I think that's what I want :-s
- Steve
Re: What to do with UTF-8 data?
On Thu, 11 Sep 2003 12:31:52 +0100, Steve Hay wrote: It would be cool if something akin to binmode STDOUT, ':utf8'; could be applied when sending data to the driver -- i.e. my data is in Perl's internal format, whether that be Latin-1 or UTF-8 in the case of the string at hand, and it all gets automagically upgraded to UTF-8 if necessary before insertion into the database. Oh that's easy to achieve. Just concatenate the string with an UTF-8 string, and you'll get an UTF-8 string. Perl will do the upgrading for you. Just try it: $zero_length_utf8 = pack U0; # UTF8, length ==0 $string = élève; # Latin-1 $string .= $zero_length_utf8; # upgrade to UTF8 print $string; Now the reverse is much harder... :) -- Bart.
