Re: [Catalyst] DBIx-Class list, cdbi-talk closure (fwd)
At 2:23 PM -0400 7/28/05, Christopher Hicks wrote: -- Forwarded message -- Date: Thu, 28 Jul 2005 17:47:46 +0100 From: Matt S Trout [EMAIL PROTECTED] Ok, due to popular demand I've got gabb to set up [EMAIL PROTECTED] for DBIx-Class discussion (thanks gabb!). I've stopped hacking on it for a few days while I think through where I want to go with the code, so now would be the time to make design/feature suggestions! Also, with the recent unexpected closure of cdbi-talk I (and I guess most of the other people involved) would be happy to answer Class::DBI questions on there, at least as a stop-gap measure until a new dedicated cdbi list turns up. Matt S Trout Website: http://www.shadowcatsystems.co.uk Technical DirectorE-mail: mst (at) shadowcatsystems.co.uk Shadowcat Systems Ltd. I wrote Matt S Trout (also cc'd now) partly on this topic, and he asked me to forward this following extra information to dbi-users. -- Darren Duncan Date: Fri, 29 Jul 2005 03:40:42 +0100 From: Matt S Trout [EMAIL PROTECTED] On Thu, Jul 28, 2005 at 06:45:03PM -0700, Darren Duncan wrote: FYI, I noticed your contact info in a message forwarded to dbi-users concerning a DBIx-Class module that seems to be related to Class-DBI. Well, it *was* a research project, but since Tony Bowden decided to delete the cdbi-talk list and wiki, what happens next I can't say anymore - the refugees from there are all welcome on the dbic list, and I appear to already have 50 subscribers. The aim is to produce a cdbi-style more pluggable (via MI and NEXT.pm) resultset (rather than table, i.e. native views etc.) oriented ORM with a cdbi compatibility interface for easy migration (and as a good way to exercise the codebase). It ain't production-ready yet but it's coming along nicely. List is at http://lists.rawmode.org/mailman/listinfo/dbix-class SVN is at http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ I should probably get on dbi-users, but my mailbox is full enough atm. Could I perhaps put upon you to knock out a quick reply to that forward outlining what I've just said (poss. just C+P-ing from The aim)?
Inserting UTF-8 string over 2000 chars to Oracle 10g - error ORA-01461
Hi,
Even though character encoding issues have been discussed also here, I still
cannot figure out what is going on in my system.
I try to load data from XML documents and insert into an Oracle database. A
simple test program (given below together with the trace) that tries to read
and insert a string of 2075 a:s to a varchar2(4000) field fails:
$ /opt/perl-5.8.7/bin/perl utf_test4000.pl
UTF8 on, ASCII, 2075 characters 2075 bytes
DBD::Oracle::st execute failed: ORA-01461: can bind a LONG value only for
insert into a LONG column (DBD ERROR: error possibly near * indicator at
char 19 in ...
XML-parsing causes conversion to UTF8 but as the nice data_string_desc function
shows, the string should still be only 2075 bytes long. Why does it look
like double space is needed compared to the actual length?
I have observed that
- the problem disappears if I truncate the to less than 2000 chars:
UTF8 on, ASCII, 1953 characters 1953 bytes
- the problem disappears if I make the field varchar2(10) and store 9 a:s:
UTF8 on, ASCII, 9 characters 9 bytes
- the problem disappears if I read from stdin i.e. get the UTF8 flag off:
UTF8 off, ASCII, 2073 characters 2073 bytes
(- however the problem does appear when reading from stdin if I use Perl
5.8.0 and an old DBI instead of 5.8.7 and a new one. I first had this problem
with a plain text file, installed 5.8.7, got rid of it but now l still have
the same problem when reading from XML-files.)
- setting NLS_LANG to various values does seem to affect the behavior.
Thanks for your attention
Teemu Kivioja
== system ===
Linux, 2.4.21-32.0.1.ELsmp
Oracle 10g, version 10.1.0.3.0
Perl 5.8.7 built for i686-linux
DBI-1.48
DBD-Oracle-1.16
locale: LANG=en_US.UTF-8
== code =
use DBI qw(:utils);
use XML::Parser;
my $str;
my $xp = new XML::Parser(Handlers = { Start = \start_handler,
Char = \char_handler,
End = \end_handler });
$xp-parsefile('test4000.xml');
my $user = ;
my $passwd = ;
my $db = ;
my $dbname = ;
my $server = ;
DBI-trace(2);
my $dbh = DBI-connect(dbi:Oracle:host=$server;sid=$dbname, $user, $passwd, {
RaiseError = 1, AutoCommit = 0
});
my $sth = $dbh-prepare( q{
INSERT INTO test_long_str (id, str) VALUES (?, ?)
});
my $id = 3;
my $description = data_string_desc($str);
print($description\n);
$sth-execute($id, $str);
$dbh-commit;
$dbh-disconnect;
#--- functions #
sub start_handler {
my($xp) = @_;
$xp-{cdata_buffer} = '';
}
sub char_handler {
my($xp, $data) = @_;
$xp-{cdata_buffer} .= $data;
}
sub end_handler {
my($xp) = @_;
$str = $xp-{cdata_buffer};
}
= trace ===
$ /opt/perl-5.8.7/bin/perl utf_test4000.pl
DBI 1.48-nothread default trace level set to 0x0/2 (pid 32686)
- DBI-connect(dbi:Oracle:host=sboracle1.ad.vtt.fi;sid=BfxDB, belkit,
, HASH(0x989b180))
- DBI-install_driver(Oracle) for linux perl=5.008007 pid=32686
ruid=500 euid=500
install_driver: DBD::Oracle version 1.16 loaded from
/opt/perl-5.8.7/lib/site_perl/5.8.7/i686-linux/DBD/Oracle.pm
- STORE in DBD::_::common for DBD::Oracle::dr
(DBI::dr=HASH(0x9969f68)~0x9a10e54 'ShowErrorStatement' 1)
- STORE= 1 at Oracle.pm line 61
- install_driver= DBI::dr=HASH(0x9969f68)
- connect for DBD::Oracle::dr (DBI::dr=HASH(0x9969f68)~0x9a10e54
'host=sboracle1.ad.vtt.fi;sid=BfxDB' 'belkit' HASH(0x98fa3c4))
connect using
'(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(HOST=sboracle1.ad.vtt.fi)(PROTOCOL=tcp
)(PORT=1526))(ADDRESS=(HOST=sboracle1.ad.vtt.fi)(PROTOCOL=tcp)(PORT=1521)))(
CONNECT_DATA=(SID=BfxDB)))'- connect= DBI::db=HASH(0x9a73550) at DBI.pm
line 598
- STORE for DBD::Oracle::db (DBI::db=HASH(0x98fa43c)~INNER 'RaiseError' 1)
- STORE= 1 at DBI.pm line 645
- STORE for DBD::Oracle::db (DBI::db=HASH(0x98fa43c)~INNER 'PrintError' 1)
- STORE= 1 at DBI.pm line 645
- STORE for DBD::Oracle::db (DBI::db=HASH(0x98fa43c)~INNER 'AutoCommit' 0)
- STORE= 1 at DBI.pm line 645
- STORE for DBD::Oracle::db (DBI::db=HASH(0x98fa43c)~INNER 'Username'
'belkit')
- STORE= 1 at DBI.pm line 648
FETCH= 'belkit' ('Username' from cache) at DBI.pm line 648
- connect= DBI::db=HASH(0x9a73550)
- STORE for DBD::Oracle::db (DBI::db=HASH(0x98fa43c)~INNER
'dbi_connect_closure' CODE(0x9a735ec))
- STORE= 1 at DBI.pm line 668
- prepare for DBD::Oracle::db (DBI::db=HASH(0x9a73550)~0x98fa43c '
INSERT INTO test_long_str (id, str) VALUES (?, ?)
')
dbd_preparse scanned 2 distinct placeholders
- prepare= DBI::st=HASH(0x98fa550) at utf_test4000.pl line 27
UTF8 on, ASCII, 2075 characters 2075 bytes
- execute for DBD::Oracle::st (DBI::st=HASH(0x98fa550)~0x98a11a4 3
Re: Inserting UTF-8 string over 2000 chars to Oracle 10g - error ORA-01461
Sorry, Small, yet crucial error in my mail At 11:00 29.7.2005 +0300, you wrote: - setting NLS_LANG to various values does seem to affect the behavior. I meant to write - setting NLS_LANG to various values does _not_ seem to affect the behavior. Teemu Kivioja -- Teemu Kivioja, Research Scientist VTT Biotechnology P.O. Box 1500, FIN-02044 VTT, Finland (Street address: Tietotie 2, Espoo, Otaniemi) Email: [EMAIL PROTECTED] Phone: +358 20 722 7111 Fax: +358 20 722 7071
Re: Seeking *non* thread-friendly DBD
On 22 Jul 2005, at 12:30, Dean Arnold wrote: Hoping someone can point me at a DBD thats known to be non-thread-friendly (ie, hasn't implemented the clone() methods). However, its underlying client libs and XS subs (if any) do need to be thread-capable (ie, no writing to process-global variables wo/ locking). I'm trying to test out a theory that DBIx::Threaded will make non-thread-friendly DBD's not only friendly, but thread-safe. DBD::SQLite.
Re: Need Help with Unicode on ActivePerl 5.8.6, MS SQL 2000
On Thu, Jul 28, 2005 at 04:14:16PM +0200, Alexander Foken wrote: Hello, A large Perl application (10^4 .. 10^5 lines of code) has to work with data on an MS SQL Server 2000 containing Unicode data in NVARCHAR columns. Perl 5.8.6 (ActivePerl) runs on the same or another Windows 2000 Server (usually english or german). The Unicode data may contain characters from all over the world, e.g. russian, chinese, arabic or hebrew, among the usual latin characters. A separate application also accesses the Database, performs some reporting and expects the data to be valid Unicode. DBD::ODBC returns all latin characters, german umlauts and french accents, but replaces all non-latin characters with question marks (?, ASCII 63). Also, all data returned from DBD::ODBC has the UTF8 flag off. I spent three days searching Google, DBI docs and FAQ, and DBI and DBD::ODBC sources for any hints, but without success. Any ideas, hints, tips? I'd suggest you work with the maintainers of DBD::ODBC to fix it and help save the world. Tim.
Re: Storable problem with DBI::ProxyServer
Hi, let me resend my request hoping there is the one who can point at the solution of the problem. There are two machines: computer1 and computer2. Parameters of computer1: perl 5.6.1 sname=solaris, osvers=2.8, archname=sun4-solaris-thread-64int-ld DBI 1.41 DBI::ProxyServer 0.3005 DBD::Oracle 1.16 DBD::Proxy 0.2004 RPC::PlServer 0.2018 RPC::PlClient 0.2018 Storable 2.11 Parameters of computer2: perl 5.8.0 osname=linux, osvers=2.4.21-23.elsmp, archname=i386-linux-thread-multi DBI 1.48 DBI::ProxyServer 0.3005 DBD::Oracle 1.16 DBD::Proxy 0.2004 RPC::PlServer 0.2018 RPC::PlClient 0.2018 Storable 2.15 I have dbiproxy daemon running on computer1 with standard configuration. Unfortunately, from time to time while connecting from computer2 it crushes with an error: == Child died: Storable binary image v2.7 more recent than I am (v2.6) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 369 thread 373, at /usr/local/lib/perl5/site_perl/5.6.1/RPC/PlServer/Comm.pm line 179 thread 373 == After that I have to restart daemon to make dbiproxy work again. Why is that? Which modules these versions (2.7 and 2.6) concern? Both Storable modules have different versions. How can I avoid it? There is also one interesting thing. I have two identical scripts on computer1 and computer2 testing my dbiproxy connection. Let's call them testproxy_comp1.pl and testproxy_comp2.pl. After restarting dbiproxy deamon testproxy_comp2.pl fails because of: == Cannot log in to DBI::ProxyServer: Unexpected EOF from server at /usr/lib/perl5/site_perl/5.8.0/RPC/PlClient.pm line 79' == Then I run testproxy_comp1.pl and it is OK. After that I run testproxy_comp2.pl again and now it runs with no errors. Is anybody able to explain that strange situation? Thank you for your help in advance. Wojciech Pietron
ANNOUNCE: IBM Informix Database Driver for Perl DBI Version 2005.02 (2005-07-29) released
IBM Informix Database Driver for Perl DBI Version 2005.02 (2005-07-29) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.8.5, you should be planning to upgrade to it). You will need the code for DBI version 1.38 or later as well (v1.48 recommended). 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 [EMAIL PROTECTED] ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2005.02: * The changes here are all related to improved diagnostics during the build process. For example, esqlcc works in debug mode once more. * Fix bug with INT8 handling on 64-bit platforms. * Identify dubious Solaris linker flags (-z ignore is the trouble maker; -z lazyload is the memorable one; -z combreloc usually occurs with them and might or might not be damaging). * Identify dubious AIX compiler flags (-qlanglvl=ansi). * Add DBD_INFORMIX_NO_RESOURCE environment variable for under-privileged Informix users (those with CONNECT privilege only). * Add DBD_INFORMIX_NO_DBCREATE environment variable for a different class of under-privileged users (those not permitted to create databases because of ONCONFIG parameter DBCREATE_PERMISSION). * These mean that if there is a database to which you can connect, you can test DBD::Informix and have good (though not perfect) confidence that all is OK. New in release 2005.01: * Various minor bug fixes made as reported - see ChangeLog. * Release required to handle Informix ClientSDK 2.90, which includes ESQL/C 2.90. The previous release (CSDK 2.81, included ESQL/C 9.51), and the older DBD::Informix compilation based decisions off the ESQL/C version, rejecting 2.90 as obsolete and unusable. * Note that a number of obsolete versions of ESQL/C are no longer supported. Known problem: * t/t91udts.t sometimes warns about an uninitialized variable on subroutine entry. It seems to be harmless - but it is very irksome. Support email address: * This release is supported by Jonathan Leffler [EMAIL PROTECTED]. * 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 [EMAIL PROTECTED]; they also get sent to [EMAIL PROTECTED], etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) @(#)$Id: Announce,v 2005.3 2005/07/29 00:19:34 jleffler Exp $
