Quantcast
Channel: perl.dbi.users
Viewing all 225 articles
Browse latest View live

SQL-Statement 1.406_001 dev-release out for testing (1 message)

$
0
0
Hi,

I recently uploaded a dev-release of SQL-Statement (1.406_001) because of so many (partially exciting patches from community).
I hereby kindly ask anybody who's using it to test it whether it works as expected or not.

I'm looking forward to release 1.407 at begin of next week when no regressions are introduced.

Cheers
--
Jens Rehsack - rehsack@gmail.com


Released SQL::Statement 1.407 (1 message)

$
0
0
Hi,

it was silent around SQL::Statement for a long time ...

I uploaded a new release fixing some open bugs this morning. Special thanks is going out to Slaven Rezic for supporting by running tests.

Changes log for Perl extension SQL::Statement

1.407 2015-05-26
* Release 1.406_002 without further changes as 1.407

1.406_002 2015-05-22
[Bug fixes]
* Fix RT#104579: Redundant argument in sprintf
submitted by Slaven Rezić
* Fix RT#104589: t/14parse.t fails if Test::Deep is not installed
submitted by Slaven Rezić

1.406_001 2015-05-20
[Misc]
* clean up Makefile.PL, meta-data and requirements

[Bug fixes]
* Fix SQL function CONV to use limited number of sane character sets
for conversion and rely on Math::Base::Convert instead of own code
(suggested by Tom Wyant in RT#100551, thanks Tom)
* fix handling of literal identifiers and for every IMPORT rely on
literal identifiers to avoid parser errors for column names starting
with numbers or similar
* fix capability cache: "$class->can(...)" might return undef and
therefore inexistent capabilities are queried to often
* Fix COUNT(DISTINCT col) without GROUP BY clause (patch submitted
by Grant Mathews, thanks Grant)
* Fix "parse insert with functions" submitted via GitHub PR#6 by
fecundf and RT#96628
* Fix RT#93320: SQL-style comment can not begin inside quotes by
Tom Wyant - thanks Tom

[Improvements]
* reduce blocks and rewrite some inner statements to increase speed
of sql command processing

Best regards
--
Jens Rehsack - rehsack@gmail.com

Potential dbi memory leak. (9 messages)

$
0
0
Hi Guys,

You may have seen part of this post on PerlMonks. If so apologies for
the duplication. This started off as a general search for leaks in my
code, and resulted in a few hits, one of which was attached to every
database access.

A simple "select ATT_RECORD_NAME_TXT from TBL_TEST; " results in the
leak of one scalar value. It seems to be attached to the ->prepare
statement.

At first I assumed it was down to my Firebird driver, which is
relatively new, so I switched the driver to ODBC::Firebird, with the
same result. Finally I changed to mysql and again got a memory leak.
The only thing I can assume is that either my code is generically wrong
(and I hope this is the case), or there is a leak in dbi, which I would
be surprised by.

I would appreciate some advice.

Test code follows. Please install Devel::Leak to pick up leaked scalars
and update the dsn to the dsn of your choice.

Thanks for your help.

Regards,

Steve.

#! /usr/bin/perl

package main;
use strict;
use warnings;
use DBI;
#use DBD::Firebird;
use DBD::ODBC;
use Devel::Leak;
my $handle;
my $count_start;
my $count_stop;
my $gl_dbh;

# Just do this 5 times to make sure there is no contribution to
$handle count from Devel::Leak
for (1..10){
print "Handle init: ", Devel::Leak::NoteSV($Launch::handle),"\n";
}
#my $loc_dsn = <<DSN;
#dbi:ODBC:Driver=Firebird;Dbname=/home/image/Documents/Endoscopia/DB/newEndo.fdb;
#ib_dialect=3;
#DSN
my $loc_dsn = <<DSN;
DBI:mysql:database=new_schema_test;
host=localhost;
port=3306";
DSN
$Launch::gl_dbh=DBI->connect($loc_dsn,"root","password", {
PrintError => 1, # Report errors via warn
RaiseError => 1 # Report errors via Die
}
) or die;

my @loc_sql_string =();
$loc_sql_string[0]="CREATE TABLE TBL_TEST_LEAK ( ATTR_RECORD_ID_TXT
VARCHAR(10) NOT NULL, ATT_RECORD_NAME_TXT VARCHAR(255), CONSTRAINT
PK_TBL_TEST_LEAK PRIMARY KEY (ATTR_RECORD_ID_TXT) ); ";
$loc_sql_string[1]="GRANT DELETE, INSERT, REFERENCES, SELECT,
UPDATE ON TBL_TEST_LEAK TO SYSDBA WITH GRANT OPTION";
$loc_sql_string[2]="INSERT INTO TBL_TEST_LEAK (ATTR_RECORD_ID_TXT,
ATT_RECORD_NAME_TXT) VALUES ('206', 'Delay Test 1' )";
$loc_sql_string[3]="select ATT_RECORD_NAME_TXT from TBL_TEST_LEAK; ";
$loc_sql_string[4]= $loc_sql_string[3];
$loc_sql_string[5]= $loc_sql_string[3];
$loc_sql_string[6]= $loc_sql_string[3];
$loc_sql_string[7]= $loc_sql_string[3];
$loc_sql_string[8]= $loc_sql_string[3];
$loc_sql_string[9]="drop table TBL_TEST_LEAK; ";

