Re: IN in WHERE-clause is not being parsed correctly using SQL::Statement
> Am 12.05.2020 um 21:49 schrieb Provensal, Jerome : > > Hi Jens, > I was hoping that you could help me with an issue I’m having with > SQL::Statement. > > My goal is to make transitioning from Sybase to MySQL a breeze by converting > Sybase-like SQL statements into MySQL statements. > For that, I was planning on using SQL::Statement. > > While evaluating the module, I ran into an issue with the “IN” predicate. > I posted a “request for help” on SO: > https://stackoverflow.com/questions/61743167/in-in-where-clause-is-not-being-parsed-correctly-using-sqlstatement > > <https://stackoverflow.com/questions/61743167/in-in-where-clause-is-not-being-parsed-correctly-using-sqlstatement> > but so far without much luck. > I was hoping that going to the “source” (i.e. you) would help. > > Please help. Any insight would be greatly appreciated! > > Thanks! > > > This message, including any attachments, is intended only for the personal > and confidential use of the designated recipient(s) to which it is addressed. > This communication may contain information that constitutes attorney work > product, is privileged, confidential or otherwise protected from disclosure. > If the reader of this message is not the designated recipient, you are hereby > notified that you have received this communication in error, and that any > review, dissemination, retention, distribution or copying of this > communication is strictly prohibited. If you have received this communication > in error, please notify us by e-mail reply to the sender, and discard any > paper copies and delete all electronic files of this communication. Virtu > Financial LLC <http://www.virtu.com/>. > > FOR CANADIAN RECIPIENTS: Securities products and services provided to > Canadian investors are offered by Virtu ITG Canada Corp., a subsidiary of > Virtu Financial, Inc. and member Canadian Investment Protection Fund (“CIPF”) > and the Investment Industry Regulatory Organization of Canada (“IIROC”). In > accordance with Canadian Anti-Spam Legislation, this communication has been > sent to you on the basis that Virtu ITG Canada Corp. or its affiliates > (collectively, “Virtu”) has implied consent from you as a member of the > investment community, with whom Virtu has an established business > relationship or through which your email address has been made available to > Virtu. However, if you wish to stop receiving electronic communications from > Virtu ITG Canada Corp. or its affiliates, please click here > <mailto:can-c...@virtu.com?subject=Unsubscribe%20request>. Please note that > we may not be able to accommodate this request for existing clients, where > Virtu is required under securities laws or any other applicable regulations > to send certain electronic communications related to your account. > -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: Wrt. [DBD-AnyData] Repository cleanup (#1)
Nigel, > Am 11.02.2020 um 17:47 schrieb Nigel Horne,, : > > I like that module and will be sad to see it go. If you want I'll happily > take it over. it doesn't work anymore. And there is a drop-in replacement. I don't know what's the expectation. Can you explain that a bit? DBD::AnyData is there if anyone has old software which needs the old module with the old API sing with old perl and old DBI. > -Nigel > > On 11/2/20, 11:45, "Jens Rehsack" wrote: > >Hi Olivier, > > >wrt. https://github.com/rehsack/DBD-AnyData/pull/1 > >In case you really need DBD::AnyData and DBD::AnyData2 won't do at all, > please let's sit together (virtually ^^) and figure out how to help you. >DBD::AnyData won't work with recent DBI (I'd say for any DBI newer than > 2012) - and likely even before then ;) > >IIRC, it is marked deprecated on CPAN. > >Best regards >-- >Jens Rehsack - rehs...@gmail.com Best regards, -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Wrt. [DBD-AnyData] Repository cleanup (#1)
Hi Olivier, wrt. https://github.com/rehsack/DBD-AnyData/pull/1 In case you really need DBD::AnyData and DBD::AnyData2 won't do at all, please let's sit together (virtually ^^) and figure out how to help you. DBD::AnyData won't work with recent DBI (I'd say for any DBI newer than 2012) - and likely even before then ;) IIRC, it is marked deprecated on CPAN. Best regards -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: perl issue
[124]: : remote process on 'sydcosafpp001.enterprisenet.org <>'
> terminated unexpectedly [124]: ERROR: [124]: process terminated due to an
> unhandled exception:
> Can't load '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so' for module
> DBD::Pg: libpq.so.5: cannot open shared object file: No such file or
> directory at /usr/lib64/perl5/DynaLoader.pm line 190.
> at /loader/0x23c3528/pgBackRest/Db.pm line 10.
>
>==> pwd
> /usr/lib64/perl5
> postg...@sydcosausd001.enterprisenet.org <>:/usr/lib64/perl5
> ==> ls
> arybase.pm <> bits CORE Fcntl.pm _h2ph_pre.ph <> lib.pm <> NDBM_File.pm
> perllocal.pod stdarg.ph <> syslimits.ph <> Unicode
> asm B.pm Devel features.ph <> Hash linux ODBM_File.pm POSIX.pm stdc-predef.ph
> <> syslog.ph <> vendor_perl
> asm-generic Config_git.pl Digest File I18N machine Opcode.pm POSIX.pod
> stddef.ph <> Text wait.ph <>
> attributes.pm <> Config_heavy.pl DynaLoader.pm Filter IO Math O.pm re.pm <>
> sys Tie xlocale.ph <>
> auto Config.pm endian.ph <> GDBM_File.pm IO.pm MIME ops.pm <> SDBM_File.pm
> Sys Time
> B Config.pod Errno.pm gnu IPC mro.pm <> PerlIO signal.ph <> syscall.ph <>
> time.ph <>
> more A4_sydcosafpp001-restore.log
>
> 2019-05-02 14:50:00.028 P00 INFO: restore command begin 2.10:
> --log-level-console=detail --pg1-path=/pgDATA/datanew
> --repo1-host=sydcosafpp001.enterprisene
> t.org <> --repo1-host-config=/etc/pgbackrest.conf --repo1-host-user=postgres
> --repo1-path=/pgBACKUP/A4_sydcosafpp001 --stanza=A4_sydcosafpp001
> --target="2019-05
> -01 10:58:18.00+01" --type=time
> 2019-05-02 14:50:07.930 P00 ERROR: [124]: remote process on
> 'sydcosafpp001.enterprisenet.org <>' terminated unexpectedly [124]: ERROR:
> [124]: process terminate
> d due to an unhandled exception:
> Can't load '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so' for module
> DBD::Pg: libpq.so.5: cannot open shared
> object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line
> 190.
> at /loader/0x1623548/pgBackRest/Db.pm line 10.
> at /loader/0x1623548/pgBackRest/Main.pm line 12.
> pgBackRest::Main::ANON('Can't load
> '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so...') called at /usr
> /share/perl5/vendor_perl/Carp.pm line 100
> Carp::croak('Can't load '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so...')
> called at /usr/lib64/perl5/Dy
> naLoader.pm line 98
> DynaLoader::croak('Can't load
> '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so...') called at /usr/lib64/pe
> rl5/DynaLoader.pm line 190
> DynaLoader::bootstrap('DBD::Pg', 'version=HASH(0x1f9a938)') called at
> /usr/lib64/perl5/vendor_perl/DBD/Pg.pm
> line 73
>
>
> --
>
>
>
> Thanks,
> Prakash.R
> PostgreSQL - Offshore DBA support TCS / Nielsen Infrastructure Team On call :
> +91-8939599426
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
Released SQL::Statement 1.407
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 - rehs...@gmail.com
Re: Here is a classic one for you
Am 02.01.2015 um 16:29 schrieb The Doctor doc...@doctor.nl2k.ab.ca: On Fri, Jan 02, 2015 at 07:10:42PM +1100, Ivan Wills wrote: My technique for that is to add the following lines in DBI (say on line 283): use Carp qw/cluck/; cluck Here; And see what the stack suggests is going on. Ivan On 2 January 2015 at 10:53, The Doctor doc...@doctor.nl2k.ab.ca wrote: I start a programme with a DBI dependency and I get: Can't locate object method bootstrap via package DBI at /usr/contrib/lib/perl5/site_perl/5.18.2/i386-bsdos/DBI.pm line 277. BEGIN failed--compilation aborted at /usr/contrib/lib/perl5/site_perl/5.18.2/i386-bsdos/DBI.pm line 284. No dice. All that happens is that 284 becomes 286. But bootstrap wasn't found in line 277 :) So you're fortune might improve by moving the debug code a few lines upwards ... All right the bs file exists. The .bs file is mostly irrelevant - the DBI.so file counts ... Did you check `file /usr/contrib/lib/perl5/site_perl/5.18.2/i386-bsdos/auto/DBI/DBI.so`? What else is not correct? How do I do a debug on this? http://www.lmgtfy.com/?q=Can%27t+locate+object+method+%22bootstrap%22+via+package Cheers -- Jens Rehsack rehs...@gmail.com
Re: Escaping placeholders
Am 20.12.2014 um 23:10 schrieb Tim Bunce tim.bu...@pobox.com: On Sat, Dec 20, 2014 at 05:35:55PM +0100, Alexander Foken wrote: On 20.12.2014 15:38, Tim Bunce wrote: Can you, or anyone else, think of any situation where a backslash before a ? or :foo (or even $1) style placeholder might be valid SQL? I found two situations for PostgreSQL: (1) PostgreSQL allows almost any character as escape character in Unicode string constants (http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE). With that, I can construct an expression containing \:foo that is valid SQL as understood by PostgreSQL: U'foo\:bar' UESCAPE ':' This expression represents the string foo\Xbar, where X is the Unicode character U+ (TAI VIET LETTER LOW VO). I don't think that'll be a problem because the driver code that parses the statement looking for placeholders will skip over quoted strings. Sure, strings can be manipulated on language level, no need for driver to interfere. (2) PostgreSQL also allows Dollar quoting (http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING). With that, I can construct an expression containing \$1 that is valid SQL as understood by PostgreSQL: $1$foo\$1$ This expression represents the string foo\, quoted by dollar signs using the character 1 as tag. I'm not sure if the driver code that parses statements in DBD::Pg handles dollar quoting. I presume so. In which case this shouldn't be a problem either for the same reason as above. So far no one has come up with one, so I'm getting more comfortable with the idea that a backslash before a placeholder is a safe change. I.e., there's a near-zero risk that upgrading a DBI driver to support backslashes would cause breakage in existing code. Do you plan to escape the escape character, i.e. use a double backslash at DBI level to represent a single backslash at database level? That's a good question. I'm not sure. I think the answer has to be no. I'd welcome any input on that. We have a dictum (translated word by word ...): One can't even think as foolish as it sometimes happens. When escaping is specified, escaping the escape character itself should be mandatory - just for being complete and do not ask for future trouble. Of course - outside of quotes only. Cheers -- Jens Rehsack rehs...@gmail.com
Re: DBI - DBD - mysql on Yosemite
Am 28.10.2014 um 17:45 schrieb Michael Ahrweiler m...@versale.de: Hello Hi Michael, It is not, that it does not function. It did. It was just not starting by itself. So I updated. Since then, it’s a mess. After installing the latest mysql community-version 5.6.21 On make test of DBD I get: # Failed test 'use DBD::mysql;' # at t/00base.t line 18. # Tried to use 'DBD::mysql'. # Error: Can't load '/temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.18.dylib Where is this libmysqlclient.18.dylib from? What is /temp? What says 'otool -L /temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle'? # Referenced from: /temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle # Reason: image not found at /System/Library/Perl/5.18/darwin-thread-multi-2level/DynaLoader.pm line 194. # at (eval 8) line 2. If I do the install all the same I get (more or less) the same error-message on my web-pages using perl-DBI-DBD. I fumbled arount a lot… - with libmysqlclient.18.dylib - with old DBI DBD installation pouring over what was installed (getting „an error occurred“ for loading shtml-pages with DBI DBD mysql-content) - which might be better but… - with installing oder version of DBI and DBD (with the same error in make test) I am out of „ideas“. Is this a yosemite thing? For instance harder sandbox something? Any ideas ? Not enough information (at least for me)... Makes me fear updating to Yosemite ^^ Is there a path ? There is always a path - but what dedicated path are you looking for? Cheers -- Jens Rehsack rehs...@gmail.com
Re: SQL Parser
Am 28.04.2014 um 07:28 schrieb Gustavo Castro cris7ian.gus7...@gmail.com: Hi! I have a doubt using SQL Parser Module (Link) I need to implement the command CREATE DATABASE because this module only implements CREATE TABLE. Thank you very much for your answer. Hi, currently all SQL::Parser based DBD’s support only one Database which has to be specified at connection. That’s why there’s no need for a „CREATE DATABASE“. Depending on you’re goals you can derive from SQL::Parser and add support for a create database statement (if you want to continue with SQL::Statement), or - when just parsing is required - check what ribasushi has in his portfolio. IIRC, he has several SQL parsing packages which are much more advanced than SQL::Parser. Best regards and good luck -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK
Re: I have a weird issue with a script running under cron
Am 17.02.2014 um 23:43 schrieb Bruce Johnson john...@pharmacy.arizona.edu: On Feb 17, 2014, at 2:48 PM, John D Groenveld jdg...@elvis.arl.psu.edu wrote: In message 5302803c.4080...@triad.rr.com, Richie writes: Is LD_LIBRARY_PATH exported? It's hard to see whats going on without a full test case. The OP shouldn't need to set a LD_LIBRARY_PATH so long as he built DBD::Oracle with the correct runtime link path, but a simple shell script to see which libraries aren't resolving would be a useful test: #!/bin/ksh /bin/env - /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so Everything works on the command line interactively. The error only happens when the script is run via cron; however the ORACLE_HOME and LD_LIBRARY_PATH variables appear to be set correctly. This is a fairly lengthy script that hits tables in use during working hours, yet depends on remote databases not available to me most of the nights, so it may take a few days to work through checking stuff since I only have about two hours a day when I can actually run it :-) Am 17.02.2014 um 19:42 schrieb Jens Rehsack rehs...@gmail.com: Hi Bruce, try an ldd on /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so and any dependent library beside standard library paths to see what might be missing. Optionally a locate for libocci.so.11.1 might be helpful. If nothing else helps, try to answer my questions, please :) Cheers -- Jens Rehsack rehs...@gmail.com
Re: I have a weird issue with a script running under cron
Hi Bruce, Am 17.02.2014 um 19:30 schrieb Bruce Johnson john...@pharmacy.arizona.edu: I get the following error: install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200, DATA line 749. at (eval 10) line 3 Compilation failed in require at (eval 10) line 3, DATA line 749. Perhaps a required shared library or dll isn't installed where expected at /home/allwebfiles/perl/kfs/kfsupdate.pl line 21 The script runs just fine when run interactively in a shell. This normally means an issue with Oracle environment variables, but I wrote another script that simply lists %ENV. When run in the same crontab I get: Environment variables HOME = /root LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib LOGNAME = root ORACLE_HOME = /usr/lib/oracle/11.2/client64 ORACLE_SID = phmweb PATH = /usr/bin:/bin PWD = /root SHELL = /bin/sh SHLVL = 1 USER = root _ = /home/allwebfiles/perl/kfs/showenvcron.pl These are the correct values. So what am I missing? try an ldd on /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so and any dependent library beside standard library paths to see what might be missing. Optionally a locate for libocci.so.11.1 might be helpful. Cheers -- Jens Rehsack rehs...@gmail.com
Re: A question about DBI
Am 10.09.2013 um 21:45 schrieb Curtis Leach cle...@caesars.com:
Hello,
Aloah /o\
I’m having issues trying to query flat files using DBI DBD::CSV. I’m
currently upgrading from v5.8.8 to v5.16.3 and with the latest Perl platform
my code no longer works. I’m running on various Windows platforms.
I’m going to Strawberry Perl v5.16.3 (32-bit)
DBI 1.628(upgraded core module)
DBD-CSV 0.41
SQL-Statement 1.405
Text-CSV_XS 1.01
From: Active State Perl v 5.8.8
DBI 1.49
DBD-CSV 0.22
SQL-Statement 1.14
Text-CSV_XS 0.23
Here is a code sample that reproduces my issue:
my %attr = (PrintError = 0, RaiseError = 1, AutoCommit = 1);
my $dbh = DBI-connect (DBI:CSV:csv_sep_char=|;csv_eol=\n, , , \%attr);
$dbh-{csv_tables}-{logs} = { 'file' = basename ($src_file) };
Please use f_file instead of file (see Changes).
For a long time, file was handled as a depreciated flag and was mapped to
f_file.
It might be removed sooner or later (or maybe is, see alias def in
DBD::File::Table).
$dbh-{f_dir} = dirname ($src_file);
It might help to do move this line before the csv_tables meta initialization
(do global init before local init).
my $sql = SELECT File, Extension, Directory, Message from logs where Status
= .
$dbh-quote (ERROR) . ORDER BY Time;
my $sth = $dbh-prepare ( $sql );
$sth-execute ();
I turned on tracing (level 2) and according to the error message the file I’m
trying to find isn’t being found.
It looks like the query is ignoring the setting of “f_dir”. It’s instead
looking for the file in the current directory, which isn’t what “f_dir”
points to! (The trace acknowledges f_dir is pointing to the correct location)
So if I manually run the code from the location where the log file is
located, everything works.
So I see one of two things being true:
1) “f_dir” is being ignored.
Only for table logs, because logs's f_dir is initialized before you set it.
2) There is a problem with how I initialized things.
Indeed. You should really carefully study the Changes since DBI 1.49,
also for SQL::Statement since 1.405.
Can anyone comment about which is the real issue? With the files I’m
querying all over the place, putting chdir’s all over my code isn’t really a
good option.
Curtis Leach
Lead Engineer
RMS IT ERM IT
Phone: (702) 494-4562
image001.jpg
dbitrace.log
Cheers
--
Jens Rehsack
pkgsrc, Perl5
rehs...@cpan.org
Announcing DBI-Test 0.001
Hi, hereby I proudly announce DBI::Test-0.001. It's ready to be used for converting DBD tests as well as create generic basic DBI test. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: cross database queries?
On 26.06.13 14:26, Andrew Snyder wrote: I want to write a query like: select clients.client.client_id, columnar.sales.total_sales, web.page_hits from clients, columnar, web where clients.client_id = columnar.client_id and clients.client_id = web.client_id in a system where 'clients' is actually one or more relational databases, 'columnar' is one or columnar databases, and 'web' is the Apache logs on one or more web servers. The dbi driver would be configured to connect to the correct databases and filter web hits based on 'client_id'. Has somebody written that already? As far as I understood: yes. The professional solution is available from http://www.easysoft.com/index.html When you're willing to write some pieces of code, SQL::Statement and DBI::DBD::SqlEngine will help. But in that case - all data is fetched into a Perl based SQL engine and I can confirm that it's highly unoptimized regarding mass data ... Cheers -- Jens Rehsack
Re: cross database queries?
On 26.06.13 15:25, David Nicol wrote:
On Wed, Jun 26, 2013 at 7:26 AM, Andrew Snyder a...@dancingjars.com
mailto:a...@dancingjars.com wrote:
I want to write a query like:
select clients.client.client_id, columnar.sales.total_sales,
web.page_hits from clients, columnar, web
where clients.client_id = columnar.client_id
and clients.client_id = web.client_id
in a system where 'clients' is actually one or more relational
databases, 'columnar' is one or columnar databases, and 'web' is the
Apache logs on one or more web servers. The dbi driver would be
configured to connect to the correct databases and filter web hits
based on 'client_id'.
Has somebody written that already?
Thanks,
Andrew
it seems like the right thing to do here would be to do three queries,
against the three data sources, and store all the results in a hash of
arrays, then dump the results. Any solution that automates it will wind
up doing at least that anyway, and might not be optimized for the join.
S::S is not bad in joining tables - it's bad in optimizing queries.
I cannot fetch the smalles table first or first query those tables which
have constants in where clauses. So bad queries might cause gigabytes
on memory are wasted for resulting 50 lines.
That is what I meant by not optimized :)
Unless there really are so many client IDs that you need to process the
results as a stream or run out of memory, which is unlikely.
while (my ($c_id, $ar) = each %resultz){
$ar-[0] or next; # filter out client_id not appearing in
clients database
print join( \t, $c_id, 0+$ar-[1], 0+$ar-[2]),\n;
}
Well - even if not optimized, the implementation of SQL::Statement is
even better. And the datasources for S::S are easy to write - it
finally requires an open_table and fetch_row method.
Two parallel hashes containing the web and columnar results, accessed
once for each result from querying the clients table, would also work.
Yes, that's something S::S can't do out of the box. But it could do, I
have a version of DBD::Sys where during open_table() the query is send
against the data-sources and first fetch_row() synchronized the results
of the appropriate queries.
Cheers
--
Jens Rehsack
Re: Relevance of ChildHandles
On 08.05.13 00:05, Tim Bunce wrote: [...] At this stage in the life of the DBI I think it's reasonable to assume that there isn't a leak in the DBI itself. If there was then a lot of people would be affected and complaining about it. I think this assumption is heavily wrong. From my jobs I learned one thing the last years: do it quick. To illustrate what I mean saying that, see following exampple. In a particular project we had the issue, that every monday morning our web-interface was inoperable because of an invalid $dbh (which was cached). The question from our manager was: can you say in 10 minutes why and how to fix and can you guarantee fix it until lunch? Otherwise - implement a cron controlled web-server restart each morning at 5. Because of personal interests I debugged later into it (and fixed it a few weeks later - guaranteed) ... What I'm trying to say - when administrators see there web-server machines running out of memory, the implement a scheduled restart in the pool of machines. I really don't know business relying on web-services running qualified monitoring with performance measurement (some do, but don't know what they measure and finally one company really does). Sorry for complaining ;) Cheers -- Jens Rehsack
Re: Issues installing DBD::Teradata on AIX server
On 23.04.13 01:19, Sunil Palepu wrote: Hi - ++ We had installed DBI on the AIX server but unable to install DBD::Teradata on the same server. My Unix admin is seeing Memory fault(coredump) error and wondering if someone can help me out. I did install this on the Linux servers in the past but this is my first time installing DBI on AIX. How did you install that DBI? Which compiler did you use? Which compiler flags. Did you modify the system perl (read: where is DBI installed?) or used local::lib? OS : AIX Perl version is : v5.8.8 DBI version : DBI-1.625 DBD version : DBD-Teradata-1.52 $ sudo perl Makefile.PL *** Configuring DBD::Teradata (feature-limited free edition)... *** * * !!!NOTE TO INSTALLERS!!! * * DBD::Teradata will be built using the following * directives: * Libraries: -L/usr/lib -lcliv2 -lnet -lsocket -lresolv -ltdusr.so * Include files: * Compile flags: -D__error_t_defined=1 * * If your CLI2 libraries and/or include files are in another * location, please update the TDAT_DBD_CLI_LIB and * TDAT_DBD_CLI_INC environment variables before running * Makefile.PL. * *** Memory fault(coredump) You should probably trace where it crashes - and you should NEVER run Makefile.PL as root. Thanks in advance ' welcome Cheers -- Jens Rehsack
Re: Building DBD-Oracle on MacOS 10.8 with instantclient_11_2
On 29.03.13 18:10, Philippe Causse wrote: Hello, Hi Philippe, I would like to provide some feedback which may be useful for build of DBD-Oracle. [...] And now it works :-) Cool /o\ I hope this information may be useful -- eventually as an addition to this document http://search.cpan.org/dist/DBD-Oracle/lib/DBD/Oracle/Troubleshooting/Macos.pod I hope so - it's on Yanick and Martin to decide it. Regardless that decision, I'm impressed about the details and clearity of your mail and I'm sure the one or other search bot will index http://www.nntp.perl.org/group/perl.dbi.users/ and a web-search will point to that message and increase your fame and karma. Thank you very much -- Jens Rehsack
SQL::Statement 1.402 uploaded
Hi, SQL::Statement 1.402 has been uploaded to PAUSE and should be updated where ever possible. Version 1.402, released December 19, 2012 - [Misc] * add Math::Complex 1.56 as recommendation (RT#81926, Sam Ferencik) * add Math::BigInt 1.88 as recommendation (RT#81927, Sam Ferencik) * clarify Test::Simple 1.90 is required for building (RT#81925, Sam Ferencik) [Bug fixes] * fix leaking reference to open tables outside SQL::Statement::execute (fixes RT#81523) * looks_like_number identifies 'nan' as number sometimes (add regex to t/06virtual.t) The bug described in RT#81523 might result in invalid (outdated) data return from SQL::Statement. Upgrading is strongly recommended. Cheers -- Jens Rehsack
Fwd: SQL::Statement (SQL-Statement-1.402_002)
Original Message
Subject:SQL::Statement (SQL-Statement-1.402_002)
Date: Wed, 19 Dec 2012 15:53:31 +0100
From: Thomas Binder tcb...@gmail.com
To: rehs...@cpan.org
Hi there,
I have a little problem with SQL-Statement.
I installed it on two different systems (Linux+Windows) using Perl v5.14.
The installation went w/o a hitch, also make test showed no issues :
All tests successful.
Test Summary Report
---
t/06virtual.t(Wstat: 0 Tests: 677 Failed: 0)
TODO passed: 587-589
t/08join.t (Wstat: 0 Tests: 321 Failed: 0)
TODO passed: 289-291, 293-295, 314, 316, 318, 321
Files=16, Tests=1639, 7 wallclock secs ( 0.55 usr 0.06 sys + 6.92
cusr 0.30 csys = 7.83 CPU)
Result: PASS
However, when I try your example from the docs of SQL::Statement::Structure
use SQL::Statement;
my $sql= SELECT a FROM b JOIN c WHERE c=? AND e=7 ORDER BY f DESC
LIMIT 5,2;
my $parser = SQL::Parser-new();
$parser-{RaiseError}=1;
$parser-{PrintError}=0;
# $parser-parse(LOAD 'MyLib::MySyntax' );
my $stmt = SQL::Statement-new($sql,$parser);
printf Command %s\n,$stmt-command;
printf Num of Placeholders %s\n,scalar $stmt-params;
printf Tables %s\n,join( ',', map {$_-name}
$stmt-tables() );
printf Where operator %s\n,join( ',', $stmt-where-op() );
printf Limit %s\n,$stmt-limit();
printf Offset %s\n,$stmt-offset();
printf Columns %s\n,join( ',', map {$_-name}
$stmt-column_defs() );
I get this result :
Command SELECT
Num of Placeholders 1
Tables b,c
Where operator AND
Limit 2
Offset 5
Can't call method name on unblessed reference at test.pl
http://test.pl line 14.
So, I'm unable to use *column_defs()* correctly. Any idea ?
I would be happy, to hear from you.
Best regards A Merry Christmas
Thomas Binder
Re: DBD::CSV on MacOSX Lion using cpanm fails to $r-fetch in t/50_chopblanks.t line 41
On 30.11.12 09:49, Allen van der Ross wrote: Hi Jens, Hi Allen, am I allowed to ask why you're writing to my NetBSD.org address instead of my CPAN address? At first I looked for a mistake I made last DBI/DBD::* update for pkgsrc ;) I've installed all the prerequisites, Congrats ;) but using cpanm DBD::CSV fails on the tests: simba:db allen$ cpanm -v DBD::CSV cpanm (App::cpanminus) 1.5008 on perl 5.014002 built for darwin-2level Work directory is /Users/allen/.cpanm/work/1354261809.36053 You have make /usr/bin/make You have LWP 6.04 You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3 You have /usr/bin/unzip Searching DBD::CSV on cpanmetadb ... -- Working on DBD::CSV Fetching http://search.cpan.org/CPAN/authors/id/H/HM/HMBRAND/DBD-CSV-0.36.tgz ... OK Unpacking DBD-CSV-0.36.tgz skipped lots of stuff here t/50_chopblanks.t ... 2/? # Failed test 'fetch' # at t/50_chopblanks.t line 41. # Failed test 'content' # at t/50_chopblanks.t line 42. # Structures begin differing at: # $got = undef # $expected = ARRAY(0x7fc2b4385290) # Failed test 'fetch' # at t/50_chopblanks.t line 41. # Failed test 'content' # at t/50_chopblanks.t line 42. # Structures begin differing at: # $got = undef # $expected = ARRAY(0x7fc2b41ab938) # Looks like you failed 4 tests of 65. t/50_chopblanks.t ... Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/65 subtests Looks as if you should join RT#81523 (https://rt.cpan.org/Ticket/Display.html?id=81523). If you're able to try out and send us Feedback using the current Repository HEAD revision from http://repo.or.cz/w/DBD-CSV.git (we enhanced the test because we can't reproduce on Mountain Lion). Here are the version of Perl and the related modules… simba:db allen$ perl -v This is perl 5, version 14, subversion 2 (v5.14.2) built for darwin-2level Copyright 1987-2011, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. simba:db allen$ perl -MSQL::Statement -E 'say $SQL::Statement::VERSION' 1.401 simba:db allen$ perl -MText::CSV_XS -E 'say $Text::CSV_XS::VERSION' 0.93 simba:db allen$ perl -MDBI -E 'say $DBI::VERSION' 1.618 simba:db allen$ Looks fine, even if DBI could be newer - but that's not the reason. The Mac OSX Lion version is 10.7.5 How do I resolve this problem or is there something I can do to help you resolve this problem? Best thing you can do is help us figuring out what really goes wrong. We don't know what fails and why (Merijn, please correct me if I'm wrong), but we're willing to investigate. Regards, Allen. Cheers, Jens
Re: DBD::CSV and skip_first_line
On 25.11.12 10:00, H.Merijn Brand wrote: On Fri, 23 Nov 2012 17:43:50 -0500, Scott R. Godin scot...@mhg2.com wrote: I've run into an issue where I need both col_names set and skip_first_line still set to TRUE, because of malformed colnames in the original dumpfiles that conflict with SQL Reserved Words (such as 'key') that I am unable to find any other acceptable workaround short of Why not automate the hacking using Text::CSV_XS and rewrite the header before using DBD::CSV? Or simply quote the column names in your SQL statement? hacking the dumpfiles prior to import for unit-testing and validation prior to splitting the dumpfiles out into a normalized sql database. (I'll eed to hand this off to someone else for future dump-and-import work, so it's just got to WORK with these ACCESS database dump files as-is, plus HIPAA rules about not changing data complicates matters) Is there any way to ensure that despite col_names being set, I can still force skip_first_line = 1 ? or should I report this as a possible edge-case bug There should be, and it is likely that this case is already fixed in the current development state of DBD::CSV by the valuable work of Jens Rehsack, but that state is not (yet) releasable as it depends on changes in SQL::Statement and DBI (DBD::File). Well, since we're both busy - we need to find an hour or so to integrate. I do not expect a general issue with DBI-1.622, I expect some edge cases we need to tidy up. to sum up, col names present in csv but bad (sql reserved words) can use col_names = [ @ary ], but this sets skip_first_line to FALSE as it *assumes* that colnames are NOT present in original dump what do ? :) Rewrite the headers with Text::CSV_XS before using DBD::CSV Or simply quote the reserved cols :) Cheers -- Jens Rehsack
SQL::Statement 1.401 is out
Hi, hereby I announce the SQL::Statement 1.401 release containing following changes: Version 1.401, released October 29, 2012 - [Misc] * Switch to 3-digited minor version [Bug fixes] * undo literal replaces in subqueries before passing them to the child parser * Fix doc typo RT#76764 (STEFFENW) - thanks Steffen * Fix typo documented in RT#71914 (reported by Ze'ev Atlas, fixed by H.Merijn Brand) - thanks Ze'ev and Merijn * Fix DROP TABLE behaviour and error detection [Improvements] * Improve documentation/tests for multiple JOIN's from RT#69573 (from BBYRD) with modifications * Filling in the SQL92 gaps for functions (BBYRD) from RT#72638 with minor modifications - thanks Brendan A big thanks for the most impressive change in this release goes to Brendan Byrd - he contributed a very big patch for a lot of SQL92 compatible functions. It wasn't easy to integrate and needed some turnarounds in testing but finally makes SQL::Statement a lot better. Thanks a lot in the name of all SQL::Statement users, Brendan. Best regards, Jens
Re: error: software package not installed
2012/10/16 John R Pierce pie...@hogranch.com: On 10/15/12 2:15 AM, Darvesh Kumar wrote: plz give me solution for this problem, log installation is given below- install Oracle Studio (assuming this is Solaris). or read about CPAN on Solaris Perl and using GCC, here... http://search.cpan.org/~jesse/perl-5.12.1/README.solaris http://search.cpan.org/%7Ejesse/perl-5.12.1/README.solaris It is always a good idea to use the same compiler for Perl and Perl-Modules. Want keep /usr/bin/perl leads to Solaris Studio, want gcc leads to build your own Perl. If you're developing a product which must run on Solaris, it's highly recommended to build and deploy own version of Perl and DBI you can rely on. I use pkgsrc (http://www.pkgsrc.org/) for application I create for my customers. I bundle all dependencies in /opt/product_name - which allows me to do easy staging processes. Best regards, Jens
Re: dbd-anydata v0.09 on windows - INSERT doesnt add new records
On 11.05.2012 02:07, Greg Aiken wrote:
dear jeff and jens,
i found your wonderful dbd-anydata module and installed it to my windows
activeperl 5.8.8 build 820 environment (on Windows XP 32 bit)
Probably you should install a more recent version of DBD::AnyData.
As I can see in CPAN (http://search.cpan.org/dist/DBD-AnyData/),
DBD-AnyData-0.110 is the current version.
Without further information about the used DBI version, used
SQL::Statement version etc. pp., I can not even guess where
your problems comes from.
i am able to use it to READ data from a 'Tab' delimited file.
i have followed, almost verbatim, your sample code to INSERT new records
into such a file - but i can not get this to work.
there are 3 different code fragment attempts ive made. when each of
these three code blocks run (one at a time obviously), in all cases the
return code for the execute (or do) statement is 1 (true). yet none of
these actually results in a new record being added to the file
'oldfile.txt'. ive attached oldfile.txt as a zip file so you can see
its contents. its a simple 2 line ascii file - record 1 is the field
names, record 2 is a dummy data line.
if you can possibly figure out what i am doing wrong, i'd be greatly
indebted as i can see using your module frequently if i can get it to
output data.
Even if I don't like to loose happy users, for the recorded simple use
it's probably reasonable to use DBD::CSV. Don't bite on comma - the
separator is freely configurable.
Further: I'm sure, DBD::AnyData has a test which proves whether
inserting new rows will succeed or not. If not (I didn't prove), it
would be nice if you add such a test case (steal it from DBD::CSV,
DBD::DBM or simply SQL::Statement).
If you can send the test output (including the test, if it needs to be
added), it'll be more easy for us to help you.
Thanks for helping to improve DBD::AnyData. Please CC dbi-users@ to
allow the community to help you.
Best regards,
Jens
sincerely yours,
greg aiken
use DBI;
use DBD::AnyData;
my $dbh = DBI-connect('dbi:AnyData(RaiseError=1):');
#i am trying to insert new record to an existing tab delimited file
#'oldfile.txt' is an ascii encoded two line file:
#FIELD1\tFIELD2\n
#abc\tdef\n
$dbh-func('insertnewrecstooldfile', 'Tab', 'oldfile.txt', 'ad_import');
#test 1 - attempt using DO with hard-coded 'values'
#$return1 = $dbh-do(INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
VALUES ('ghi', 'jkl'));
#print return1 = $return1\n;
#$dbh-disconnect;
#exit;
#result: returns 1, but the file does NOT contain the new record!
#test 2 - next level of indirection, using scalar values in the sql
command
#$value1 = 'mno';
#$value2 = 'pqr';
#$sql2= qq{ INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
VALUES ('$value1', '$value2') };
#$return2 = $dbh-do($sql2);
#print return2 = $return2\n;
#$dbh-disconnect;
#exit;
#result: returns 1, but the file does NOT contain the new record!
#test 3 - to pass in vars
#by way of preparing placeholders for values, then execute
#$value1 = 'stu';
#$value2 = 'vwx';
#$sql3= qq{ INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
VALUES (?,?) };
#$sth3= $dbh-prepare($sql3);
#$return3 = $sth3-execute($value1, $value2);
#print return3 = $return3\n;
#$dbh-disconnect;
#exit;
#result: returns 1, but the file does NOT contain the new record!
Fwd: questions about SQL::Statement
Original-Nachricht
Betreff: questions about SQL::Statement
Datum: Mon, 19 Mar 2012 16:59:46 -0400
Von: Philip Goetz philgo...@gmail.com
An: rehs...@cpan.org
The module SQL::Statement doesn't work as your documentation describes.
There is no column_defs function defined.
There is a 'columns' function, but it returns an empty list.
For example:
use SQL::Parser;
use SQL::Statement;
my $query = SELECT a, b, c FROM bar;
our $SqlParser = SQL::Parser-new() or die Could not create an
SQL::Parser;
my $parse = SQL::Statement-new($query, $SqlParser);
# my @columns = $parse-column_defs(); -- crashes with Can't
locate object method column_defs via package SQL::Statement
my @columns = $parse-columns();
foreach my $col (@columns) {
my ($table, $name) = ($col-table(), $col-name());
print $table\t$name\n;
}
does not crash, but prints nothing.
Do you know how to retrieve the columns from an SQL::Statement object?
Thanks,
Phil
Re: SQL::Statement - how easy to subclass?
Am 16.03.2012 01:50, schrieb David Muir Sharnoff:
Hi.
Hi,
I want to build a SQL query translater for my OOPS module.
I want users reading the support section of the modules they use
or a business support contract when they want private or special
support.
I need an SQL parser for that I can modify so that it will accept perl
data expressions as terms.
For example:
select $x from objects where $x-isa('Foo') and $x-{field1} == 'bar'
The perl expressions can be parsed by PPI.
How easy is it to subclass SQL::Statement? Can I grab control of terms
and lists when I see a '$' or '@'?
I had a brief look and I saw some subclassing hooks, but it wasn't clear
that there were enough to do what I need.
As long as you want to parse SQL, it's easy. When you're going to mix
languages and the functions API of SQL::Statement doesn't fit your
requirements any more, you can develop a complete new parser. The API
requirements are mixed in the accessors of SQL::Statement - sorry, heritage.
Best regards,
Jens
Fwd: Problem to get UTF8-CSV-File
-- Weitergeleitete Nachricht --
Von: Ralf Eiteljörge ralf.eiteljoe...@prounix.de
Datum: 21. Dezember 2011 14:06
Betreff: Problem to get UTF8-CSV-File
An: rehs...@cpan.org
Hallo,
We have a problem. We want to get an UTF8-CSV-File from
UTF8-Oracle-Database. It seems to be that the CSV-File is always charset
latin-1. What can we do to get UTF-8-File?
Here is our Testscript.
#-- our Testscript#
#!/usr/local/bin/perl -w -C64 use strict;
use bytes;
use open IO = :utf8;
use DBI;
my %Param;
my $Select;
my $Dsn=dbi:Oracle:samsafe;
my $User=UU;
my $Passwd=XX;
$ENV{NLS_LANG}=GERMAN_GERMANY.AL32UTF8;
$Select=select
ku.knd_name1,ku.knd_name2,ku.knd_str,ku.knd_hausnr,ku.knd_plz,ku.knd_ort\n;
$Select.=from wd_kunde ku\n;
$Select.=where ku.knd_vorid=1001586\n;
system(rm Test.csv);
my $dbh=DBI-connect('dbi:AnyData(RaiseError=1):f_encoding = utf8');
my $oracle_dbh=DBI-connect($Dsn,$User,$Passwd);
my %OraFlags;
$OraFlags{sql}=$Select;
$OraFlags{col_names}=knd_name1,knd_name2,knd_str,knd_hausnr,knd_plz,knd_ort;
$dbh-func('wd_kunde','DBI',$oracle_dbh,\%OraFlags,'ad_import');
$dbh-func('wd_kunde','CSV','Test.csv','ad_export');
my $sth=$dbh-prepare($Select);
$sth-execute();
With friendly regards
Ralf
Ralf Eiteljoerge
--
ProUnix GmbH
Heinemannstr. 34
53175 Bonn
--
Telefon: +49-228-18466-774
Fax: +49-228-18466-66
Mobil..: +49-177-3130158
E-Mail.: ralf.eiteljoe...@prounix.de
Web: www.prounix.de
--
Prounix Gesellschaft für Softwareentwicklung mbH - Geschäftsführer:
Markus Glaz, Andreas Decker - Handelsregister: Amtsgericht Bonn HRB
5855 - Sitz der Gesellschaft: Bonn
Re: How to detect if a table exists, with DBD::DBM
2011/4/4 David McMath mcd...@stanford.edu:
On 04/03/2011 06:18 AM, Jens Rehsack wrote:
On 04/01/11 17:15, David McMath wrote:
Dear List,
Hi David,
I quick reply now without taking a look into the details of the
implementation to prevent that I forget you (I'm currently busy
with other tasks ...).
...
I've tried $dbh-func('list_tables') but that just lists all the files
in the directory. I'd rather not use that because I'd rather not have to
remember how the particular DBM handles extensions.
This shouldn't happen with a proper configured DBD::DBM session. If I
forgot to dig deeper here within next 4 business days, please feel free
to remind me.
You should include the version numbers of DBI and SQL::Statement
you use in your environment and they should better match the latest
released versions ;)
Further, you should add the OS(s) you're using (just to be sure).
Thanks for your time. Including version numbers is always good advice.
When I wrote the original, DBI was something very old and DBD::DBM was
v0.03. After updating, I understand that list_tables should work.
The attached script almost does the right thing except for a bug in
SqlEngine (?). I described that at
https://rt.cpan.org/Public/Bug/Display.html?id=67223
I'll see when I find the time to care (might not be soon). Thanks for reporting.
I don't think CREATE TABLE IF NOT EXISTS parses, even after I updated
everything I could think of. The attached script gives the output below.
But the list_tables trick is good enough for me.
You're right and I'm sorry - CREATE TABLE IF NOT EXISTS is neither
supported by DBI::SQL::Nano nor by SQL::Statement. I'll try to remind
myself when hacking on RT#67223.
Thanks again for your help,
You're welcome,
Jens
dave
--
[mcdave@epgy-dsk-999 ticketServer]$ uname -a
Linux epgy-dsk-999.Stanford.EDU 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6
13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
[mcdave@epgy-dsk-999 ticketServer]$ perl gdb_test_list.pl
Version information:
Use of uninitialized value in concatenation (.) or string at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBD/DBM.pm line
178.
Use of uninitialized value in concatenation (.) or string at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBD/DBM.pm line
185.
DBD::DBM 0.06 using SDBM_File () + MLDBM () +
MLDBM::Serializer::Storable
DBD::File 0.40 using IO::File (1.14)
DBI::DBD::SqlEngine 0.03 using SQL::Statement 1.33
DBI 1.616
OS linux (2.6.18-128.1.10.el5)
Perl 5.008008 (x86_64-linux-thread-multi)
List of tables:
Can't use string (tickets) as an ARRAY ref while strict refs in use at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI/DBD/SqlEngine.pm
line 688.
Can't find column definitions! at
/usr/lib/perl5/site_perl/5.8.8/SQL/Statement.pm line 88
DBD::DBM::db do failed: Can't find column definitions! [for Statement
CREATE TABLE IF NOT EXISTS tickets
(tid TEXT PRIMARY KEY
, user_id INTEGER
, started DATE
, status_f VARCHAR(16)
, value_f VARCHAR(255)
)
] at gdb_test_list.pl line 19.
Can't find column definitions! at gdb_test_list.pl line 18.
Re: How to detect if a table exists, with DBD::DBM
On 04/01/11 17:15, David McMath wrote:
Dear List,
Hi David,
I quick reply now without taking a look into the details of the
implementation to prevent that I forget you (I'm currently busy
with other tasks ...).
The short version of my question is: Using DBD::DBM, is there a simple
way to tell whether a table exists? (Other than just trying to query it
and handling failure.)
I've tried $dbh-{'dbm_tables'} which seemed promising, except that
it's always empty until I actually execute a query.
That's true, the attribute dbm_tables contains only those tables which
had been touched in this session.
I've tried $dbh-func('list_tables') but that just lists all the files
in the directory. I'd rather not use that because I'd rather not have to
remember how the particular DBM handles extensions.
This shouldn't happen with a proper configured DBD::DBM session. If I
forgot to dig deeper here within next 4 business days, please feel free
to remind me.
You should include the version numbers of DBI and SQL::Statement
you use in your environment and they should better match the latest
released versions ;)
Further, you should add the OS(s) you're using (just to be sure).
The longer version of the question, with the rest of the story, is below.
Thanks for any advice,
dave
--
I have a little application that tracks state of tickets. I wrote a
proof-of-concept using DBI and DBD::SQLite. A colleague suggested I try
a different backing store, like BerkeleyDB or GDBM. No problem, said
I, I'll just switch to DBD::DBM.
Of course, I had cheated. In the SQLite version, I had the statement
CREATE TABLE IF NOT EXISTS tickets (...)
at the very beginning. For the DBM version, I have to remove the IF NOT
EXISTS phrase. The code works, but its output is peppered with
warnings like
DBD::DBM::st execute failed: Cannot CREATE './tickets.pag' because it
already exists at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBD/DBM.pm
line 338.
Those are just warnings and everything else seems to work. At least with
SDBM.
When you're able to create a small test case to demonstrate it, you would
save me some work. This seems to be a bug, because CREATE TABLE IF NOT
EXISTS ... should work fine without noise.
Best regards,
Jens
Re: FW: DBI 1.6.15 problem on AIX 6.1 with perl 5.8.8 64bit
2010/10/8 Hatala, Michael mhat...@nemours.org: Jens, I am using cpan for module installations. On thing is that the CPAN failed on this test but passed when I ran it via the vi 'perl Makefile.PL' way. I think, in this case it's more a question to the toolchain people (http://github.com/Perl-Toolchain-Gang). I don't know if there is a mailing list. I suggest, ask on irc.perl.org in #toolchain channel. /Jens t/04clean_load.t ... Can't stat blib/lib: A file or directory in the path name does not exist. at t/04clean_load.t line 8 You said to run 0 tests at t/04clean_load.t line 11. t/04clean_load.t ... Dubious, test returned 2 (wstat 512, 0x200) Here is proof of CPAN installation. I still don't have a prove command. cpan[2] install Bundle::CPAN Test::Harness is up to date (3.22). ExtUtils::CBuilder is up to date (0.2703). ExtUtils::MakeMaker is up to date (6.56). Module::Build is up to date (0.3607). File::Spec is up to date (3.33). File::Temp is up to date (0.22). Scalar::Util is up to date (1.23). Test::More is up to date (0.96). Data::Dumper is up to date (2.128). Digest::SHA is up to date (5.48). File::HomeDir is up to date (0.93). Compress::Raw::Bzip2 is up to date (2.031). Compress::Raw::Zlib is up to date (2.030). IO::Compress::Base is up to date (2.030). IO::Uncompress::Gunzip is up to date (2.030). Compress::Zlib is up to date (2.030). IO::Zlib is up to date (1.10). Archive::Tar is up to date (1.68). Archive::Zip is up to date (1.30). Net::Cmd is up to date (2.29). Net::FTP is up to date (2.77). Term::ReadKey is up to date (2.30). Term::ReadLine::Perl is up to date (1.0303). YAML is up to date (0.72). Parse::CPAN::Meta is up to date (1.40). Text::Glob is up to date (0.08). CPAN is up to date (1.9402). File::Which is up to date (1.09). Thanks, Mike -Original Message- From: Jens Rehsack [mailto:rehs...@googlemail.com] Sent: Friday, October 08, 2010 12:07 PM To: Martin J. Evans Cc: Hatala, Michael ; Jens Rehsack; dbi-users@perl.org Subject: Re: FW: DBI 1.6.15 problem on AIX 6.1 with perl 5.8.8 64bit On 10/08/10 14:57, Martin J. Evans wrote: On 08/10/10 15:25, Hatala, Michael wrote: I don't have the prove command with this perl 5.8.8 64bit release. I'm assuming it's a byproduct of the perl installation(?) It is in Test::Harness which you already have but perhaps not new enough. On my Linux system it is not in the same place as the perl binary - perl binary is in /usr/bin and prove is in /usr/local/bin. This sounds reasonable, Martin. I encountered massive problems on AIX with the old modules. I used some more recent ones (especially toolchain and test modules). But they are named all in Makefile.PL or META.yml, so cpan should have the preinstalled. Hatala, you're using cpan, cpanplus or cpanminus, don't you? If you don't use them, you checked META.yml and/or Makefile.PL for prerequisites, don't you? Jens
Re: DBI Layer documentation
2010/10/9 Kumar, Ankur ankur.ku...@netapp.com: Dear Jens, Dear Ankur, please keep the list cc'ed. Thanks for your mail. I know what dbi is and why is it used. I am clueless at the moment w.r.t. its implementation in the code I am working on. I will get back you soon after further investigation. Please get back to the list. I cannot help you much on database interface programming, regardless the language. I just detected some open questions in your mail if I would have the technical knowledge to answer. Jens Thanks again for your mail. With Regards, Ankur Kumar Intern, SMAI Dev. NetApp, Bangalore -Original Message- From: Jens Rehsack [mailto:rehs...@googlemail.com] Sent: Thursday, October 07, 2010 3:56 PM To: Kumar, Ankur Cc: dbi-users@perl.org Subject: Re: DBI Layer documentation 2010/10/7 Kumar, Ankur ankur.ku...@netapp.com: Hello, I am working with C in front end and Sybase in backend. I have been asked to understand and modify a piece of code which uses DBI layer for running queries on Sybase entries. I am not able to understand the DBI layer implementation in the code. Please help me with a very simple and basic documentation on DBI layer (specific to C-Sybase duo if possible) But you regognize what DBI is, don't you? If not, it's a Database independent interface for Perl Probably you explain now a bit more detailed how you plan to use DBI in you setup: 1) load embedded Perl in you C application 2) load the DBI module in this embedded Perl 3) call DBI methods via perlapi? Or do you plan to copy code from DBI.xs to adapt it in your project to be able to use a Database independent interface for C? Jens
Re: FW: DBI 1.6.15 problem on AIX 6.1 with perl 5.8.8 64bit
2010/10/8 Hatala, Michael mhat...@nemours.org: Well I can't send a zip so here is my error in the tests and the perl -V. I'm pretty much stuck at this point and need some direction. t/zvxgnp_51dbm_file.t .. ok 1 - drop table ok 2 - FRED.dir exists ok 3 - fred.dir exists Dubious, test returned -1 (wstat 139, 0x8b) All 3 subtests passed ... Test Summary Report --- t/50dbm_simple.t (Wstat: 139 Tests: 12 Failed: 0) Non-zero exit status: -1 Parse errors: No plan found in TAP output t/51dbm_file.t (Wstat: 139 Tests: 3 Failed: 0) Non-zero exit status: -1 Parse errors: No plan found in TAP output # perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=aix, osvers=5.3.0.0, archname=aix-thread-multi-64all uname='aix akash79 3 5 00011a85d600 ' config_args='-desr -Dinstallprefix=/usr/opt/perl5 -Dprefix=/usr/opt/perl5 -Dcc=xlc_r -Duseshrplib -Dusethreads' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q64 -DUS E_64_BIT_ALL -q64', optimize='-O', cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT' ccversion='9.0.0.2', gccversion='', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld', ldflags ='-brtl -bdynamic -b64' libpth=/lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -lgdbm -ldbm -ldb -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd libc=, so=a, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -bE:/usr/opt/perl5/lib64/5.8.8/aix-thread-multi-64all/CORE/perl.exp' cccdlflags=' ', lddlflags='-b64 -bhalt:4 -bexpall -G -bnoentry -lpthreads -lc' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under aix Compiled at Jun 3 2009 12:34:41 �...@inc: /usr/opt/perl5/lib64/5.8.8/aix-thread-multi-64all /usr/opt/perl5/lib64/5.8.8 /usr/opt/perl5/lib64/site_perl/5.8.8/aix-thread-multi-64all /usr/opt/perl5/lib64/site_perl/5.8.8 /usr/opt/perl5/lib64/site_perl -Original Message- From: Hatala, Michael Sent: Thursday, October 07, 2010 6:07 PM To: 'dbi-users@perl.org' Subject: DBI 1.6.15 problem on AIX 6.1 with perl 5.8.8 64bit I'm getting many 'Dubious, test returned -1 (wstat 139, 0x8b)' errors when running the 'make test'. I have attached all of the appropriate files. Any help would be appreciated. Try a perl -Mblib -d t/51dbm_file.t, type 'c' at the debugger prompt and see what fails (usually you'll see much more in debugger than in normal output). I can't reproduce on an AIX 6.1 32-bit, gcc (except the initial error of to low Test::More installed, which causes nearly all tests fail at the first ok()). Jens
Re: FW: DBI 1.6.15 problem on AIX 6.1 with perl 5.8.8 64bit
On 10/08/10 14:57, Martin J. Evans wrote: On 08/10/10 15:25, Hatala, Michael wrote: I don't have the prove command with this perl 5.8.8 64bit release. I'm assuming it's a byproduct of the perl installation(?) It is in Test::Harness which you already have but perhaps not new enough. On my Linux system it is not in the same place as the perl binary - perl binary is in /usr/bin and prove is in /usr/local/bin. This sounds reasonable, Martin. I encountered massive problems on AIX with the old modules. I used some more recent ones (especially toolchain and test modules). But they are named all in Makefile.PL or META.yml, so cpan should have the preinstalled. Hatala, you're using cpan, cpanplus or cpanminus, don't you? If you don't use them, you checked META.yml and/or Makefile.PL for prerequisites, don't you? Jens
Re: anti-join with SQL::Statement?
2010/10/4 Reinier Post r...@win.tue.nl: On Mon, Oct 04, 2010 at 11:12:05AM -0700, Darren Duncan wrote: Reiner, I don't know if this was your workaround, but here's another solution that just uses SQL::Statement ... Ludwig, Michael wrote: So the next thing I tried was the anti-join (see http://en.wikipedia.org/wiki/Relational_algebra#Antijoin First time I hear of this antijoin. The example given on the Wiki page doesn't make much sense to me. Isn't is simply an OUTER JOIN where you're looking for NULL on the right-hand side? SELECT E.Name, D.DeptName FROM Employee AS E LEFT JOIN Dept AS D ON E.DeptName = D.DeptName WHERE D.DeptName IS NULL I tried this, but it didn't work: none of the D.DeptNames were NULL. However, on retrying, I find that it *does* work, so my testing must have been faulty. My apologies. SELECT E.* FROM Employee AS E LEFT JOIN Dept AS D USING (DeptName) WHERE D.DeptName IS NULL Thanks, I didn't know about USING. Works fine, too: $ cat ab-h.csv a,b a1,b1 a1,b2 a2,b1 a2,b2 $ cat bc-h.csv b,c b1,c1 b1,c2 $ csvsql -e 'SELECT * FROM t1 LEFT JOIN t2 USING (b) WHERE t2.b IS NULL' ab-h.csv bc-h.csv a,b,c a1,b2, a2,b2, $ csvsql is a 82-line Perl script that reads its inputs with DBD::CSV, assigns them to tables t1, t2, ..., performs the SQL query, and writes the result with Test::CSV_XS (I didn't figure out how to do it with DBD::CSV). In theory following should work: $dbh-do( CREATE TABLE tgt_tbl AS SELECT * FROM t1 LEFT JOIN t2 USING (b) WHERE t2.b IS NULL ); I can't give any guarantees, because I haven't tried it (currently fighting with corrupted filesystems on my development box). Have a look to t/16morejoins.t - there're some buggy behavior of SQL::Statement using left joins. Be careful. Quite an improvement over the Unix join. Glad to hear it :) /Jens
Re: DBI Layer documentation
2010/10/7 Kumar, Ankur ankur.ku...@netapp.com: Hello, I am working with C in front end and Sybase in backend. I have been asked to understand and modify a piece of code which uses DBI layer for running queries on Sybase entries. I am not able to understand the DBI layer implementation in the code. Please help me with a very simple and basic documentation on DBI layer (specific to C-Sybase duo if possible) But you regognize what DBI is, don't you? If not, it's a Database independent interface for Perl Probably you explain now a bit more detailed how you plan to use DBI in you setup: 1) load embedded Perl in you C application 2) load the DBI module in this embedded Perl 3) call DBI methods via perlapi? Or do you plan to copy code from DBI.xs to adapt it in your project to be able to use a Database independent interface for C? Jens
Re: DBI and DBD Installation on Different Unix (Solaris, AIX, HP and Linux)
On 08/06/10 08:05, Satish Bora wrote: Hello, Hello Satish, I am asking a very basic question here. You do not follow the guide how to ask questions as preferred in DBI documentation. Is there any standard instruction set which can guarantee the successful installation of DBI and DBD on Unix env. Yes, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/databases/p5-DBI, where is DBI packaged for Unix environments and running successful on Linux over NetBSD, other *BSD over Solaris and AIX up to HP-UX and IRIX (see http://www.netbsd.org/docs/software/packages.html#platforms). I tried this for last month of or so (using README files from DBI-DBD packages or based on the search on Google and other CPAN sites) and came to conclusion that there is no standard method which can guarantee the successful installation. Well, others seem to be more successful. Maybe you should hire someone, see http://dbi.perl.org/support/ or http://www.netbsd.org/gallery/consultants.html I may be missing something here. DBI docs at first? Would appreciate if somebody can provide me full proof method for installation of this. I am ready to treat for this :) I'm sorry, I read your questions before and always thought: This could be everything, I need more information. Maybe he's just not experienced enough to handle this alone and each question you ask him would move him into a defense corner. There're great tutorials how to build software on AIX (Porting C Software ... RedBook from IBM), the Sun developer forum and documentation is very detailed and usable for any experienced developer and software integrator who is coming from another Unix to Solaris. I'm pretty sure, for HP-UX similar pages exists. If you cannot understand them, you're well advised to hire someone. Best regards, Jens
[ANNOUNCE] DBD-Sys-0.100 and DBD-Sys-0.101
Hi, I'm glad to announce new versions of DBD::Sys: - the release with heavy plug-in structure reworking (0.100) and - the release with a test fix (0.101). I would be happy to read about feedback and successful uses. Best regards, Jens -- Changes since initial 0.01 release: 0.101 2010-07-25 - fix tests to run only when all dependencies are satisfied 0.100 2010-07-21 - rename columns which were reserved sql words for table procs - rework plugin-management and table-management: * allow multiple implementors for one table * merge the data from multiple implementors on primary key - rely on DBI::DBD::SqlEngine - add support for Win32::Process::Info - fix DBD::Sys::Plugin::Unix::Users and DBD::Sys::Plugin::Unix::Groups using setpwent/setgrent as recommended by Ashish SHUKLA ash...@freebsd.org (and by Richard W. Stevens) - add logins table to get a list of logged in users - add openfiles table - fix hwadress column in netint table to hwaddress - add a second implementation for the netint table using Net::Ifconfig::Wrapper and (for calculating broadcase address) NetAddr::IP - fixing duplicate group entries on FreeBSD (and maybe others)
[ANNOUNCE] SQL::Statement 1.28
Hi all, I'm proud to announce SQL::Statement 1.28. It's the first release for me where other DBI developers (Matin Evans, H. Merijn Brand) actively contributed patches and do their own commits. Thanks for that! To all users of SQL::Statement or Meta-DBD's: Please take care when updating SQL::Statement without DBI-1.612 - they depend on each other, if both installed, and SQL::Statement 1.28 will break: - DBD::DBM in DBI 1.611 and below - DBD::CSV 0.29 - DBD::AnyData 0.09 - DBD::RAM - DBD::PO 2.10 and maybe more. Best regards, Jens Version 1.28, release July 15th, 2010 -- [Improvements] * Introduce new capability method for SQL::Statement and SQL::Eval::Table + Add capability for insert_new_row to allow DBD::DBM to fix PK constrain on INSERT statements. * Performance of IMPORT feature improved (thanks to Sven Probst, RT#57322) [Bug fixes] * expect every table object being derived from SQL::Eval::Table * rewrite DELETE and UPDATE command based on table capabilities * add abstract methods for all methods derived classes must override (this means, open_table for SQL::Statement deriveds must be overridden and all data access methods of tables - see SQL::Eval::Table for details) * Tests are fixed to use TEMP TABLES explicitely when required * check for invalid column names fixed * Don't let depreciated parser structures stay alive in SQL::Statement when reusing the Parser [Documentation] * Method documentation of SQL::Statement and SQL::Eval::Table are improved * Add a Roadmap describing future plans for SQL::Statement (in addition to DBD::File::Roadmap). * POD spelling fixes provided by H.Merijn Brand and Pod::Spell::CommonMistakes (thanks Tux) * POD grammar fixes and reasonable sentences created by Martin Evans [Things that may break your code] * SQL::Statement 1.28 is expected not to work proper in combination with DBI 1.611 and below * SQL::Statement::ColumnValue expects now every table being derived from SQL::Eval::Table
Re: Building 32-Bit ONLY Perl on Mac OSX
On 06/15/10 21:25, Michael Nhan wrote: Hi, You are trying to build 32bit application on a 64bit osx. You will need to tell both the compiler and the linker that you want to build 32bit apps. Gcc is easy enough with the -m32 flag. ld is a little trickier. On linux, I have to link using ld -melf_i386 instead of plain ld. Run ld -V to see what emulation modes are available to you. I don't have a 64bit macosx to help you. Building 32bit perl on a 64bit os will require you to change the make file to build with gcc -m32 and get the ld to link with the proper parameter. You may have to temporarily move ld to ld.bin and make a script that calls ld.bin -melf_i386 (or whatever fits your neeed) as ld so it links properly if you can't get the makefile do you what you want. As I said, for people who don't have the experience with the compiler toolchain, it could be safer to use a build from source packaging environment like pkgsrc or gentoo-arch. The can be configured to the OSABI to be used and build all packages against this ABI. I know that pkgsrc is supporting MacOS X 10.6 in 32-bit mode, too, because some of our pkgsrc committers have target (not build) machines running 32-bit only and they build 32-bit packages to their requirements on 64-bit osx hosts. Sorry for repeating this again - but I think using such a pkg system would be the best way for questions like OP. Jens
Re: Building 32-Bit ONLY Perl on Mac OSX
2010/6/15 kai.schwerm...@bill-x.de: Hi DBI-Users, my question isn't directly related to DBI, but i need to compile a 386/32 Bit ONLY Perl Binary on Mac OSX 10.6 (SnowLeopard), not only but also because we only have a 32 Bit Oracle Instant Client... No Matter what Config-Params i tried, the only thing i get is the following: ...file was built for i386 which is not the architecture being linked (x86_64)... Does anyone have an idea or a good link? Looks as you are not very familiar with compiler and linker flags. I suggest you use pkgsrc (http://www.pkgsrc.org/) to build your Perl and DBI. BTW, this problem seems to happen also on 64-Bit Linux... It doesn't - but seems to be the same reason :) Suggest the same solution for you :) Best regards, Jens Thanks in advance for any idea Kai -- Kai Schwermann, Geschäftsführer bill-X GmbH Möserstr. 34 49074 Osnabrück, Germany Tel. +49-541-71008-0 Fax +49-541-71008-499 http://www.bill-X.de schwerm...@bill-x.de
Re: Building 32-Bit ONLY Perl on Mac OSX
2010/6/15 kai.schwerm...@bill-x.de: Hi Jens, i don't need prebuilt packages, but a working config.sh... pkgsrc is not only for prebuilt packages - it primarily works for building from source. When you bootstrap it for 32-bit ABI, it will build all your packages for 32-bit. It seems difficult to find such a thing, even on more mac-like pages like fink and macports... Give it a shot (read: take a deeper look). Jens Nonetheless thanks Kai -- Kai Schwermann, Geschäftsführer bill-X GmbH Möserstr. 34 49074 Osnabrück, Germany Tel. +49-541-71008-0 Fax +49-541-71008-499 http://www.bill-X.de schwerm...@bill-x.de From: Jens Rehsack rehs...@googlemail.com To: kai.schwerm...@bill-x.de Cc: dbi-us...@perl.org Date: 15.06.2010 22:53 Subject: Re: Building 32-Bit ONLY Perl on Mac OSX 2010/6/15 kai.schwerm...@bill-x.de: Hi DBI-Users, my question isn't directly related to DBI, but i need to compile a 386/32 Bit ONLY Perl Binary on Mac OSX 10.6 (SnowLeopard), not only but also because we only have a 32 Bit Oracle Instant Client... No Matter what Config-Params i tried, the only thing i get is the following: ...file was built for i386 which is not the architecture being linked (x86_64)... Does anyone have an idea or a good link? Looks as you are not very familiar with compiler and linker flags. I suggest you use pkgsrc (http://www.pkgsrc.org/) to build your Perl and DBI. BTW, this problem seems to happen also on 64-Bit Linux... It doesn't - but seems to be the same reason :) Suggest the same solution for you :) Best regards, Jens Thanks in advance for any idea Kai -- Kai Schwermann, Geschäftsführer bill-X GmbH Möserstr. 34 49074 Osnabrück, Germany Tel. +49-541-71008-0 Fax +49-541-71008-499 http://www.bill-X.de schwerm...@bill-x.de
Re: Perl coredump when using ora_dbh_share to connect to Oracle DB's
2010/4/1 Wesley Schwengle wesley.schwen...@is.online.nl: On 01.04.10 03:02 John Scoles wrote: Hard to say exatly are you sure you are connecting to oracle corretly?? use DBI; my $dsn = 'DBI:Oracle:host=localhost;port=1527;sid=XXX'; is a rather odd dsn I always the the method above, although I don't define the host and port part, since it is known in tnsnames. But the dsn part looks normal to me :) The connect works absolutely fine when I cut off ora_dbh_share parameter. Best, Jens
Re: Perl coredump when using ora_dbh_share to connect to Oracle DB's
2010/4/1 John Scoles byter...@hotmail.com: Date: Wed, 31 Mar 2010 16:31:11 +0200 Subject: Perl coredump when using ora_dbh_share to connect to Oracle DB's From: rehs...@googlemail.com To: dbi-users@perl.org; pa...@pythian.com CC: karl.li...@lisse.it Hi all, I get a core dump when using attached script to connect to an Oracle DB. Anyone here having a hint what's going wrong? I need this (probably) to get Log::Log4perl::Appender::DBI run fine in a multithreaded environment. Hard to say exatly are you sure you are connecting to oracle corretly?? Correct, because the list-software cut my attachments :( See http://www.netbsd.org/~sno/orathreads.pl and http://www.netbsd.org/~sno/orathreads.trace to get the files. Best regards, Jens
Perl coredump when using ora_dbh_share to connect to Oracle DB's
Hi all, I get a core dump when using attached script to connect to an Oracle DB. Anyone here having a hint what's going wrong? I need this (probably) to get Log::Log4perl::Appender::DBI run fine in a multithreaded environment. Best regards and thanks in advance, Jens orathreads.pl Description: Binary data orathreads.trace Description: Binary data
Antwort: Re: Next patch for SQL::Statement
Hi Jeff, thanks for your quick response. I thought you were busy, that's why I always included the DBI-list so bots can index it and everyone can find the patch. I don't patch separately - the patches are cumulative, so it's enough to apply the last patch. The way using a -CURRENT version from svn sound to a freebie like me absolutely perfect. The guys who worked on the improvement were my collegue [EMAIL PROTECTED] (office) and me (both: private and office). If you really want to put me in the credits, please use [EMAIL PROTECTED] - I don't use my mail-server for the moment but if you give me several weeks to fix it, I'll get it up and running before christmas ;) Freundliche Grüße / Best Regards Jens Rehsack _ Fa. Manß Partner Phone: +49 - 214 - 30 - 46 193 Fax: +49 - 214 - 30 - 31 625 E-mail: [EMAIL PROTECTED] Web: http://www.BayerBBS.com Geschäftsführung: Vorsitzender Andreas Resch | Arbeitsdirektor Norbert Fieseler Vorsitzender des Aufsichtsrats: Klaus Kühn Sitz der Gesellschaft: Leverkusen | Amtsgericht Köln, HRB 49895 Jeff Zucker [EMAIL PROTECTED] 12.10.2007 10:01 An [EMAIL PROTECTED] Kopie Jeff Zucker [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], dbi-users@perl.org, [EMAIL PROTECTED] Thema Re: Next patch for SQL::Statement Hi Jens, Thank you for all the work you have put in to SQL::Statement, it sounds like great work. I have known for a long time that the joins could be improved and I'm glad that you did it. I'm unfortunately at a very busy time personally - with two major site launches coming up this month and next so I have almost no time to keep up with working on my modules. I'd like to include your patches and make a CPAN release as quickly as I can. Realistically it may be several weeks before I have time to do any real testing. To get some feedback quicker, I think what I will do is put the new version on perl.svn.org and then tell people on the DBI list and perlmonks (which may actually get more feedback) to try out your changes by downloading the SVN version. Then I will test when I can and presumably move the SVN version to CPAN. Does that sound like a good way to proceed? Just to check - If I patch 1.15 with your three patches, will I then end up with the version you have been using and testing? I will want to thank you formally in the changes file when I make the release so please let me know how you would like the credits listed - if there are several people involved, if your company should or should not be credited, if you want your email listed, etc. Thanks again for all the work. -- Jeff [EMAIL PROTECTED] wrote: Hi Jeff, as I wrote you last time, we were a little bit unhappy with the method join2tables(). Finally we looked over it a little and in our environment it was possible to rewite the function as added in the patch. Because of we didn't really understand what NATURAL joins are, we couldn't test all situations the function theoretically could handle. But the current version we tested here over 3-4 weeks and it seems to be stable and fully functional (for our requirements). I would be glad if you'll find the time to look over it and before everyone may find it via Google in the perl-dbi mailing list (I googled before writing the patch on my onw ;-)) so duplicate work may avoided. Best Regards Jens Rehsack
Next patch for SQL::Statement
Hi Jeff, as I wrote you last time, we were a little bit unhappy with the method join2tables(). Finally we looked over it a little and in our environment it was possible to rewite the function as added in the patch. Because of we didn't really understand what NATURAL joins are, we couldn't test all situations the function theoretically could handle. But the current version we tested here over 3-4 weeks and it seems to be stable and fully functional (for our requirements). I would be glad if you'll find the time to look over it and before everyone may find it via Google in the perl-dbi mailing list (I googled before writing the patch on my onw ;-)) so duplicate work may avoided. Best Regards Jens Rehsack patch-SQL_Statement Description: Binary data
2nd Patch for SQL::Statement
Hi Jeff,
because you didn't answer my last reply I think it's better to send the
2nd bug fix (patch includes fixes sent last times, too) again via
dbi-users@ list. When you're short on time, maybe others who are involved,
may take a look on it. Furthermore SQL::Statement and a lot of DBD-Modules
seems to rely on the other, when both modules are installed.
I made a fix in join_2_tables which prevents detecting the shared columns
as soon as more than 2 tables shall get joined. To be honest, I can't see
any reason for checking $isunqualA{$c} or $isunqualB{$c} in lines 663 and
666. Because of 2 tables could have similar named columns, the check of
k1/k2 in %iscolA/%iscolB is more significant. That's the reason why I
can't understand the lines 659-661 - a check as done in 663/666 is enough,
isn't it? In the first impression (without deep think over it) it looks
like a forgotten relict from first steps in joining into MemTables. But
maybe it's important for NATURAL joins - what ever that means - I'm not an
SQL expert as you.
Other problems - I didn't fix, because don't know where - is the behaviour
of SQL::Statement/SQL::Parser on following queries:
1) select A, B from tA, tB where tA.ID=tB.A_ID and tB.PK=PATTERN
2) select A, B from tA, tB where tA.ID=tB.A_ID and tB.PK='PATTERN1' or
tB.PK='PATTERN2'
Both statement prints out a perl warning like:
1) Use of uninitialized value in substitution iterator at
/usr/lib/perl5/vendor_perl/5.8.5/SQL/Parser.pm line 1806.
2) Use of uninitialized value in substitution iterator at
/usr/lib/perl5/vendor_perl/5.8.5/SQL/Parser.pm line 1552.
#ERROR: error during query: 'SQL ERROR: No equijoin condition in WHERE or
ON clause
The 1st situations causes SQL::Parser to bail out when hit the PATTERN
arg without raising any error.
I think better error checking could works wonders xD
Let me ask the question from my last mail again: What do you think about
allow indexed table-access? It's very likely that a physical data
structure knows more performant ways to search in it's data pool (XPath in
XML, BTrees in Berkeley-DB-tables, we use reverse lookup hash-tables).
When I shall invest time to add the one or other bug-fix or feature as
suggested, I ask for being allowed to reformat the source. It's very
painful to edit, because sometimes are TAB's used, sometimes blanks, no
consistent indent etc. `perltidy -gnu` or `perltidy -toc` would allow me
to stop wasting time to reformat the source when editing around to program
sth. and format back when finished to reduce differences made only because
of beautifying ...
Freundliche Grüße / Best Regards
Jens Rehsack
_
Fa. Manß Partner
Phone: +49 - 214 - 30 - 46 193
Fax: +49 - 214 - 30 - 31 625
E-mail: [EMAIL PROTECTED]
Web: http://www.BayerBBS.com
Geschäftsführung: Vorsitzender Andreas Resch | Arbeitsdirektor Norbert
Fieseler
Vorsitzender des Aufsichtsrats: Klaus Kühn
Sitz der Gesellschaft: Leverkusen | Amtsgericht Köln, HRB 49895
patch-SQL_Statement
Description: Binary data
