$ora_errno Reset Problem
I am running into a problem where it appears as though the $ora_errno variable isn't being properly reset after encountering an error. What I am experiencing is that once $ora_errno and $ora_errstr is set, it stays set upon additional calls to ora_bind(). The following code produces the problem: --- code -- #!/usr/local/bin/perl use Oraperl; $DBH = ora_login(, userid/[EMAIL PROTECTED]); #--- -- #These values should be empty... print Error variables before doing anything...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #First query -- shouldn't produce an error and will return a result. $sql = select log_data from log_os where os_id = :1; $csr = ora_open($DBH, $sql); ora_bind($csr, '1'); ($value) = ora_fetch($csr); print \nValue from query 1: $value\n; print \nError variables after basic query 1...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Second query -- will produce an error (ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)) because #the bind variable isn't the correct type ora_bind($csr, 'a'); ($value) = ora_fetch($csr); print \nValue from query 2: $value\n; print \nError variables after basic query 2...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Third attempt -- shouldn't produce an error and will return a result. The problem, however, is that $ora_errno and $ora_errstr #still has the previous error AFTER the successful ora_bind() and $ora_fetch() call. ora_bind($csr, 2); ($value) = ora_fetch($csr); print \nValue from query 3: $value\n; print \nError variables after basic query 3...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; ora_close($csr); print Logoff of oracle\n; ora_logoff($DBH); print \n; -- end code -- Is this possibly an installation/configuration problem? Something else? The various versions are: Oraperl emulation interface version 1.43 DBD::Oracle 1.14 using OCI8 by Tim Bunce DBI 1.37 by Tim Bunce Perl v5.6.0 build for AIX AIX version 5 Thank you for your help. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify the HealthPartners Support Center by telephone at (952) 967-6600. You will be reimbursed for reasonable costs incurred in notifying us.
Re: $ora_errno Reset Problem
Try chaning these two lines in Oraperl.pm *Oraperl::ora_errno = \$DBD::Oracle::err; *Oraperl::ora_errstr = \$DBD::Oracle::errstr; to: *Oraperl::ora_errno = \$DBD::err; *Oraperl::ora_errstr = \$DBD::errstr; Tim. On Wed, Sep 10, 2003 at 02:00:28PM -0500, [EMAIL PROTECTED] wrote: I am running into a problem where it appears as though the $ora_errno variable isn't being properly reset after encountering an error. What I am experiencing is that once $ora_errno and $ora_errstr is set, it stays set upon additional calls to ora_bind(). The following code produces the problem: --- code -- #!/usr/local/bin/perl use Oraperl; $DBH = ora_login(, userid/[EMAIL PROTECTED]); #--- -- #These values should be empty... print Error variables before doing anything...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #First query -- shouldn't produce an error and will return a result. $sql = select log_data from log_os where os_id = :1; $csr = ora_open($DBH, $sql); ora_bind($csr, '1'); ($value) = ora_fetch($csr); print \nValue from query 1: $value\n; print \nError variables after basic query 1...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Second query -- will produce an error (ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)) because #the bind variable isn't the correct type ora_bind($csr, 'a'); ($value) = ora_fetch($csr); print \nValue from query 2: $value\n; print \nError variables after basic query 2...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Third attempt -- shouldn't produce an error and will return a result. The problem, however, is that $ora_errno and $ora_errstr #still has the previous error AFTER the successful ora_bind() and $ora_fetch() call. ora_bind($csr, 2); ($value) = ora_fetch($csr); print \nValue from query 3: $value\n; print \nError variables after basic query 3...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; ora_close($csr); print Logoff of oracle\n; ora_logoff($DBH); print \n; -- end code -- Is this possibly an installation/configuration problem? Something else? The various versions are: Oraperl emulation interface version 1.43 DBD::Oracle 1.14 using OCI8 by Tim Bunce DBI 1.37 by Tim Bunce Perl v5.6.0 build for AIX AIX version 5 Thank you for your help. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify the HealthPartners Support Center by telephone at (952) 967-6600. You will be reimbursed for reasonable costs incurred in notifying us.
get the messages, not the rows
Is there a way to execute an SQL command and get the messages, not
the records?
I mean, I'd like to run
DBCC CHECKDB ('databasename')
parse the output and add the result to a daily report of my servers'
health. The question is how do I get the messages.
I'm using DBI+DBD::ODBC and MS SQL Server 2000.
Thanks, Jenda
(And sorry if it's on line XX of the fine manual and I just did not
find it:)
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
Problem connecting to non-default db
Hi,
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:
$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
Re: get the messages, not the rows
If MSSQL Server hasn't diverged too far from being a derivative of Sybase, you
would trap those messages in an error or a message handler - but that only works
in sybperl and DBD::Sybase AFAIK. I don't know how you would get to the those
callbacks in ODBC.
HTH somewhat.
--
Matt
To: [EMAIL PROTECTED]
Jenda Krynicky cc:
[EMAIL PROTECTED] Subject: get the messages, not the rows
11 Sep 2003 10:37 AM
Is there a way to execute an SQL command and get the messages, not
the records?
I mean, I'd like to run
DBCC CHECKDB ('databasename')
parse the output and add the result to a daily report of my servers'
health. The question is how do I get the messages.
I'm using DBI+DBD::ODBC and MS SQL Server 2000.
Thanks, Jenda
(And sorry if it's on line XX of the fine manual and I just did not
find it:)
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
RE: [dbi] Problem connecting to non-default db
I haven't tried it in a long time (other than running make test) but from
perldoc DBD::ODBC:
odbc_async_exec
Allow asynchronous execution of queries. Right now,
this causes a spin-loop (with a small sleep) until
the sql is complete. This is useful, however, if you
want the error handling and asynchronous messages (see
the err_handler) below. See t/20SQLServer.t for an
example of this.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
On 11-Sep-2003 [EMAIL PROTECTED] wrote:
Hi,
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:
$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
Re: get the messages, not the rows
From: [EMAIL PROTECTED]
If MSSQL Server hasn't diverged too far from being a derivative of
Sybase, you would trap those messages in an error or a message handler
- but that only works in sybperl and DBD::Sybase AFAIK. I don't know
how you would get to the those callbacks in ODBC. HTH somewhat. --
Matt
I tried to get them from the errors but they do not seem to be there.
This is what I tried:
use DBI;
my $db = DBI-connect('dbi:ODBC:jobodbc2', '', 'xxx',
{PrintError = 0,RaiseError = 1,LongReadLen = 65536});
my $rows = $db-do(q{DBCC CHECKDB ('jobviper')});
$db-disconnect();
print ROWS: $rows\n;
print ERROR: .$db-errstr.\n;
No exception raised, nothing in errstr :-(
Jenda
Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
RE: [dbi] Problem connecting to non-default db
Hi,
I'm not trying to connect to the 2 db's at the same time, so I'm not sure
what you mean.
What I'm doing is executing the script for the 1st; editing it so that
the dbname parameter in the connect string is for the other 2nd; running
the script again.
The problem is that it's only connecting to whichever is the default db
every time.
Bilal
On Thu, 11 Sep 2003, Martin J. Evans wrote:
I haven't tried it in a long time (other than running make test) but from
perldoc DBD::ODBC:
odbc_async_exec
Allow asynchronous execution of queries. Right now,
this causes a spin-loop (with a small sleep) until
the sql is complete. This is useful, however, if you
want the error handling and asynchronous messages (see
the err_handler) below. See t/20SQLServer.t for an
example of this.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
On 11-Sep-2003 [EMAIL PROTECTED] wrote:
Hi,
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:
$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
RE: [dbi] Problem connecting to non-default db
On 11-Sep-2003 [EMAIL PROTECTED] wrote: Hi, I'm not trying to connect to the 2 db's at the same time, so I'm not sure what you mean. Appologies, I clicked reply on the wrong message. My reply was for Jenda Krynicky. Sorry about that. -- Martin J. Evans Easysoft Ltd, UK Development
Re: Problem connecting to non-default db
[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
Re: Problem connecting to non-default db
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
Re: Problem connecting to non-default db
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
Re: Entering data in Postgres bytea field
On Tue, 9 Sep 2003, Zhivko Duchev wrote: Hello all, I'm trying to load a large amount of binary data in bytea field in Postgre table using perl. The problem is that the only way I've managed to do it was by using placeholders and binding like this: $statement=Insert into pic1 (pic,type) values(?,'eps2'); $sth=$dbh-prepare($statement); $sth-bind_param(1, $md,SQL_QUERY ) || die $dbh-errstr; Is there any generic way to write this statement in the usual way : INSERT INTO table (col1,col2,...) VALUES (val1,val2,...). Placeholders are the standard way of inserting data into a database. I'm using Perl5.6.1 ;DBI 1.21 ;DBD:Pg 1.01; PostgreSQL 7.2.1 on Debian Linux mashine Your DBD::Pg is quite old and has some possible bufer overruns in quoting of bytea data, so you might want to upgrade. Rudy
Re: Help with install????
On Tue, 9 Sep 2003, Badinter, George wrote: I am trying to get perl mysql going and this is the error message I get : dbimon mysql:test:localhost ld.so.1: /usr/local/bin/perl: fatal: relocation error: file /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/DBD/mysql/mysql.so: symbol mysql_init: referenced symbol not found Killed Any ideas? Are Perl and the mysql client library both compiled with either 32 or 64 bits and is your mysql client library in a directory that is searched when doing the dynamic linking (LD_LIBRARY_PATH on linux?) Rudy
RE: [dbi] get the messages, not the rows
From: Martin J. Evans [EMAIL PROTECTED]
I haven't tried it in a long time (other than running make test) but
from perldoc DBD::ODBC:
odbc_async_exec
Allow asynchronous execution of queries. Right now,
this causes a spin-loop (with a small sleep) until
the sql is complete. This is useful, however, if you
want the error handling and asynchronous messages (see the
err_handler) below. See t/20SQLServer.t for an example of
this.
Swet. It works:
use DBI;
my $text = '';
my $dbh = DBI-connect('dbi:ODBC:jobodbc2', 'TMPJOBVIPERADMIN',
'jobviper',
{PrintError = 0,RaiseError = 1,LongReadLen = 65536,
odbc_async_exec = 1,
odbc_err_handler = sub {
my ($state, $msg) = @_;
# Strip out all of the driver ID stuff
$msg =~ s/^(\[[\w\s]*\])+//;
$text .= $msg.\n;
return 0;
}
});
$sth = $dbh-prepare(dbcc CHECKDB ('jobviper'));
$sth-execute;
print $text;
$dbh-disconnect();
It seems that the -prepare() and -execute() is necessary, it
doesn't work with -do().
Thanks, Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
DBD Informix Install Question
I am having trouble installing the DBD::Informix (version 2003.04). I have installed a 64 bit perl and the DB1 1.35. Here is the specs: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=solaris, osvers=2.9, archname=sun4-solaris uname='sunos carbon01 5.9 generic_112233-06 sun4u sparc sunw,sun-fire-880 ' config_args='-Dcc=gcc -des -Duse64bitall -Aldflags=-mcpu=v9 -m64 -Alddlflags =-mcpu=v9 -m64 -G' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=unde f useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -D_LARG EFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -mcpu=v9 -m64 -Wa ,-xarch=v9 -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='3.2.3', gccosandvers='solaris2.9' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize =8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -mcpu=v9 -m64 -L/usr/local/lib -L/usr/lib/sparcv9 -mcp u=v9 -m64' libpth=/usr/local/lib /usr/lib/sparcv9 /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/usr/lib/sparcv9/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -L/usr/lib/sparcv9 -mcpu= v9 -m64 -G' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES Built under solaris Compiled at Sep 11 2003 07:51:58 @INC: /usr/local/lib/perl5/5.8.0/sun4-solaris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . Prior to doing the Makefile.PL I have set the ENV vars: DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX=^-xarch=(sparc)?v9$ AND INFORMIXC=gcc -m64 but I am still getting errors when doing the perl Makefile.pl. Below is the output and errors: Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) ( aka DBD::Informix) You are using DBI version 1.35 and Perl version 5.008 Remember to actually read the README file! Perl: perl5.008 sun4-solaris dl_dlopen.xs System: sunos carbon01 5.9 generic_112233-06 sun4u sparc sunw,sun-fire-880 Compiler: gcc -O -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -D_LARGEFILE_S OURCE -D_FILE_OFFSET_BITS=64 Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.FC1 from /i nformix-sparc_prod_ctrl1_1 Beware: DBD::Informix is not yet aware of all the new IUS data types. Assert macro will be disabled! lib/DBD/Informix/Defaults.pm written OK esqlvrsn.h written OK esqlinfo.h written OK Testing whether your Informix test environment will work... # DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX set. # Removing options that match regex m%^-xarch=(sparc)?v9$% # DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX set. # Removing options that match regex m%^-xarch=(sparc)?v9$% # DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX set. # Removing options that match regex m%^-xarch=(sparc)?v9$% ld: fatal: file esqltest.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to esqltest collect2: ld returned 1 exit status Failed to link test program esqltest Does anyone have any suggestions? Thanks
Re: $ora_errno Reset Problem
Unfortunately this doesn't appear to have done the trick as I am seeing the same behavior as before. Do you have any other suggestions of things to try? Tim Bunce [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Try chaning these two lines in Oraperl.pm *Oraperl::ora_errno = \$DBD::Oracle::err; *Oraperl::ora_errstr = \$DBD::Oracle::errstr; to: *Oraperl::ora_errno = \$DBD::err; *Oraperl::ora_errstr = \$DBD::errstr; Tim. On Wed, Sep 10, 2003 at 02:00:28PM -0500, [EMAIL PROTECTED] wrote: I am running into a problem where it appears as though the $ora_errno variable isn't being properly reset after encountering an error. What I am experiencing is that once $ora_errno and $ora_errstr is set, it stays set upon additional calls to ora_bind(). The following code produces the problem: --- code -- #!/usr/local/bin/perl use Oraperl; $DBH = ora_login(, userid/[EMAIL PROTECTED]); #--- -- #These values should be empty... print Error variables before doing anything...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #First query -- shouldn't produce an error and will return a result. $sql = select log_data from log_os where os_id = :1; $csr = ora_open($DBH, $sql); ora_bind($csr, '1'); ($value) = ora_fetch($csr); print \nValue from query 1: $value\n; print \nError variables after basic query 1...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Second query -- will produce an error (ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)) because #the bind variable isn't the correct type ora_bind($csr, 'a'); ($value) = ora_fetch($csr); print \nValue from query 2: $value\n; print \nError variables after basic query 2...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Third attempt -- shouldn't produce an error and will return a result. The problem, however, is that $ora_errno and $ora_errstr #still has the previous error AFTER the successful ora_bind() and $ora_fetch() call. ora_bind($csr, 2); ($value) = ora_fetch($csr); print \nValue from query 3: $value\n; print \nError variables after basic query 3...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; ora_close($csr); print Logoff of oracle\n; ora_logoff($DBH); print \n; -- end code -- Is this possibly an installation/configuration problem? Something else? The various versions are: Oraperl emulation interface version 1.43 DBD::Oracle 1.14 using OCI8 by Tim Bunce DBI 1.37 by Tim Bunce Perl v5.6.0 build for AIX AIX version 5 Thank you for your help. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify the HealthPartners Support Center by telephone at (952) 967-6600. You will be reimbursed for reasonable costs incurred in notifying us.
RE: [dbi] get the messages, not the rows
On 11-Sep-2003 Jenda Krynicky wrote:
From: Martin J. Evans [EMAIL PROTECTED]
I haven't tried it in a long time (other than running make test) but
from perldoc DBD::ODBC:
odbc_async_exec
Allow asynchronous execution of queries. Right now,
this causes a spin-loop (with a small sleep) until
the sql is complete. This is useful, however, if you
want the error handling and asynchronous messages (see the
err_handler) below. See t/20SQLServer.t for an example of
this.
Swet. It works:
use DBI;
my $text = '';
my $dbh = DBI-connect('dbi:ODBC:jobodbc2', 'TMPJOBVIPERADMIN',
'jobviper',
{PrintError = 0,RaiseError = 1,LongReadLen = 65536,
odbc_async_exec = 1,
odbc_err_handler = sub {
my ($state, $msg) = @_;
# Strip out all of the driver ID stuff
$msg =~ s/^(\[[\w\s]*\])+//;
$text .= $msg.\n;
return 0;
}
});
$sth = $dbh-prepare(dbcc CHECKDB ('jobviper'));
$sth-execute;
print $text;
$dbh-disconnect();
It seems that the -prepare() and -execute() is necessary, it
doesn't work with -do().
It won't work with do() because do is for non-result-set generating SQL like
inserts etc and doesn't do the asynchronous stuff . Glad you have it working OK
though.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
Problems with make on unix
Title: Problems with make on unix # perl Makefile.PL Using DBI 1.38 installed in /usr/local/ActivePerl-5.8/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBI Configuring DBD::Oracle ... Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /u01/app/oracle/product/9.2.0 Oracle version 9.2.0.0.0 Found header files in rdbms/public rdbms/demo. Found /u01/app/oracle/product/9.2.0/rdbms/demo/demo_rdbms.mk Found /u01/app/oracle/product/9.2.0/otrace/demo/atmoci.mk Found /u01/app/oracle/product/9.2.0/precomp/demo/proc/demo_proc.mk Using /u01/app/oracle/product/9.2.0/rdbms/demo/demo_rdbms.mk Reading /u01/app/oracle/product/9.2.0/rdbms/demo/demo_rdbms.mk Reading /u01/app/oracle/product/9.2.0/rdbms/lib/env_rdbms.mk Deleting ORA_NLS = $(ORACLE_HOME)/ocommon/nls/admin/data/ because it is not already set in the environment and it can cause ORA-01019 errors. Deleting ORA_NLS33 = $(ORACLE_HOME)/ocommon/nls/admin/data/ because it is not already set in the environment and it can cause ORA-01019 errors. Attempting to discover Oracle OCI build rules gcc -c -I/u01/app/oracle/product/9.2.0/rdbms/demo -I/u01/app/oracle/product/9.2.0/rdbms/public -I/u01/app/oracle/product/9.2.0/plsql/public -I/u01/app/oracle/product/9.2.0/network/public -I/u01/app/oracle/product/9.2.0/rdbms/demo -I/u01/app/oracle/product/9.2.0/rdbms/public -I/u01/app/oracle/product/9.2.0/rdbms/demo -I/usr/local/ActivePerl-5.8/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBI -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.14\ -DXS_VERSION=\1.14\ -fPIC -I/usr/local/ActivePerl-5.8/lib/5.8.0/sun4-solaris-thread-multi/CORE -DUTF8_SUPPORT DBD_ORA_OBJ.c by executing: (make -f /u01/app/oracle/product/9.2.0/rdbms/demo/demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=echo OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o) Oracle oci build command: + -L/opt/SUNWcluster/lib -R/opt/SUNWcluster/lib -o build -L/u01/app/oracle/product/9.2.0/rdbms/lib/ -L/u01/app/oracle/product/9.2.0/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -lnbeq9 -lnhost9 -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 -lnnis9 -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 -lnsl -lsocket -lgen -ldl -R/u01/app/oracle/product/9.2.0/lib -laio -lposix4 -lkstat -lm -lthread System: perl5.008 sunos sparky 5.6 generic_105181-26 sun4u sparc sunw,ultra-5_10 Compiler: gcc -O -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/ccs/bin/ld Sysliblist: -lnsl -lsocket -lgen -ldl Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -xO3 $(CDEBUG) -Xa $(PROFILE) -xstrconst -dalign -xF $(XS) $(MR) -xildoff -errtags=yes -v -xarch=v9 -xchip=ultra3 -W2,-AKNR_S -Wd,-xsafe=unboundsym -Wc,-Qiselect-funcalign=32 -xcode=abs44 -Wc,-Qgsched-trace_late=1 -Wc,-Qgsched-T5 -xalias_level=weak -D_REENTRANT -DSS_64BIT_SERVER -DBIT64 -DMACHINE64 -K PIC -I/u01/app/oracle/product/9.2.0/rdbms/demo -I/u01/app/oracle/product/9.2.0/rdbms/public -I/u01/app/oracle/product/9.2.0/plsql/public -I/u01/app/oracle/product/9.2.0/network/public -DSLMXMX_ENABLE -DSLTS_ENABLE -D_SVID_GETTOD -D_REENTRANT $(LPFLAGS) $(USRFLAGS)] LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) [-o $@ -L/u01/app/oracle/product/9.2.0/rdbms/lib/ -L$(LIBHOME)] Linking with OTHERLDFLAGS = -L/opt/SUNWcluster/lib -R/opt/SUNWcluster/lib -o build -L/u01/app/oracle/product/9.2.0/rdbms/lib/ -L/u01/app/oracle/product/9.2.0/lib/ -lclntsh -lnbeq9 -lnhost9 -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 -lnnis9 -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 -lnsl -lsocket -lgen -ldl -R/u01/app/oracle/product/9.2.0/lib -laio -lposix4 -lkstat -lm -lthread [from 'build' rule] Argument 9.200.0.0 isn't numeric in numeric ge (=) at Makefile.PL line 669. LD_RUN_PATH=/u01/app/oracle/product/9.2.0/lib:/u01/app/oracle/product/9.2.0/rdbms/lib Using DBD::Oracle 1.14. Using DBD::Oracle 1.14. Using DBI 1.38 installed in /usr/local/ActivePerl-5.8/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBI Writing Makefile for DBD::Oracle *** If you have problems... read all the log printed above, and the README and README.help files. (Of course, you have read README by now anyway, haven't you?) # make Skip blib/lib/DBD/Oracle.pm (unchanged) Skip blib/arch/auto/DBD/Oracle/Oracle.h (unchanged) Skip blib/arch/auto/DBD/Oracle/dbdimp.h (unchanged) Skip blib/lib/oraperl.ph (unchanged) Skip blib/arch/auto/DBD/Oracle/ocitrace.h (unchanged) Skip blib/lib/Oraperl.pm (unchanged) Skip blib/arch/auto/DBD/Oracle/mk.pm (unchanged) Skip blib/lib/DBD/Oracle/GetInfo.pm (unchanged) /usr/local/ActivePerl-5.8/bin/perl -p -e s/~DRIVER~/Oracle/g
Licence expired for DBI module
could you pls clarify i am getting this error while installing DBI module. cc -c -xO3 -xdepend-DVERSION=\1.32\ -DXS_VERSION=\1.32\ -KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE -DDBI_NO_THREADS Perl.c , license error: Notice: The 60-day trial serial number has expired. In order to purchase the product, visit http://www.sun.com/forte/buy.html or contact your Forte Tools reseller. cc: acomp failed for Perl.c make: *** [Perl.o] Error 2 Thanks Jiten
Re: Licence expired for DBI module
On Thu, 11 Sep 2003 15:48:28 -0400 Vasanthu, Jitendra [EMAIL PROTECTED] wrote: could you pls clarify i am getting this error while installing DBI module. cc -c -xO3 -xdepend-DVERSION=\1.32\ -DXS_VERSION=\1.32\ -KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE -DDBI_NO_THREADS Perl.c , license error: Notice: The 60-day trial serial number has expired. In order to purchase the product, visit http://www.sun.com/forte/buy.html or contact your Forte Tools reseller. cc: acomp failed for Perl.c make: *** [Perl.o] Error 2 The error is just what is says, the 60-day trial license for the tool set that includes 'cc' has expired. It has nothing to do with DBI. -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: $ora_errno Reset Problem
Can you produce a small test script that shows ora_errno not being reset but $DBD::err being reset? Tim. On Thu, Sep 11, 2003 at 02:59:27PM -0500, David Deemer wrote: Unfortunately this doesn't appear to have done the trick as I am seeing the same behavior as before. Do you have any other suggestions of things to try? Tim Bunce [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Try chaning these two lines in Oraperl.pm *Oraperl::ora_errno = \$DBD::Oracle::err; *Oraperl::ora_errstr = \$DBD::Oracle::errstr; to: *Oraperl::ora_errno = \$DBD::err; *Oraperl::ora_errstr = \$DBD::errstr; Tim. On Wed, Sep 10, 2003 at 02:00:28PM -0500, [EMAIL PROTECTED] wrote: I am running into a problem where it appears as though the $ora_errno variable isn't being properly reset after encountering an error. What I am experiencing is that once $ora_errno and $ora_errstr is set, it stays set upon additional calls to ora_bind(). The following code produces the problem: --- code -- #!/usr/local/bin/perl use Oraperl; $DBH = ora_login(, userid/[EMAIL PROTECTED]); #--- -- #These values should be empty... print Error variables before doing anything...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #First query -- shouldn't produce an error and will return a result. $sql = select log_data from log_os where os_id = :1; $csr = ora_open($DBH, $sql); ora_bind($csr, '1'); ($value) = ora_fetch($csr); print \nValue from query 1: $value\n; print \nError variables after basic query 1...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Second query -- will produce an error (ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)) because #the bind variable isn't the correct type ora_bind($csr, 'a'); ($value) = ora_fetch($csr); print \nValue from query 2: $value\n; print \nError variables after basic query 2...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; #--- --- #Third attempt -- shouldn't produce an error and will return a result. The problem, however, is that $ora_errno and $ora_errstr #still has the previous error AFTER the successful ora_bind() and $ora_fetch() call. ora_bind($csr, 2); ($value) = ora_fetch($csr); print \nValue from query 3: $value\n; print \nError variables after basic query 3...\n; print Error code: $ora_errno\n; print Error text: $ora_errstr\n; ora_close($csr); print Logoff of oracle\n; ora_logoff($DBH); print \n; -- end code -- Is this possibly an installation/configuration problem? Something else? The various versions are: Oraperl emulation interface version 1.43 DBD::Oracle 1.14 using OCI8 by Tim Bunce DBI 1.37 by Tim Bunce Perl v5.6.0 build for AIX AIX version 5 Thank you for your help. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify the HealthPartners Support Center by telephone at (952) 967-6600. You will be reimbursed for reasonable costs incurred in notifying us.
Re: Problem connecting to non-default db
On Thu, 2003-09-11 at 11:32, [EMAIL PROTECTED] wrote: 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. If the do() doesn't work it's probably because you already have an active statement handle for that $dbh, and DBD::Sybase will open a second connection in that situation. 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. I know that setting the database this way works when using the Sybase libraries. I suggest that you run your script with DBI-trace(3) and send me (not the list) the output from that trace. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.mbay.net/~mpeppler Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.mbay.net/~mpeppler/resume.html
Re: Licence expired for DBI module
On Thu, 11 Sep 2003 15:48:28 -0400, Vasanthu, Jitendra wrote: could you pls clarify i am getting this error while installing DBI module. cc -c -xO3 -xdepend -DVERSION=\1.32\ -DXS_VERSION=\1.32\ - KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE -DDBI_NO_THREADS Perl.c , license error: Notice: The 60-day trial serial number has expired. In order to purchase the product, visit http://www.sun.com/forte/buy.html or contact your Forte Tools reseller. cc: acomp failed for Perl.c make: *** [Perl.o] Error 2 It's the cc compiler that's expired, not Perl. Thanks Jiten -- Matthew O. Persico
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: 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
Re: What to do with UTF-8 data?
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. 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. It is right, that the driver author possibly knows how to detect the encoding of columns in the database. However, this is *only* possibly, because doing a SHOW COLUMNS FROM mytable with any prepare statement is not an option, IMO. There has to be at least a possibility to say this column is encoded in ISO-8859-1, but please be so kind to convert into the UTF-8 which we are using in nowadays Perl. Whether MySQL 4.1 does return such flag or not, doesn't matter: The driver still has to work with elder versions, where encoding matters quite the same. IMO a good approach would go like follows: - DBI's got to know about encodings. It is the task of the generic layer to decide on the character encoding of the input data, aka SQL statements and placeholder values. In short: DBI must decide on What is input data and how is it encoded? - DBI should also know about the *desired* encodings of input data. Of course, it would be nice, if driver authors can provide the ability to determine these value automatically. However, IMO the DBI user should be able to override. Also, we should not forget that people may use binary columns to store text data, in which case the driver author will never be able to give suitable information. - Based on the above facts, DBI would be able to decide that we need to convert from encoding1 to encoding2. If they are the same, DBI could suppress the following. Otherwise DBI could invoke a method doing the conversion. That method ought to be overridable by the driver author. And it ought to be implementable in Perl or C. - Likewise for the output. In short: Let DBI decide when to convert. And give it suitable hooks that allow the driver authors to provide information. Jochen
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.