for (my $i=1;$i<=9;$i++){
$count_start=Devel::Leak::NoteSV($Launch::handle);
print "DBD start: ", $count_start,"\n";
print $loc_sql_string[$i], "\n";
dbd_select($loc_sql_string[$i]);
# You can use
#$count_stop=Devel::Leak::CheckSV($Launch::handle);
$count_stop=Devel::Leak::NoteSV($Launch::handle);
print "Handle stop: ", $count_stop,"\n";
print "Count difference: ", $count_stop-$count_start,"\n";
}
$Launch::gl_dbh->disconnect;

sub dbd_select{
my $loc_sql_string=shift;
my $loc_sth=$Launch::gl_dbh->prepare($loc_sql_string) or die;
#$loc_sth->execute() or die;
#$loc_sth->finish();
return;
}

1;


help with odd DBI perpare/execute errors (25 messages)

$
0
0
Environment Perl script trying to query Oracle 11g database:

FreeBSD 9.3-STABLE

DBI 1.633

oracle8-client 0.2.0

DBD::Oracle 1.19

I have no trouble connecting with the Oracle database. And I do
recover data when I use the temporary workaround described below.

I have a query/prepare setup outside a foreach loop where I execute()
the prepared query something like this, only more complex:

my $query = "select column from table where column = ?";

my $sth = $dbh->prepare ($query);

foreach ()
{
$sth->execute($value);
}

I was getting invalid string ORA-0911 errors at the question mark.
I then replaced the question mark with a number (555) and made the
execute() call just "$sth->execute();"

This worked. But I really needed to bind to the $value variable
in the foreach loop.

In reading the DBI POD it said for Oracle the "?" is turned into
":p1" (in this case). So I replaced the question mark with :p1.

The prepare statement no longer generated an error, instead the
execute statement generated the error:

DBD::Oracle::st execute failed: called with 1 bind variables
when 0 are needed [for Statement ... ] at script.pl line xxx.

Can any one help me figure out this confusing situation? BTW, I
have been using Perl for twenty years and DBI for perhaps ten,
and I have used this query/prepare/bind/execute methodology in
the past with success. Something is different, but I don't know
what to look for.

Regards,

web...

--

/"\ ASCII RIBBON / William Bulley
\ / CAMPAIGN AGAINST /
X HTML E-MAIL AND / E-MAIL: web@umich.edu
/ \ LISTSERV POSTINGS /

72 characters width template ----------------------------------------->|

FW: DBD:Pg problems (2 messages)

Please test DBI-1.633_91 - recently uploaded to CPAN (1 message)

$
0
0
I've uploaded DBI-1.633_91 to CPAN.

It contains a couple of experimental changes I'd like feedback on:
https://metacpan.org/changes/release/TIMB/DBI-1.633_91

Enabled strictures on all modules (Jose Luis Perez Diez) #22
Note that this might cause new exceptions in existing code.
Please take time for extra testing before deploying to production.

Improve handling of row count on 32bit int systems, add sanity check warn
Relevant if "perl -V:'i(nt|v)size'" reports different sizes
and either you execute statements that might affect >=2,147,483,648 rows.

Please build it, install it, test it, and let us know how it goes.

cpanm https://cpan.metacpan.org/authors/id/T/TI/TIMB/DBI-1.633_91.tar.gz

Thanks!

Tim.

Announce: DBI 1.634 (1 message)

$
0
0
file: $CPAN/authors/id/T/TI/TIMB/DBI-1.634.tar.gz
size: 595020 bytes
md5: 4ad15a9c2cc9b68e3fe1f5cadf9cdb30

=head2 Changes in DBI 1.634 - 3rd August 2015

Enabled strictures on all modules (Jose Luis Perez Diez) #22
Note that this might cause new exceptions in existing code.
Please take time for extra testing before deploying to production.
Improved handling of row counts for compiled drivers and enable them to
return larger row counts (IV type) by defining new *_iv macros.
Fixed quote_identifier that was adding a trailing separator when there
was only a catalog (Martin J. Evans)

Removed redundant keys() call in fetchall_arrayref with hash slice (ilmari) #24
Corrected pod xref to Placeholders section (Matthew D. Fuller)
Corrected pod grammar (Nick Tonkin) #25

Added support for tables('', '', '', '%') special case (Martin J. Evans)
Added support for DBD prefixes with numbers (Jens Rehsack) #19
Added extra initializer for DBI::DBD::SqlEngine based DBD's (Jens Rehsack)
Added Memory Leaks section to the DBI docs (Tim)
Added Artistic v1 & GPL v1 LICENSE file (Jose Luis Perez Diez) #21

=cut

Enjoy!

Tim.

(Fwd) DBI Dilemma (12 messages)

$
0
0
----- Forwarded message from "Adkins, Blake" <blake.adkins@intel.com> -----

Date: Mon, 17 Aug 2015 17:51:41 +0000
From: "Adkins, Blake" <blake.adkins@intel.com>
To: "Tim.Bunce@pobox.com" <Tim.Bunce@pobox.com>
Subject: DBI Dilemma

Tim,

