Re: An interesting DBD::Oracle OSAuth bug
On Tue, Feb 11, 2003 at 01:58:31PM -0800, Christopher R. Baker wrote:
Here's an interesting little bug that's been driving me crazy and a quick fix to it.
It only appears when using Oracle's OS authentication on a script called with the -w
flag
#!/usr/local/bin/perl
use strict;
use warnings 'all';
use Carp();
use DBI;
# We are connecting using Oracle's OS Authentication
# See:
# http://www.geocities.com/SiliconValley/Heights/6616/ops.html
# http://www.bijoos.com/oratom/ot_199808.htm
my $dbh = DBI-connect( dbi:Oracle:) || die($DBI::errstr);
You could just pass in an empty username (or / also works I believe).
Here's a diff that shows how to get rid of it:
$ diff /usr/local/lib/perl5/site_perl/5.6.1/sparc-solaris/DBD/Oracle.pm
lib/perl/site/DBD/Oracle.pm
208,209c208,209
if (DBD::Oracle::ORA_OCI() = 8) {
$dbname = $1 if !$dbname $user =~ s/\@(.*)//s;
---
if (DBD::Oracle::ORA_OCI() DBD::Oracle::ORA_OCI() = 8) {
$dbname = $1 if !$dbname $user $user =~ s/\@(.*)//s;
Much thanks for your work on this most wonderful framework!
Thanks.
Tim.
Help on group by with DBI::CSV
I am using CSV under DBI. A select statement with group by always gives me error: ex: SELECT AVG(id), MIN(id), MAX(id) FROM $table WHERE NOT (id IS NULL) GROUP BY name SQL ERROR: Bad table or column name 'NULL GROUP BY name' has chars not alphanume ric or underscore! It works fine with group by clause removed. Looks like CSV does not support group by. Is there a way that I can do group by with CSV or DBD? Thanks Ming
RE: passing more than one ARGV value
Hello ,
I am writing a user registration script which once the user has filled
in the form it emails them a simple html email with a link for them to click
to validate that there email address is real.
i.e
Print 'a
Href=http://www.mydomain.com/cgi-bin/script.pl?confirm?[EMAIL PROTECTED];
Click to validate/A href;
Ok so far but when the link is clicked the script will not pick up the
second variable I am using
$process = $ARGV[0];
$somevariable = $ARGV[1];
if ($process EQ confirm)
{
do_something;
}
else
{
do_somethingelse
}
I am relatively new to perl so I may be going about it in completely the
wrong way can anyone help me out here please.
Thanks
James
***DISCLAIMER***
This Email and any files transmitted with it are confidential and intended
solely for the use of the individual to whom or the entity to which they are
addressed. If you have received this email in error please notify the sender
immediately. Please note that any views or opinions presented in this email
are those of the author and do not necessarily represent those of Letterbox
Mail Order Limited. The recipient should check this email and any
attachments for the presence of viruses. Letterbox Mail Order Limited
accepts no liability for any damage caused by any virus transmitted via this
email.
Re: Install of DBI for Perl fails on Solaris 8
At 23:30 11/02/03, Dave James wrote: I think the issue is that I need to use gcc instead of cc. But I don't know how to change the Makefile.PL to configure this... Any direction is appreciated... (There's a FAQ but ...) It's the Perl you're trying to add DBI to. On Sol8 the default Perl is 5.5.3 and is built using Sun's cc compiler. Best route is to get a gcc built perl (5.6.1) from www.sunfreeware.com and start over. Don't get rid of Sun's perl - solaris uses it for own scripts HTH -- MarkT E M Thornber Enchanted Systems Limited Software Toolsmiths +44 (0) 1503 272097 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/03
RE: Dates and DBD::Pg
Good Morning,
Thanks all for your help, I ended up doing this:
3. You might be able to get away with doing a
$prepare-(q{INSERT INTO thistab VALUES(now() + ?});
followed by:
$sthCreateOEHeader-execute('30');
Here's hoping it doesn't get broken later on ;)
J-T MacNeil
Jr. Software Developer, Connect 24 Division
Digital Security Controls
Phone: (905) 760-3000 x7302
e-Mail: [EMAIL PROTECTED]
dbi_time() - microseconds patch for win32 [DBI 1.32]
Tim, why don't you take advantage of Time::HiRes instead of your own dbi_time() implementation. If you are afraid of module dependency or you have another good reason for it could you accept the patch below. It will provide microsecond precision for DBI profiling on MSWin32 (at least my MS Visual C 6 doesn't implement gettimeofday() function but provides similar one). 12,15d11 # if (defined(_WIN32) (! defined(HAS_GETTIMEOFDAY))) #include sys/timeb.h # endif 1815,1819d1810 # ifdef _WIN32 struct _timeb when; _ftime( when ); return when.time + (when.millitm / 1000.0); # else 1822d1812 # endif BTW: All tests successfully passes with this patch applied. But without it... (MSWin32, AS Perl 5.6.1.633) t\40profile.FAILED tests 22-25 Failed 4/56 tests, 92.86% okay t\41prof_dump...ok t\42prof_data...FAILED test 6 Failed 1/14 tests, 92.86% okay -- Petr Smejkal
Connect error
Hello again, * After loading the DBI and DBD::Sybase modules under the SA password, I get the following error when running the simple connect script: $dbh = DBI-connect(dbi:Sybase:tec, tec, tectec): DBI-connect(tec) failed: OpenClient message: LAYER = (6) ORIGIN = (8) SEVERITY = (5) NUMBER = (3) Message String: ct_connect(): directory service layer: internal directory control layer error: Requested server name not found. at dbi.sql line 5 Cannot connect to tec: OpenClient message: LAYER = (6) ORIGIN = (8) SEVERITY = (5) NUMBER = (3) Message String: ct_connect(): directory service layer: internal directory control layer error: Requested server name not found. * I also got the following error when printing available drivers(I do not see the Sybase driver listed): install_driver(Proxy) failed: Can't locate RPC/PlClient.pm in @INC (@INC contains: /opt/perl5/lib/5.6.0/PA-RISC1.1 /opt/perl5/lib/5.6.0 /opt/perl5/lib/site_perl/5.6.0/PA-RISC1.1 /opt/perl5/lib/site_perl/5.6.0 /opt/perl5/lib/site_perl .) at /opt/perl5/lib/site_perl/5.6.0/PA-RISC1.1/DBD/Proxy.pm line 28. BEGIN failed--compilation aborted at /opt/perl5/lib/site_perl/5.6.0/PA-RISC1.1/DBD/Proxy.pm line 28. Compilation failed in require at (eval 4) line 3. Perhaps a module that DBD::Proxy requires hasn't been fully installed at dbi.sql line 14 DRIVER: ADO DRIVER: ExampleP Data Source is dbi:ExampleP:dir=. DRIVER: Multiplex DRIVER: Proxy
ApacheDBI/AuthDBI question
Hi I appreciate that this question is slightly off topic.. I have been asked to investigate moving an application that works well on Unix to Win2K for a particular customer. Everything works well apart from Authentication. I have tried Apache::AuthDB, and I cannot get it to work. The error I get when starting Apache relates to IPC::SysV. Has anyone got this to work on Win2K? Thanx Simon -- Simon Windsor Email: [EMAIL PROTECTED]
perl-6.5.1 DBI-1.32 DBD-Oracle-1.12
Hi, First of all, thanks Frans Postma for your mail about my DBD-DBI login problem. As he indicated, i tried downgrading first DBI to 1.14 and DBD-Oracle to 1.07 always with perl-5.8.0. With no success. So i tried perl-5.6.1 (-- WITHOUT threading because i encounterd the same problems with threading enabled as with version 5.8.0) with DBI-1.32 and DBD-Oracle-1.12 . I had the following errors in DBI: - t/40profile Can't locate Time/HiRes.pm in @INC at t/40profile.t line 183 - t/70shell Use of uninitialized value in pattern match (m//) at /opt/ perl5/lib/5.6.1/Term/Cap.pm line 284 Even with theses errors i installed and compiled DBD-Oracle AND NO connexion problem with Oracle 7.3.4. (By the way, yes, there were an Oracle error: SET TRANSACTION not allowed ... at this point but i think thats an Oracle 7.3.4 issue.) So here my questions: - Even with the errors with Time/HiRes.pm and in Term/Cap.pm am i save to continue to work with this installation? - shall i try to get rid of them and how? or - do you have other hints or advices? Thanks for helping josef
RE: perl-6.5.1 DBI-1.32 DBD-Oracle-1.12
I had the following errors in DBI: - t/40profile Can't locate Time/HiRes.pm in @INC at t/40profile.t line 183 Install Time::HiRes from CPAN if you want this error to go away. It doesn't affect your DBD module at all though. The HiRes module comes standard with perl 5.8 which is why you now get the error. - t/70shell Use of uninitialized value in pattern match (m//) at /opt/ perl5/lib/5.6.1/Term/Cap.pm line 284 This is a warning concerning an entirely different module, doesn't look worriesome to me. Should affect your module at all. Just ignore it, you could upgrade Term::Cap of course but I doubt thats worth the trouble just for that warning. If I remember correctly that 'set transaction not allowed here' is intentional and to be expected ? Check the testoutput, it should say something like that. Then again, maybe transaction don't work at all on 7.3.4 ? Never used them below Oracle 8 anyway. --- Frans Postma, (050-58) 81 852 ATOS Origin, Unix Support If at first you don't succeed, skydiving isn't for you -Oorspronkelijk bericht- Van: Josef Jirkovsky [mailto:[EMAIL PROTECTED]] Verzonden: woensdag 12 februari 2003 16:45 Aan: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Onderwerp: perl-6.5.1 DBI-1.32 DBD-Oracle-1.12 Hi, First of all, thanks Frans Postma for your mail about my DBD-DBI login problem. As he indicated, i tried downgrading first DBI to 1.14 and DBD-Oracle to 1.07 always with perl-5.8.0. With no success. So i tried perl-5.6.1 (-- WITHOUT threading because i encounterd the same problems with threading enabled as with version 5.8.0) with DBI-1.32 and DBD-Oracle-1.12 . I had the following errors in DBI: - t/40profile Can't locate Time/HiRes.pm in @INC at t/40profile.t line 183 - t/70shell Use of uninitialized value in pattern match (m//) at /opt/ perl5/lib/5.6.1/Term/Cap.pm line 284 Even with theses errors i installed and compiled DBD-Oracle AND NO connexion problem with Oracle 7.3.4. (By the way, yes, there were an Oracle error: SET TRANSACTION not allowed ... at this point but i think thats an Oracle 7.3.4 issue.) So here my questions: - Even with the errors with Time/HiRes.pm and in Term/Cap.pm am i save to continue to work with this installation? - shall i try to get rid of them and how? or - do you have other hints or advices? Thanks for helping josef
Re: Connect error
On Wed, 2003-02-12 at 07:51, [EMAIL PROTECTED] wrote: Hello again, * After loading the DBI and DBD::Sybase modules under the SA password, I get the following error when running the simple connect script: $dbh = DBI-connect(dbi:Sybase:tec, tec, tectec): DBI-connect(tec) failed: OpenClient message: LAYER = (6) ORIGIN = (8) SEVERITY = (5) NUMBER = (3) Message String: ct_connect(): directory service layer: internal directory control layer error: Requested server name not found. Which simply means that tec isn't listed in the interfaces file that this script uses. Check your SYBASE environment variable to make sure that the test scripts pick up the right interfaces file. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.mbay.net/~mpeppler Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.mbay.net/~mpeppler/resume.html
Re: dbi_time() - microseconds patch for win32 [DBI 1.32]
On Wed, Feb 12, 2003 at 04:41:34PM +0100, Smejkal Petr wrote: Tim, why don't you take advantage of Time::HiRes instead of your own dbi_time() implementation. I believe, perhaps wrongly, that a Win32 build of perl defined it's own gettimeofday() which dbi_time() would then use. Notice, for example, that XSUB.h contains #define gettimeofday PerlProc_gettimeofday Umm, I'm looking at perl 5.8, maybe it's not in 5.6. If you are afraid of module dependency or you have another good reason for it could you accept the patch below. It will provide microsecond precision for DBI profiling on MSWin32 (at least my MS Visual C 6 doesn't implement gettimeofday() function but provides similar one). Thanks. Could you generate a patch with context information using diff -u oldfile newfile or diff -c oldfile newfile? That would make it easier and safer to apply. How portable across Win32 versions is this? 12,15d11 # if (defined(_WIN32) (! defined(HAS_GETTIMEOFDAY))) #include sys/timeb.h # endif 1815,1819d1810 # ifdef _WIN32 struct _timeb when; _ftime( when ); Is there an ftime function with the underscore? return when.time + (when.millitm / 1000.0); # else 1822d1812 # endif BTW: All tests successfully passes with this patch applied. But without it... (MSWin32, AS Perl 5.6.1.633) t\40profile.FAILED tests 22-25 Failed 4/56 tests, 92.86% okay t\42prof_data...FAILED test 6 Failed 1/14 tests, 92.86% okay Umm, could you try just removing the #ifdef around the existing dbi_time() code? Tim.
Re: Help on group by with DBI::CSV
Ming Lei wrote: I am using CSV under DBI. A select statement with group by always gives me error: That's because the GROUP BY clause is not supported by DBD::CSV. Please look in the documentation for SQL::Parser to see a list of the (fairly limited) SQL that DBD::CSV supports. It works fine with group by clause removed. Looks like CSV does not support group by. Correct, as specified in the documentation. Is there a way that I can do group by with CSV or DBD? Many other DBDs support it. If you're on windows, try DBD::ODBC with the text driver to access your CSV files directly, otherwise you'll need to dump your data into an rdbms. Alternatively, you could accomplish the same effects as a GROUP BY by using several combined queries and/or some perl manipulation. -- Jeff
Re: Help on group by with DBI::CSV
Ming Lei wrote:
[BTW: there is no such address as dbi-users-help, please trim it from
your cc list]
Alternatively, you could accomplish
the same effects as a GROUP BY by using several combined queries and/or
some perl manipulation.
I would appreciate if you or someone else can point out how to accomplish
group by with several combined queries that are supported by CSV. Note:
only sql querieswith minimum (best no) perl manipulation.
This works with DBD::CSV and a table t that has two columns - name
and amount:
my $sth=$dbh-prepare(
'SELECT MAX(amount),AVG(amount) FROM t WHERE name=?'
);
my $names = $dbh-selectcol_arrayref(
'SELECT DISTINCT name FROM t'
);
for my $name(@$names) {
$sth-execute($name);
while (my $r=$sth-fetch) {
print $name @$r\n;
}
}
--
Jeff
Can't Connect to Oracle 9i Database
I've written a perl program and I'm trying to connect to a 9i database as user 'sys', which requires the 'as sysdba' clause. Using the dbi-connect method fails with everything I've passed it. What's the secret? Eddie Bradford Systems Analyst/Programmer Information Technology Services John Muir/Mt. Diablo Health System 1400 Treat Boulevard Walnut Creek, CA 94596 (925) 947-4466 x32069 [EMAIL PROTECTED]
Re: Help on group by with DBI::CSV
Alternatively, you could accomplish the same effects as a GROUP BY by using several combined queries and/or some perl manipulation. I would appreciate if you or someone else can point out how to accomplish group by with several combined queries that are supported by CSV. Note: only sql queries with minimum (best no) perl manipulation. Many thanks -- Ming
Re: Can't Connect to Oracle 9i Database
Hi,
Try this:
my $dbuser=sys/change_on_install\@tnsalias;
my $dbh=DBI-connect('',$dbuser,'','Oracle',{AutoCommit = 0,RaiseError
=0,ora_session_mode =2});
see perldoc of DBD::Oracle for ora_session_modes.
Regards,
Michael
Date: Wed, 12 Feb 2003 10:24:49 -0800
From: Eddie Bradford [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: Can't Connect to Oracle 9i Database
I've written a perl program and I'm trying to connect to a 9i database
as user 'sys', which requires the 'as sysdba' clause. Using the
dbi-connect
method fails with everything I've passed it. What's the secret?
Eddie Bradford
Systems Analyst/Programmer
Information Technology Services
John Muir/Mt. Diablo Health System
1400 Treat Boulevard
Walnut Creek, CA 94596
(925) 947-4466 x32069
[EMAIL PROTECTED]
---//---
I don't need to compromise my principles, because they don't have the
slightest bearing on what happens to me anyway.
---Calvin (Calvin Hobbes).
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Ratliffe, M.
PLS HELP! Unable to install DBD-Oracle with Perl 5.6 in Solaris 8 ...
Hi Everyone: Please help! Here are the stuff I've installed in a SunBlade 150 box (SunOS 5.8 Generic_108528-18 sun4u sparc SUNW) ... Oracle9i Client : 9.2.0.1.0 Perl (ActivePerl) : 5.6.1 PPM : 2.1.6 DBI : 1.32 and I've got GCC in place as well ... Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.3/specs Configured with: ../configure --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --enable-libgcj Thread model: posix gcc version 3.0.3 I've tried to install DBD-Oracle, but isn't able to. For your references, attached are the standard outputs when I did perl Makefile.PL (perl-makefile.log) and then did make (make.log). What am I missing? I tried install dbd-oracle via PPM but it said PPM install dbd-oracle Install package 'dbd-oracle?' (y/N): y Installing package 'dbd-oracle'... Error installing package 'dbd-oracle': Read a PPD for 'dbd-oracle', but it is not intended for this build of Perl (sun4-solaris-thread-multi) Thank you very much in advance! __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com localhost:/export/home/londonbell/setup/temp/DBD-Oracle-1.12# perl Makefile.PL -v V Using DBI 1.32 installed in /usr/local/ActivePerl-5.6/lib/site_perl/5.6.1/sun4-solaris-thread-multi/auto/DBI Configuring DBD::Oracle ... Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /export/home/londonbell/OraHome1 Found rdbms/demo/oratypes.h Found header files in rdbms/demo. Found /export/home/londonbell/OraHome1/precomp/demo/proc/demo_proc.mk Using /export/home/londonbell/OraHome1/precomp/demo/proc/demo_proc.mk Reading /export/home/londonbell/OraHome1/precomp/demo/proc/demo_proc.mk. Reading /export/home/londonbell/OraHome1/precomp/lib/env_precomp.mk. Read a total of 1705 lines from /export/home/londonbell/OraHome1/precomp/lib/env_precomp.mk (including inclusions) Read a total of 1891 lines from /export/home/londonbell/OraHome1/precomp/demo/proc/demo_proc.mk (including inclusions) Deleted SHELL definition: SHELL=/bin/sh Deleted LIB_EXT definition: LIB_EXT=a Deleted OBJ_EXT definition: OBJ_EXT=o Deleted AR definition: AR=ar Deleted AS definition: AS=as Deleted CC definition: CC=cc Deleted CHMOD definition: CHMOD=chmod Deleted CPP definition: CPP=cpp Deleted ECHO definition: ECHO=echo Deleted LD definition: LD=ld Deleted PERL definition: PERL=perl Deleted CFLAGS definition: CFLAGS=$(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) Deleted LDFLAGS definition: LDFLAGS=-o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) LMAKE macro redefined by Oracle from make to /usr/ccs/bin/make FIND macro redefined by Oracle from find to /usr/local/bin/find # gnu find! LINK macro redefined by Oracle from $(LDCCOM) to $(ADE_DEL_FILE_CMD) $(PURECMDS) $(LD) $(LDFLAGS) -dy $(COMPSOBJS) LINKCC macro redefined by Oracle from $(LDCCOMCC) to $(ADE_DEL_FILE_CMD) $(PURECMDS) $(CCC) $(LDFLAGS) -norunpath -mt -nocx -dy $(COMPOBJSCC) LINKLDLIBS macro redefined by Oracle from $(LDLIBS) to $(EXPDLIBS) $(EXOSLIBS) $(SYSLIBS) $(LINKEXSYSLIBS) $(MATHLIB) $(USRLIBS) $(COMPEOBJS) COBLDLIBS macro redefined by Oracle from $(LDLIBS) to $(EXPDLIBS) $(EXOSLIBS) $(SYSLIBS) $(COBEXSYSLIBS) $(MATHLIB) $(USRLIBS) Deleted OPTIMIZE definition: OPTIMIZE=$(OPTIMIZE3) AR macro redefined by Oracle from ar to /usr/ccs/bin/ar Deleted AR definition: AR=/usr/ccs/bin/ar AS macro redefined by Oracle from as to /usr/ccs/bin/as Deleted AS definition: AS=/usr/ccs/bin/as LD macro redefined by Oracle from ld to /usr/ccs/bin/ld Deleted LD definition: LD=/usr/ccs/bin/ld NM macro redefined by Oracle from nm to /usr/ccs/bin/nm TR macro redefined by Oracle from tr to /usr/bin/tr CPP macro redefined by Oracle from cpp to $(CC) -E $(ANSI) Deleted CPP definition: CPP=$(CC) -E $(ANSI) TOUCH macro redefined by Oracle from touch to /bin/touch CHMOD macro redefined by Oracle from chmod to /bin/chmod Deleted CHMOD definition: CHMOD=/bin/chmod Deleted ASFLAGS definition: ASFLAGS=$(NOKPIC_ASFLAGS) $(KPIC_OPTION) Deleted CCFLAGS definition: CCFLAGS= $(NOKPIC_CCFLAGS) $(KPIC_OPTION) LIBNTVI macro redefined by Oracle from $(NETWORKLIB)$(LIB_PREFIX)$(VINAME).$(SO_EXT) to $(LIBHOME)$(LIB_PREFIX)$(VINAME).$(LIB_EXT) LIBNTOD macro redefined by Oracle from $(NETWORKLIB)$(LIB_PREFIX)$(DCENAME).$(LIB_EXT) to $(LIBHOME)$(LIB_PREFIX)$(DCENAME).$(LIB_EXT) LIBCDS macro redefined by Oracle from $(NETWORKLIB)$(LIB_PREFIX)$(CDSNAME).$(LIB_EXT) to $(LIBHOME)$(LIB_PREFIX)$(CDSNAME).$(LIB_EXT) LIBNTLU62 macro redefined by Oracle from $(NETWORKLIB)$(LIB_PREFIX)$(LU62NAME).$(LIB_EXT) to $(LIBHOME)$(LIB_PREFIX)$(LU62NAME).$(LIB_EXT) LIBNTS macro redefined by Oracle from $(NETWORKLIB)$(LIB_PREFIX)$(SPXNAME).$(LIB_EXT) to $(LIBHOME)$(LIB_PREFIX)$(SPXNAME).$(LIB_EXT)
RE: dbi_time() - microseconds patch for win32 [DBI 1.32]
I believe, perhaps wrongly, that a Win32 build of perl defined it's own gettimeofday() which dbi_time() would then use. Notice, for example, that XSUB.h contains #define gettimeofday PerlProc_gettimeofday Umm, I'm looking at perl 5.8, maybe it's not in 5.6. I haven't found anything similar in my 5.6. Well, maybe it's time to upgrade. :-) Thanks. Could you generate a patch with context information using diff -u oldfile newfile or diff -c oldfile newfile? That would make it easier and safer to apply. Of course, see below. How portable across Win32 versions is this? According to MSDN _ftime() is available on all Win* platforms and present in all common libraries (libc, libcmt, msvcrt). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__ftime.asp BTW: All tests successfully passes with this patch applied. But without it... (MSWin32, AS Perl 5.6.1.633) t\40profile.FAILED tests 22-25 Failed 4/56 tests, 92.86% okay t\42prof_data...FAILED test 6 Failed 1/14 tests, 92.86% okay Umm, could you try just removing the #ifdef around the existing dbi_time() code? The reason is quite simple. The tested SQL statement is finished in less than a second - let's say 0.123s but it means 0s if you are using low-precision dbi_time(). test 22-25 in 40profile.t ok($total $first);. 0 is not greater than 0 ok($total $longest);. 0 is not greater than 0 ok($longest 0); # XXX theoretically not reliable. 0 is not greater than 0 ok($longest $shortest);. 0 is not greater than 0 test 6 in 42prof_data.t ok($nodes-[0][4] $longest);. 0 is not lower than 0 - *** DBI-1.32/DBI.xs Wed Feb 12 21:50:01 2003 --- DBI.xs Wed Feb 12 21:55:14 2003 *** *** 9,14 --- 9,18 #include DBIXS.h/* DBI public interface for DBD's written in C */ + # if (defined(_WIN32) (! defined(HAS_GETTIMEOFDAY))) + #include sys/timeb.h + # endif + #define MY_VERSION DBI( XS_VERSION ) #if (defined USE_THREADS || defined PERL_CAPI || defined PERL_OBJECT) *** *** 1808,1815 --- 1812,1825 gettimeofday(when, (struct timezone *) 0); return when.tv_sec + (when.tv_usec / 100.0); # else/* per-second is almost useless */ + # ifdef _WIN32 /* use _ftime() on Win32 (MS Visual C++ 6.0) */ + struct _timeb when; + _ftime( when ); + return when.time + (when.millitm / 1000.0); + # else return time(NULL); # endif + # endif } static void -- Petr Smejkal
Re: [INTERFACES] Prepare and prepare ?
On Tuesday, February 11, 2003, at 10:51 PM, Rudy Lippan wrote:
Since David is too busy to work on DBD::Pg right now, I have ported the
changes that I made against 1.13 to CVS HEAD from gborg.postgresql.org.
The patch can be found here:
http://www.remotelinux.com/rlippan/dbd_pg.patch (I did not include it
in
this email because I did not want to spam everyone with a 100K diff).
Wow. Reading your description below, I'm really impressed. That's a lot
of work! Good thing I stepped aside! ;-)
I'd like to start putting together some developer releases (set up a
cvs
branch for this?), and see about getting together a stable release
version
that addresses the all of the outstanding problems with DBD::Pg.
So, if people are interested, where do I go from here to get things set
up for doing dev releases c.?
No need for a separate branch, I think. Just change the version number
to have an undersore, e.g., 1.30_01. That will automatically make it a
beta release number when it's put on CPAN.
What the patch does:
1. $dbh-prepare() rewrites the SQL statement into an internal for
striping out comments and whitespace, and if PostgreSQL 7.3 takes
the
stripped statement
and passes that to postgress' PREPARE statement, then rewrites the
statement as 'EXECUTE DBD::PG::cached_query n ($1, $2, ... $n,
$n+1)'
for DBD::Pg's execute.
Cool.
2. Allows the use of :n and :foo bind params. So: (SELECT * FROM foo
where
1 = :this and 2 = :that) will now work.
Oh, was that broken?
3. Complains on execute when unbound bind params are submitted
(instead of
defaulting to NULL)
Didn't know about that one.
4. Switched over to use driver.xst.
Yay!
5. pg_error() only removes \n's don't truncate message on first \n
Oh, good. I think it should be changed to do_error, too, with renaming
in dbdimp.h, no?
6. fixed statement scan problem where the preparse of
SELECT foo[3:33] from bar was scanning :33 as a placeholder
7. moved the quoting of bind values out of execute() and into
bind -- as there is no need to requote the value every time execute
is called.
Cool.
8. :veryverylongplaceholdername == Long walk. Sort pier -- fixed.
9. quote() is now in C and uses same code as bind_param.
Nice. Faster, t hen.
10. quoting and dequoting now use libpq quoting functions where
available
(I still need
to take the libpq functions swiped out of quote.c and move it into
libpqswip.c
with license info c., and switch ifndefs to ifdefs)
Excellent.
11. bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is
PGBOOLOID.
Smart.
12. fixed many heap buffer overruns.
Do you include tests for all of these things, too? That'd be great.
Known problems with patch:
1. Broke new pg_bool_tf attribute.
Ah. Can be fixed, I assume?
2. Broke rows() method (Just needs a define in makefile)
3. quote(stuff, {typeinfo }) is broken (only when hashref is passed
in)
Probably is never used, anyway. Or shouldn't be. Is it fixable?
4. broke chopblanks.
5. has some // style comments around debug statements that need to be
converted into logging statements
6. PREPARE is not bullet-proof casts in RSH of equality and functions
LHS of equality can break serverside prepare, so decide exactly how
to
do this and how to get prepares of INSERT statements to work? Move
prepqre to execute and build list column list in bind_param? Add
attributes to prepare to identify the columns and serverside
prepare if
they exist?
Not sure I understand the problems here. Is it weaknesses in
PostgreSQL's PREPARE?
7. Code is not as clean as it should be -- some kludgeness in there.
Oh, well *that's* not new! ;-)
8. Documentation has not been updated.
9. Needs more tests.
On my immediate todo list:
1. Change quote and dequote functions to take Sv instead of string so
that
things like arrays can be seralized by the quote function. This
will
take care of broken chopblanks and pg_bool_tf (pass the
quote/dequote
options struct to function quote/dequote functions).
Cool.
2. Export the full list of supported OID types.
For constants? I think I added a partial list in 1.20.
3. finish all type mappings in types.c
4. supoort for begin_work() method.
5. clean logging and trace levels.
6. dblogin to handle user names, table table names and other
names that containg ';'s
7. add attributes to control preparing of statements.
8. rewrite hacked version detection code (and get format for string so
it is done correctly with patch level c.).
You'll want to borrow code from PostgreSQL's ODBC implementation for
this, I think. Tim sent some links a while ago.
9. various code cleanups and polishing.
10. Copy over external test cases from DBD::Churlpg and write more
tests.
11. Update documentation.
There are probably many other things that I cannot remember off the
top of
my head since I have not done much (other than copy code over to CVS
Re: [INTERFACES] Prepare and prepare ?
On Wed, 12 Feb 2003, David Wheeler wrote:
I'd like to start putting together some developer releases (set up a
cvs
branch for this?), and see about getting together a stable release
version
that addresses the all of the outstanding problems with DBD::Pg.
So, if people are interested, where do I go from here to get things set
up for doing dev releases c.?
No need for a separate branch, I think. Just change the version number
to have an undersore, e.g., 1.30_01. That will automatically make it a
beta release number when it's put on CPAN.
I was thinking more for bug fixes agaist the old version before the
devel release are tested enough to go to production.
As for CPAN, should I go ahead set up a PAUSE account (I need to anyway)
for making the dev release, or do you want to handle making the releases?
(I warn you, though, that I am planing on releasing quite often until I
get a release that is stable enough for a production environment ;) ) If
the former what would need to be done to get CPAN to pick up my uploads as
part of DBD::Pg?
I signed up for the DBD::Pg project on gborg.org few days ago, so what do
I need to do to get CVS commit access?
Cool.
2. Allows the use of :n and :foo bind params. So: (SELECT * FROM foo
where
1 = :this and 2 = :that) will now work.
Oh, was that broken?
I think that the docs say that it does not work, but the code (from
DBD::oracle) was still there in preparse and bind, so it would work up
until execute() where it would break because execute was not looking for
:foo style placeholders.
This version saves the values for placeholer 1..n in an array and just
uses the key :foo as a lookup for the index into that array.
5. pg_error() only removes \n's don't truncate message on first \n
Oh, good. I think it should be changed to do_error, too, with renaming
in dbdimp.h, no?
To get away from possible namespace collisions with libpq? the libpq
functions start with PQ..., BTA pg_eror should probably be declared
static as should several other functions.
8. :veryverylongplaceholdername == Long walk. Sort pier -- fixed.
9. quote() is now in C and uses same code as bind_param.
Nice. Faster, t hen.
Probably. But the big win is that it uses the same quoting code that
bind_param does; therefore, they both use the libpq quoting function.
12. fixed many heap buffer overruns.
Do you include tests for all of these things, too? That'd be great.
Yup. But they are not in the patch.
Known problems with patch:
1. Broke new pg_bool_tf attribute.
Ah. Can be fixed, I assume?
Yeah. This just comes about because the way I implemented quoting. There
is a struct of pq_types that contains pointers to quote and dequote
functions. Right now the quote and dequote functions don't know anything
about perl/dbi... Take string send to libpq return string returned from
libpq.
3. quote(stuff, {typeinfo }) is broken (only when hashref is passed
in)
Probably is never used, anyway. Or shouldn't be. Is it fixable?
These are the calls that are broken:
quote(foo, {type=SQL_INTEGER})
quote(foo, {pg_type=DBD::Pg::PG_INTEGER})
Which I do see being used. So this fix is at the top of my list.
6. PREPARE is not bullet-proof casts in RSH of equality and functions
LHS of equality can break serverside prepare, so decide exactly how
to
do this and how to get prepares of INSERT statements to work? Move
prepqre to execute and build list column list in bind_param? Add
attributes to prepare to identify the columns and serverside
prepare if
they exist?
Not sure I understand the problems here. Is it weaknesses in
PostgreSQL's PREPARE?
Yes. PostgreSQL's PREPARE wants a list of column types when you call
prepare, so as proof of concept I did a (varchar, varchar, varchar...) for
the column types, but that ends up breaking some things (like UPDATE
INSERT, and when it checks an operation for castability).
Which does not make sense to me... postgres knows the fields types why
does it not set them correctly instead of making the application
programmer enumerate them... (or maybe give a type that causes pg to
not do checking. -- pg does the checks twice once on prepare and then it
does them again on execute, so again why not just sub in the correct types
if nothing was enumerated beforhand on prepare and let the checks on
execute handle the type checks?. Or am I missing something? Grr.
2. Export the full list of supported OID types.
For constants? I think I added a partial list in 1.20.
I know, those might be easier for the user, but for all interal stuff, I
am using the ones extraced from pg header files:
grep '^#define' /data/dnloads/postgresql-7.3/src/include/catalog/pg_type.h
|grep OID pg_typeOID.h
And I think that they should be available to the perl programmer as well.
8. rewrite hacked version detection code (and get format for
Re: [INTERFACES] Prepare and prepare ?
On Wednesday, February 12, 2003, at 07:42 PM, Rudy Lippan wrote: I was thinking more for bug fixes agaist the old version before the devel release are tested enough to go to production. Oh, well we can create a branch for the old version. Bruce, do you have a CVS tag convention that you like to use? As for CPAN, should I go ahead set up a PAUSE account (I need to anyway) for making the dev release, or do you want to handle making the releases? (I warn you, though, that I am planing on releasing quite often until I get a release that is stable enough for a production environment ;) ) If the former what would need to be done to get CPAN to pick up my uploads as part of DBD::Pg? Either way. I can give you ownership if you like, but even if I don't you can still upload releases. Let me know your preference. I signed up for the DBD::Pg project on gborg.org few days ago, so what do I need to do to get CVS commit access? Tell me your GBorg login name and I'll give it to you. I think that the docs say that it does not work, but the code (from DBD::oracle) was still there in preparse and bind, so it would work up until execute() where it would break because execute was not looking for :foo style placeholders. This version saves the values for placeholer 1..n in an array and just uses the key :foo as a lookup for the index into that array. Makes sense. To get away from possible namespace collisions with libpq? the libpq functions start with PQ..., BTA pg_eror should probably be declared static as should several other functions. Yes. DBI::DBD says that dbdimp.h in part defines macros that rename the generic names like dbd_db_login to database specific names like ora_db_login. This avoids name clashes and enables use of different drivers when you work with a statically linked perl. Yes. PostgreSQL's PREPARE wants a list of column types when you call prepare, so as proof of concept I did a (varchar, varchar, varchar...) for the column types, but that ends up breaking some things (like UPDATE INSERT, and when it checks an operation for castability). Tom has made some mumblings about making this easier, but I don't know if anything has been done. But I was under the assumption that if you used text for the data types that they would be cast without too much trouble. Which does not make sense to me... postgres knows the fields types why does it not set them correctly instead of making the application programmer enumerate them... (or maybe give a type that causes pg to not do checking. -- pg does the checks twice once on prepare and then it does them again on execute, so again why not just sub in the correct types if nothing was enumerated beforhand on prepare and let the checks on execute handle the type checks?. Or am I missing something? Grr. This is beyond my limited knowledge, I'm afraid. I know, those might be easier for the user, but for all interal stuff, I am using the ones extraced from pg header files: grep '^#define' /data/dnloads/postgresql-7.3/src/include/catalog/pg_type.h |grep OID pg_typeOID.h And I think that they should be available to the perl programmer as well. Absolutely. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
RE: passing more than one ARGV value
This really isn't a DBI question and might be better suited to the [EMAIL PROTECTED]
Mailing list.
Hello ,
I am writing a user registration script which once the
user has filled in the form it emails them a simple html
email with a link for them to click to validate that there
email address is real.
i.e
Print 'a
Href=http://www.mydomain.com/cgi-bin/script.pl?confirm?you@yo
urdomain.com
First off this link is bad it should dbe script.pl?[EMAIL PROTECTED]
Click to validate/A href;
Ok so far but when the link is clicked the script will not
pick up the second variable I am using
Second you only have one key value pair
$process = $ARGV[0];
$somevariable = $ARGV[1];
Third ARGV is best suited for the command line.
Use CGI.pm to parse input instead.
Fomr what it looks like from your script you nedd to make your link
Script.pl?proc=confirm[EMAIL PROTECTED]
Then your script would be like
use CGI;
$cgi = new CGI;
$process = $cgi-param('proc');
$email = $cgi-param('email');
...
if ($process EQ confirm)
{
do_something;
}
else
{
do_somethingelse
}
I am relatively new to perl so I may be going about it in
completely the wrong way can anyone help me out here please.
Thanks
James
These disclaimers don't do anything and are anoying.
***DISCLAIMER***
This Email and any files transmitted with it are confidential
and intended solely for the use of the individual to whom or
the entity to which they are addressed. If you have received
this email in error please notify the sender immediately.
Please note that any views or opinions presented in this
email are those of the author and do not necessarily
represent those of Letterbox Mail Order Limited. The
recipient should check this email and any attachments for the
presence of viruses. Letterbox Mail Order Limited accepts no
liability for any damage caused by any virus transmitted via
this email.
Re: [INTERFACES] Prepare and prepare ?
On Wednesday, February 12, 2003, at 08:49 PM, Bruce Momjian wrote: Let's get the small UTF patch into a DBD:pg release, then we can just put it all into the main CVS and do a beta/final release with his changes. I don't see why we need to create a branch. Works for me...unless Rudy's planning to break the backwards compatibility of the UTF-8 patch. ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: [INTERFACES] Prepare and prepare ?
On Wed, 12 Feb 2003, David Wheeler wrote: On Wednesday, February 12, 2003, at 08:49 PM, Bruce Momjian wrote: Let's get the small UTF patch into a DBD:pg release, then we can just put it all into the main CVS and do a beta/final release with his changes. I don't see why we need to create a branch. Sounds good to me. Works for me...unless Rudy's planning to break the backwards compatibility of the UTF-8 patch. ;-) I would rather it be done the right way the first time; that being said, we can add the whatever_utf_8 (don't remember name from patch) attribute and then: 1) Flag it in the docs as expermental and don't use. 2) or when DBD::Pg decides that PostgreSQL wants to send UTF data, use the whatever_utf_8 attribute to decide whether to flag the returned data as such (ie. set the default to false for now, if whatever_utf_8 is true trun on UTF for all data coming out of the db. Then in the next version set the default to true, and set UTF8 iff whatever_utf_8 is true and DBD::Pg the client character set is UTF8). 3) do both. 4) do something better. With 2, the patch goes in as is and backwards compatibility does not get broken in the next version. Just a thought. Ideas, Suggestions? -r