I've been using your module to enable people in my group to do searches on a database that is regularly
backed up as a .csv file. The problem here is with a particular column name. Of the 140 columns in the
database, one is named DESC, short for description. This was established well before my time at the
company and I believe the name comes from GE who makes the Cimplicity product. If I try to do a SELECT
using that column, the script dies, or quietly passes DESC in the column header and all the rows. I've
tried to figure out how to get around it without success. Do you have any suggestions aside from
renaming the column? (I was thinking along the lines of escaping the name)

Thanks,

Blake Adkins

----- End forwarded message -----

Segmentation fault (1 message)

$
0
0
Hej folks,

While writing perl tests for a framework I'm working on I ran into some weird segmentation faults today.
I started noticing them in a test after changing they way error were returned in some unrelated object, which involves returning an internal error string that appends $DBI::errstr if available. We check $dbh->err() if available and $DBI::errstr for errors.
Funny thing is: the segfault only occurs 2 out of 5 times orso.

The segfault always seems to happen after disconnect(), I'm guessing on termination of the program when perl starts cleaning up stuff.

Here's a stacktrace when it segfaults on DBI:
===
1..20

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5cd7471 in err_hash.isra.6 () from /usr/local/lib64/perl5/auto/DBI/DBI.so
(gdb) bt full
#0 0x00007ffff5cd7471 in err_hash.isra.6 () from /usr/local/lib64/perl5/auto/DBI/DBI.so
No symbol table info available.
#1 0x00007ffff5cdbfe6 in XS_DBI_dispatch () from /usr/local/lib64/perl5/auto/DBI/DBI.so
No symbol table info available.
#2 0x00007ffff7b0a416 in Perl_pp_entersub () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#3 0x00007ffff7a942f6 in Perl_call_sv () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#4 0x00007ffff7b13471 in ?? () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#5 0x00007ffff7b13bb0 in Perl_sv_clear () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#6 0x00007ffff7b1423d in Perl_sv_free2 () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#7 0x00007ffff7b0b7e7 in ?? () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#8 0x00007ffff7b147f6 in Perl_sv_clean_objs () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#9 0x00007ffff7a96570 in perl_destruct () from /usr/lib64/perl5/CORE/libperl.so
No symbol table info available.
#10 0x0000000000400ed1 in main ()
No symbol table info available.
(gdb)
===
Does anyone have any idea what causes this? Or how to debug this properly?
I just installed the latest versions of DBI and DBD::mysql, that didn't help.

Thanks for reading.

Wouter.

DBI::errstr : SvUTF8 flag not set (1 message)

$
0
0
Hi,

I use DBD::Pg with the pg_enable_utf8 flag set; server locales, perl scripts and databases are all UTF8 encoded.

When using this construct in mod_perl context :

eval { $dbh->do($sql) } ;

if ( $@ ) { $content .= $@ }

I get garbled accented characters in the error message :

DBD::Pg::st execute failed: ERREUR: syntaxe en entrée invalide pour l'entier : « €20 » at <....>.pm line 103.

Messages are correctly displayed from the command line and in Apache and Postgresql logs, just not in my web pages. It seems the SvUTF8 flag is not set on errstr.

I can solve it with $content .= decode_utf8( $@ ), but was wondering if there is another solution?



--
Salutations, Vincent Veyron

https://legalcase.libremen.com/
Legal case, contract and insurance claim management software

ANNOUNCE: Informix Database Driver for Perl DBI Version 2015.0826(2015-08-26) released (1 message)

$
0
0
On the eighth birthday of the 2007.0826 release of DBD::Informix…

Informix Database Driver for Perl DBI Version 2015.0826 (2015-08-26) has
been uploaded to CPAN.

IBM Informix Database Driver for Perl (also known as DBD::Informix) is
the driver code that enables Perl 5.008001 or later to access Informix
databases via the DBI module (but if you are not already using Perl
5.022000 - or a later version - you should be planning to upgrade Perl).
You will to install DBI version 1.607 or later as well (version 1.634 - or
any
later version - is recommended) before installing DBD::Informix. The
code for DBD::Informix is available for download via:

http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces
http://dbi.perl.org/

** When you successfully build this module, use the ItWorks (Perl)
** script to report your configuration to the maintenance team (meaning
** Jonathan Leffler) at dbd.informix@gmail.com.
** The ItWorks script does not send email to anybody; you have to do
** that yourself.

New in release 2015.0826:
* Automatically deal with Perl and DBI minimum versions since the previous
releases had a mish-mash of version numbers scattered through the code.
* Fix DBD::Informix::TechSupport module, thereby fixing the TechSupport and
ItWorks scripts too.
* Note that with effect from the first release from 2016-01-01 onwards,
DBD::Informix will no longer support any version of ClientSDK prior to
version 3.50, the oldest version currently supported by IBM. The support
code for some of the older versions of ESQL/C will be removed over time.
You're welcome to try using older versions, but if anything goes wrong,
you will need to upgrade.

New in release 2015.0825:
* Deal with changes to ExtUtils::MakeMaker that broke the build.
* Update to require Perl 5.8.1 and DBI 1.607.
* Change work email address back to jleffler@us.ibm.com

New in release 2013.0521:
* Support CSDK 4.10 for IDS 12.10
* Change work email address to jleffler@google.com

New in release 2013.0206:
* Bug fix release (not generally available).
* Properly handle the new ESQL/C version 4.10.

New in release 2013.0113:
* Bug fix release.
* Workaround for bug in ESQL/C 3.70 and earlier that generates error -1820
when reopening a cursor that previously fetched LVARCHAR data.
* Fix for INFORMIXDIR containing Perl regex metacharacters.
* Other minor improvements as documented in the ChangeLog.
* Formal support for ESQL/C 7.x and 8.x (don't ask why the
current version numbers are smaller) will be dropped after this
release. The code won't go away yet, but it is beyond time to
get off those versions. ESQL/C 5.20 is nominally supported for
those still using Informix OnLine 5.20, but there is no
testing on that platform.

Support email address:
* This release is supported by Jonathan Leffler <dbd.informix@gmail.com>.
* You may also report your bugs via the CPAN resolution tracking system:
http://rt.cpan.org/
* Such bug reports can be sent by email to bug-DBD-Informix@rt.cpan.org;
they also get sent to dbd.informix@gmail.com, etc.

As always, see the ChangeLog file for details about what has changed.

Jonathan Leffler (jleffler@us.ibm.com, jonathan.leffler@gmail.com)

@(#)$Id: Announce,v 2015.3 2015/08/27 02:28:24 jleffler Exp $


PS: I'm not sure the CSDK 3.50 is still supported by IBM — anything older
most definitely isn't.

--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2015.0825 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

(Fwd) perl DBI bug report (1 message)

$
0
0
----- Forwarded message from Dave Dyer <ddyer@real-me.net> -----

Date: Tue, 01 Sep 2015 12:40:00 -0700
From: Dave Dyer <ddyer@real-me.net>
To: Tim.Bunce@pobox.com
Subject: perl DBI bug report


This query produces results with lots of trailing nulls
embedded in the "outcome" value. I suppose this might
be expected to do something odd at the sql engine level,
but embedding null characters, which do not occur in any
of the elements, can't be correct.


my $q = "select matchgroup.status,player,points,tournament,outcome,played,"
. " matchparticipant.comment,tournament_group,matchparticipant.uid"
. " from matchparticipant left join matchgroup "
. " on matchparticipant.tournament = matchgroup.uid and matchgroup.name = matchparticipant.tournament_group "
. " where matchid=$qm "
# note that because of the particular structure of this join query, $outcome seems to be padded with a lot of nulls
. " union select matchgroup.status,-2,0,tournament,if(admin='winner',admin_winner,admin),played,"
. " matchrecord.comment,tournament_group,'A'"
. " from matchrecord left join matchgroup "
. " on matchrecord.tournament = matchgroup.uid and matchgroup.name = matchrecord.tournament_group "
. " where matchid=$qm "
. " order by uid ";


----- End forwarded message -----

Oracle character column sizes from {PRECISION} (3 messages)

$
0
0
I have a table defined as follows:

SQL> desc sb1
Name Null? Type
----------------------------- -------- --------------------
C1 VARCHAR2(30 CHAR)
C2 VARCHAR2(30)

Note the difference is the character semantics, c1 is CHAR, c2 is BYTE.

I am trying to distinguish between them in my perl code which looks like
this:

my $name = 'sb1';
$dbh->{'ora_verbose'} = 6;
my $sth = $dbh->prepare( 'select * from ' . $tname . ' where 1=0' );
my $p = $sth->{PRECISION};
$dbh->{'ora_verbose'} = 0;
log_it(Data::Dumper->Dump([$p], ['$p']));

Here's the output:

OCIHandleAlloc(2548710,25eb278,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIStmtPrepare(25e94b0,256eda8,'select * from SB1 where 1=0',27,1,0)=SUCCESS
OCIAttrGet(25e94b0,OCI_HTYPE_STMT,25eb28c,0,OCI_ATTR_STMT_TYPE,256eda8)=SUCCESS
dbd_st_prepare'd sql SELECT ( auto_lob1, check_sql1)
dbd_describe SELECT (EXPLICIT, lb 80)...
OCIStmtExecute(25763c0,25e94b0,256eda8,0,0,0,0,mode=DESCRIBE_ONLY,16)=SUCCESS
OCIAttrGet(25e94b0,OCI_HTYPE_STMT,7ffcea08f4fc,0,OCI_ATTR_PARAM_COUNT,256eda8)=SUCCESS
OCIParamGet(25e94b0,4,256eda8,25eca10,1,OCI_HTYPE_STMT)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca40,0,OCI_ATTR_DATA_TYPE,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca42,0,OCI_ATTR_DATA_SIZE,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca58,0,OCI_ATTR_CHAR_USED,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca5a,0,OCI_ATTR_CHAR_SIZE,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca5c,0,OCI_ATTR_CHARSET_ID,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca5e,0,OCI_ATTR_CHARSET_FORM,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca44,0,OCI_ATTR_PRECISION,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca46,0,OCI_ATTR_SCALE,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca47,0,OCI_ATTR_IS_NULL,256eda8)=SUCCESS
OCIAttrGet(25ec8f8,OCI_DTYPE_PARAM,25eca48,7ffcea08f4f8,OCI_ATTR_NAME,256eda8)=SUCCESS
Describe col #1 type=1(VARCHAR)
Described col 1: dbtype 1(VARCHAR), scale 0, prec 120, nullok 1, name C1
: *dbsize 120, char_used 1, char_size 30*, csid 873, csform
1(SQLCS_IMPLICIT), disize 120
fbh 1: 'C1' NULLable, otype 1-> 5, dbsize 120/121, p120.s0
OCIParamGet(25e94b0,4,256eda8,25ecab8,2,OCI_HTYPE_STMT)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecae8,0,OCI_ATTR_DATA_TYPE,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecaea,0,OCI_ATTR_DATA_SIZE,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecb00,0,OCI_ATTR_CHAR_USED,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecb02,0,OCI_ATTR_CHAR_SIZE,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecb04,0,OCI_ATTR_CHARSET_ID,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecb06,0,OCI_ATTR_CHARSET_FORM,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecaec,0,OCI_ATTR_PRECISION,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecaee,0,OCI_ATTR_SCALE,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecaef,0,OCI_ATTR_IS_NULL,256eda8)=SUCCESS
OCIAttrGet(25ec8a8,OCI_DTYPE_PARAM,25ecaf0,7ffcea08f4f8,OCI_ATTR_NAME,256eda8)=SUCCESS
Describe col #2 type=1(VARCHAR)
Described col 2: dbtype 1(VARCHAR), scale 0, prec 30, nullok 1, name C2
: *dbsize 30, char_used 0, char_size 30*, csid 873, csform
1(SQLCS_IMPLICIT), disize 30
fbh 2: 'C2' NULLable, otype 1-> 5, dbsize 30/31, p30.s0
OCIAttrSet(25e94b0,OCI_HTYPE_STMT,
7ffcea08f4f8,4,Attr=OCI_ATTR_PREFETCH_MEMORY,256eda8)=SUCCESS
OCIAttrSet(25e94b0,OCI_HTYPE_STMT,
7ffcea08f4f4,4,Attr=OCI_ATTR_PREFETCH_ROWS,256eda8)=SUCCESS
cache settings DB Handle RowCacheSize=0,Statement Handle RowCacheSize=0,
OCI_ATTR_PREFETCH_ROWS=156, OCI_ATTR_PREFETCH_MEMORY=0, Rows per Fetch=156,
Multiple Row Fetch=On
OCIDefineByPos(25e94b0,25eca18,256eda8,1,25edc90,121,5,25ecb60,25ecca0,25ecde0,mode=DEFAULT,0)=SUCCESS
calling OCIAttrSet OCI_ATTR_CHARSET_FORM with csform=1 (SQLCS_IMPLICIT)
OCIAttrSet(25ec700,OCI_HTYPE_DEFINE,
25eca5e,0,Attr=OCI_ATTR_CHARSET_FORM,256eda8)=SUCCESS
OCIDefineByPos(25e94b0,25ecac0,256eda8,2,25f32b0,31,5,25f45a0,25f46e0,25f4820,mode=DEFAULT,0)=SUCCESS
calling OCIAttrSet OCI_ATTR_CHARSET_FORM with csform=1 (SQLCS_IMPLICIT)
OCIAttrSet(25ec4b0,OCI_HTYPE_DEFINE,
25ecb06,0,Attr=OCI_ATTR_CHARSET_FORM,256eda8)=SUCCESS
dbd_describe'd 2 columns (row bytes: 150 max, 75 est avg, cache: 0)
$p = [
120,
30
];

As you can see, DBD::Oracle knows the difference but the array returned by
PRECISION is in bytes rather than characters. I want to access the number
of characters.

Is this possible?

Thanks,

Steve

--


------------------------------------------------------------------
This email is intended solely for the use of the addressee and may
contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the
sender and delete the email..
------------------------------------------------------------------

RE: DBD::Sybase not working for Sybase ASE15.7 (2 messages)

$
0
0
Hi experts,



I'm not sure whether the email list still works. because
sybperl-l@peppler.org is bouncing my email.. J



We got a problem when using DBD::Sybase with Sybase ASE15.7. The error
message is as below:




Sybase CSI Error Message: Invalid directory
/home/sybase/sybase15.7/OCS-15_0/lib3p64/sybcsi.

Error Connecting to Database as:

DBI Error Message:

Message String: ct__string_extended_encryption: user api layer: internal
common library error: Client password encryption fails.



Looks to me the new installation doesn't have a directory sybcsi.

also Sybase website provided the reason why the dir was removed:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc2
0155.1550/html/newfesd/BABIFHIC.htm



So, from our side, we don't have solution for this now.



Could you please check and suggest?



Thank you in advance!



Regards,

Bryan Yin

FX Roadmap Backend Development


Perl GD module install error (3 messages)

$
0
0
‰PNG

IHDR|:ý}ª˜sRGB®ÎéëIDATx^í[ktTÕ¾ç>fBB”PÉ[4¼‡«
A,T©b±Aê­äGmKWmV
ÕÚJ,¾ê²h1EqÄ聊`}PP–7("˜“™ûèwΞ¹¹™I&7CHÂZ²&wî=gŸ}¾½÷·÷970˲¤K­c;vºK³q.Þ ~p ôK w0å%OïÐY—ª^PH±( „ê,‹ìTÝΩ?ó®HòûVÕ4éšg~gzeYb&þI23¹,\˖dIâÃb2¿cȒÂ%™&c²èÀ$mÚv7K×ÝÕò,É÷éá£×Ïôš¥Z¦ì—|³oœÃE,9‰†–d0K‘LCR”€%5øjÞþ×û¬
Ô×§ÈÍ]úsÏ LÏô5$üêÀօ@GÌ1ÆLӔá¯Í5îžèSWäò-¦k¦lÀO0Ùoég=ÊÈÿ} +š
—ÆM87<ß2—Î}T‘àðèÏ6%Vï\]¬'vC7•ìÔQ­q:Çú9‚-5 n˜•k6qÅ2ŠI¸ÜWÍ8ƒõ0-½ê”Ĺ pŠ'×VÌ[*3¿É€¹°‚kÕ_óÅw&ªõõŠat$â] N7%]2-ðo}íÞiÿ“<î³Þãö<°Ôò7`§†àK{(¸Z9ýр*K2øØ§šœB¸¿[~)¦¨©ãlƖdüVjµ¿{ÆãóÃü»7yX–G’ýƶ!7KŒs‹cŒÍ"b·G4t¦§V ¥À÷WH™Ôýݏ’|þ^½çó?î›Çjàðƒ/ފÏ˾;Dǯ.2ÓÕâ¤Ìµ„x$J€Ä솭Åé†O•T„C:_ÄKïÿÕ³€–Àe޶iÉÐá{é:Y²Zg‚Žèçë7¬OoÈ÷è> i™  f(fŸzß;'ñÇX2ˆœ»hLJ_8C5½†÷ÃH^#àGºø²u6Þ£¦]¡à‹ zØô³¿j†)lÓ0ØÄcðXˆkÀ3Èæ´Lä^ ú
Ê.IUy„^ŽÈ;t&è ø&;[ÓÓ¯ƒ%d=-V°Xæ‰:Yç¼,\V}T“ÄÇe.—$eŀÌxP,ŸÎ†~ù®¥i3yI"Zvޘ€ªñ°4‰!¢`Ñ»iÏ\†ðw†¾Šé—ÎÔÕþêé·/<zÇ"v°Z2vœ®¸çÝ:µz8²Úº#½ÆËàcIµDEš(ºjÄeÖm÷+ª‹…9¨sÈ#Ê“Û¾7#ë”_²Y«Î¹büÖµR÷Q›ƒ²9/q‡ÿ¶æPÚ$-†·``p$À܄†¡ÊJY’:¡òT•0ß°Œ@ñîý?ùE¯s¨E¹{V’k5Ö0iäðõ’,EF(`$‡¾•}EKÖéLЃ*Æ'Wޔôí7€$*‹g‡³¯˜òyʾè&žŠ ç†i /BAg’ßæÛ"QâX¨É7~úç·>Øã½!¥(YNTˆ}ËúbËèÍ·H|&ëóÙ'¼¾%,or~cPŽ}uùeãJ6ëSáòÁ̋çw&½ÀéðùßMuÞӌb(Ǔ{Mùôà 8$|a@köbåªfyЯ(˕ûvc‰WºaՉ±C,¦¢`GmiÀQUK—ÍZEéùUr¿Þœ³Ñ‘)'_/áõ÷˜‡ò¸±´UJ9õMñÈi\/ÿEº‰©u²§óÔ(*9I÷Ÿ|êõò76ƒeF/™/M+)ÀVÖeNøÎ%x»¶Ì;ЭHľTFà”ŸÜ•??®ä„ÎIó&Ü4ràš¥–·øVFµ/ý½'x̅QÓ͂¢ÞŸè0,›UZì¿2ÉÃY,FÔ;ôpø8Z:¥ž,À“¼îàt"˜WÔãÍ1'¸BøvˆXéí?rq¾!€lŠC6†DÍwü¦„ò§0/rP®Šcn¬’Š/‡Oµ{ز  ¢ÒiÃù–î›uÛ ‚ߊœ#ê‚^8¨þDeJ%GßûÁì÷§/NÕÂ逪N¸ÒU„¶†ßqžDƒ+Aýnãé¿ÝÐq‰¨Èù$5YâB$¨C/åe¦ªŠ¦àZœ»ðí©¨]¾=öWG†Ó‡Ï€âàØ¼d—YÃ+‚ˆ‘].ț#^ÃáYOožw$÷Öìíû36ýûpÚ UŠŽ2AⅰwL+Œï‰ó*¼lEDbXV¼æ 9öíÒY9?‡â嚞üþ~€+c·Ác_­ýãß'LqúÚµZ|ÿôzµù¼íTTµÔž“¿Ÿâ;ˆXßé·?èàÔ|¨ÜÐëà;ɂ’Ákù¥³õ|COìÒe?#HФõ¶â鲒²àö`:‰v8mmí:íJ¸êCÒ²G7yYˆ³Vø6Þ6HÉ T­ˆ:·ë4žsÿ]XïŎˆŸ,kHÁ¡3Ô¤Xî SƆ¿ø=<‰ã‰×ã°(h÷”pxo·¾[ÖXZ¢0q¬rÎÓmØÞ7%Y(­HhI]xÀڀ-W|Ü ’mç4%¿bòŠÀ2YeãW?Ä&õÄ{(Θ1Fk›KFzÕÖ­[wàÀ¯¾úªOŸ>×]wÝÔ©SyµB{7`J'«¼Ž1¤Ò’W“R/ã7h[N´Sï¨FjÓlô†ÒþŠk¾ÅEíÊwfªì7«Ÿ~éØã/¤Ô(êqŒ£ˆúë‡+ü³¯ZœöC…/øL§d¼„QDÑ¥µ t¨ûÔSO=ùä“(P _1>‘ôu„ Ͻø¢Æ4%œÍm b‘£,¸<´© #•ŽhNăžQrmàÜ6â0Îï7¤GԊdž
»e~Ǘ*v¼àåý›¼ç⇔vÝ0Œììl“stT32¶téÒY³fwœîæiiýÈés÷îÝ}û^ént´^gΜÎÍ͵{ ܟy¦ U±n} |Ħ†gÑëׯouâÎê@ï`Üržš@`[%¸}Õª•@Üé,˜ F^¶lY~~¾m þNÇ0ßzkc[õ°ûӈvÝüyˆ³OK£ ¶2.²nÔsJ‹‚l«d9—[Ð
V;½###«¼¼²¨èí;ïüɊ+q]YY=gνŠ¢•”‰ÍÄKü-Jczu#‡ú8¡w3ÊècãÞ^2i^·‰œèTtÛ¶™™™ÑUÆuuµo½µ˜_gμ‹òȪ°p-púô隦!¼ðÂt3..1tûíÓ[JMðVEa6l@·¯¿þÚöÄÔÔÔ9sæÌœ9³[·nâ4‹gxÌèÔwz衤¤$RŸ·Þ:ýí?Á¤î_´hѾÏ÷q{Šêvîܹ‹/öxâÈÆ406Nwzjê•<o‡6¾ ¸y¡žâeoXê/¹há…x´`Á‚·ß.rÆ/©ÓÓE]$}üñ'½zõra´à»ï¾{Û¶­4„žÚº°Ê,\´è×$Ù :ÕZ¤IËÉP\ü.~úô©#FžÄ{W>–Nò33³wìØa/<6ÐÝҋqL¹oß>,cýúÚKã_¢Qbj6¦å”F=©Ý·QÃ{±Q£FؘÒx
ÄiMDO©r¥xZ½zu³„ë$h…8#Ç(+;2|øpû¦Í]¤Zyyiff:MÅç¢?rúòåxÞ|ðçi؝;wŽ€s©J˜…J‹
{&¸ÛèÑ£¨ùojj?g@Øyáò8ý™3g&NœÈg[M҇ʅYÀóçϋN­íúŒwöìً ±Ý‡Ô­ªªÈɹ&==íàÁôv±eèƒh:5¦ëŒŒÌ‹*+«À'×©ô±cÇl3Œ5ýá˜öÿ8¿¼¼+**qáõz6kñ¨á®»îúéOïÇϼy?»ÿþy¯¼ò
F]{íµAJÁ~Ù²òóg@fEEUuõ±ªªj2<–_TTDNâÒ®aÝÜz:¢vïÞ½ýúõã™P"¨Í)S&3ÚöÊæ
jéT—®·oß>dH.ÊÍääËúÒéY˜âøñ¯©Û©S'ù›áz¸ÿ裏®XñzS'Ð@œ4 ”HÈoZ–,y?‹#§.Á¤ÇŸ xCÎ6–/_™¡—ÔìСC¡˜à=Ö®]âåtòî;wmÚ´)ÊdǏÏÊÊl5ôììj !úVUç;}>ÛéÓ§ÑaÅ
 ÐXPúY³î!hmýü@ŌÝßN =ö˜-jÔÕÕÔ¡ü
¶š°ðíÐmÿ<8·¬¬¢¤¤Tæ/ښá+Öøï»ontœ‡Ö6d„E³ƒâìíÄwö칺ΌVmìô-òô°!øºqãFû&HfÚ´iƒ80gРø8p@NNŽsTUUUk–nñ¹[O'äVX§Çã)++“¾öÚka²¡Yqqqô—‘kv
iÉs±st“o»í¶È˜ˆtúr‹R:;{ö¬c7¯NÛ@§LB’Ä;ö:lGSRúFhMrtBhi1(؋0qhå²Xrg‰F÷w.Ó¦3?ÃnÖÚôfeÀ)^~ùe[7öwrº;Dx¯«®ºÊ‰ò²e»™KÈo½¦îÞ½‡ß={ö °D«]8ó›:²1)â³ÉqëÖ­ö}wª´-ÂhÆ{î¹'ŒOvíÚIñÕï‘"¡icá„ë£G:KÇq‚Óo°gæìAw†¶üš6p”!šÈ¥¹]|iiÉðáC±ÍÎÆÕዠ °Î]»v¡®pÎçw—6v›<y²3bÙ8c™?>¡'xâ‰'|>Ÿ®‡ŸøƒŽ–€ÎPØYÆ@ì-·Üb÷ÁŇ~øì³Ï:y†,Z]]¬~žtúøñãi&,)==Q Oüäçß'³#ÝpÕ¢-M‡û®ÞÝ=ÿü‹”É)æÄ¦Má
éé©YYýkn6û¶,!!‘T‚ž0Á®Ý;¡ù5×ôlj¶õÄZßÿþ.ÿ7L„Æãÿbo¼1ï7¿ùõäÉ7忯qãÆ\}uÇêÜèÄí˜È˜¥ˆŽ—õïßÇmvc€×¤I“òò&Ÿ¸ÑØå¹çžwôçï›Ñ¨…•——Aàš5k¸ØÐß`PqyøðáW_}õàÁƒ5554)>qÜØ¦ÙÃ:»U*MI†8}…uí–-[©„wö§!öM’c»žó¾}íd’|>䥗^zøáßRdN×Í7ǎ3zô[;°8uêi,6ýC‡=ÆV˜f§)ÉHååå6ŽÎ]&v· ¿óλÈããÇç©ø#ýˆZ“¡´())Á‹:±u6ì¶âEëÑ£H™Ö†»{÷îx„†£ó•+WÚêu"VpÀ˜˜ˆè9`À[&žÞ{ï½Ø"àϲ²² =SRRòòòPQбx˜g^……ÿ|óÍ HÅÎL’œœüÁÿ"gB@c—TQQ‘––FBì‡y0šc{wõp.O¡k7c±IËÀ'”¶Õu3ßùô/.ø9}& h‚ví¨†8±j©39o³g¿$–¿Ò\e7të鑲(¬èp<rÿæfî¶ö±3¤„S‚þa–W k
¸èlpç µuåԟ¼›âÑ&ÖØD¹E´JAÉñÈ#KfοˆÃ†‹<À ³©Mît{].™ÚýBb¤÷´oÏÙ³gmÙ²Åöt›å¨èv¢ƒkT¶Û·ïˆÎ!í«žKièýú}tá|s¶N²˜Ýœ5†K8:¦[ŒôÒ1ÊEβn]!n¢Šh)ڔ]ZZÚYJ¶:ïEæéb=øûˆCâH€J×&»$ÐþæÍ›‡ÒêÊ;±Ãź@:T³†e¹Vk’NÄڞúb½+`³§Ç¼Î.5ðÿ»¨Å]—Â_IEND®B`‚

Broken CSS onmetacpan.org (6 messages)

$
0
0
FYI: your CSS appears to be broken on: https://metacpan.org/pod/DBI

There is no page formatting, others such as, DateTime seem to work fine.

|   |
|   |   |   |   |   |
| DateTimeA date and time object for Perl |
| |
| View on metacpan.org | Preview by Yahoo |
| |
|   |


 

MySQL issue with InsertID (1 message)

$
0
0
Hi all,


I wanted to point out that I have reported an issue with the latest
'dev' release of MySQL and DBD::mysql concerning mysql_insertid

http://bugs.mysql.com/bug.php?id=78778

It's been confirmed as an issue in the above bug report (by Oracle
and/or by someone operating under the handle 'Umesh Umesh').

So if you'd be trying out the new MySQL version and run into this
issue, you know it exists!

Kindest regards,


Michiel

unsuscribe (1 message)

new development release 1.53_1 of DBD::ODBC (1 message)

$
0
0
I've just uploaded DBD::ODBC 1.53_1 to the CPAN.

The most significant change is to support DBI's new 64 bit row counts. DBD::ODBC did (and still does) support 64 bit row counts via its own API but this now means if you have an up to date DBI, you can use the normal return from the execute method.

If you have a 64 bit platform and Perl you probably want to give this a go before I do a full release.

The changes since 1.52 are:

1.53_1 2015-10-16

[BUG FIXES]

Strictly speaking this is a bug fix to DBI and not DBD::ODBC but DBI
now supports 64 bit row counts where an IV in perl is 64 bits. However, it
necessitated changes to DBD::ODBC to pick up the fix. odbc_rows (my workaround
since 2012) is still supported but should no longer be required so long as you
use this DBD::ODBC and DBI 1.633_92 or above.

[INTERNALS]

Removed dbd_st_rows and now setting DBIc_ROW_COUNT.

[DOCUMENTATION]

Add tables and table_info section to deviations from the DBI spec.

[MISCELLANEOUS]

Change column name in t/rt_101579.t as "method" is a reserved word
in. Teradata Thanks to Zhenyi Zhou.

Remove duplicate dynamic_config from META.yml.


Martin

DBD::Oracle and RHEL Instant Client rpms (3 messages)

$
0
0
Has anyone else had trouble installing DBD::Oracle with the latest 12.1 instant client?

I installed the Basic and Development IC rpm’s and the DBD installer complained it couldn’t determine what version I had, then complained it couldn’t find demo.mk. I finally got it to work by manually telling it what version and the path to the .mk file (which hadn’t changed from previous versions: /usr/share/oracle/<version>/client64…)

The various env values were set correctly, and the files were installed in the usual place, the only difference between this time and the last time I set up a RHEL system was I used the latest 12.1 instant client files rather than 11.2.

[root@kalendaetest DBD-Oracle-1.74-EIJTlU]# set |grep ora
LD_LIBRARY_PATH=/usr/lib/oracle/12.1/client64/lib
ORACLE_HOME=/usr/lib/oracle/12.1/client64
PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lib/oracle/12.1/client64/bin
TNS_ADMIN=/usr/lib/oracle/12.1/client64/admin

It worked, eventually, just wondering if others have run into the issue...

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Viewing all 225 articles
Browse latest View live