Re: (Fwd) help me
Install Activestate Perl (http://www.ActiveState.com/). Read the documentation for PPM. Use PPM to install DBI. Use PPM to install DBD-Oracle8. -- Mac :}) ** I normally forward private database questions to the DBI mail lists. ** Give a hobbit a fish and he'll eat fish for a day. Give a hobbit a ring and he'll eat fish for an age. - Original Message - Date: Tue, 20 Mar 2001 18:55:11 -0800 (PST) From: tan minh [EMAIL PROTECTED] Subject: help me To: [EMAIL PROTECTED] Please tell me buil method "perl connect oracle" ? My platform is windows 98, perl5, Oralce8.1.
RE: installing DBI on windows
First are you saying this... ppm install DBI If yes then your problem is that your ActivePerl installation might be too old. Upgrade to 5.6 which is now available and that should solve it. When you use old perl installations they ususally require a lower version of .pm files and therefore can't find them. Ilya Sterin -Original Message- From: Perl To: Sterin, Ilya Cc: dBI MAIL USERS Sent: 3/21/01 1:07 AM Subject: Re: installing DBI on windows Hello, Thanks for your response, Actually, I am not behind any firewall because I have been able to successfully install DBD-mysql using PPM, and the file was found without any problem from its online PPD file located at http://www.perl.com/CPAN-local/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd I wonder if there is an equivalent file for DBI because PPM is not finding it. Tascien - Original Message - From: "Sterin, Ilya" [EMAIL PROTECTED] To: "Perl" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 10:12 PM Subject: RE: installing DBI on windows Do you have internet connection? If yes you must be behid firewall, see ppm docs. Ilya Sterin -Original Message- From: Perl [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 12:58 AM To: dBI MAIL USERS Subject: installing DBI on windows Installing DBI on windows just failing. Where can I get a ppd file for DBI? Here is the error I am getting: = Error installing package 'DBI': Could not locate a PPD file for package DBI = Any help please ? BN3 Hosted Customer Service Solution, basic service FREE. CRM enable your web site in 5 minutes! http://www.bn3.com
Re: Connect to Oracle using Oracle Names
Oracle Names is supported. Ensure you have your SQLNET.ORA file set to use names
if the entry is not found in the tnsnames.ora file.
ie NAMES.DIRECTORY_PATH= (ONAMES, TNSNAMES)
If you can connect to sqlplus via names, you should be able to connect via dbi.
Kwabena
"Ben Schol" [EMAIL PROTECTED] on 21/03/2001 15:07:12
To: "[EMAIL PROTECTED]" [EMAIL PROTECTED]
cc:(bcc: Kwabena ASARE/IBEU/HSBC)
Subject: Connect to Oracle using Oracle Names
Hi,
I'm trying to connect to an Oracle database using Oracle Names but cannot
get it to work. If I add the database to tnsnames.ora it works fine.
Is Oracle Names not supported and if not will it ever be supported?
Ben Schol ([EMAIL PROTECTED])
This message originated from the Internet. Its originator
may, or may not be who they claim to be, and the information
contained herein may, or may not be accurate.
{\rtf1\ansi\deff0{\fonttbl {\f0\fmodern\fcharset0 Courier New;}}
\uc1\pard\lang1033\ulnone\f0\fs20 Hi,\par
\par
I'm trying to connect to an Oracle database using Oracle Names but cannot get it
to work. If I add the database to tnsnames.ora it works fine.\par
\par
Is Oracle Names not supported and if not will it ever be supported?\par
\par
\par
Ben Schol ([EMAIL PROTECTED])\par
}
___
This transmission has been issued by a member of the HSBC group ("HSBC")
for the information of the addressee only and should not be reproduced
and / or distributed to any other person. Each page attached hereto must
be read in conjunction with any disclaimer which forms part of it. Unless
otherwise stated, this transmission is neither an offer nor the solicitation
of an offer to sell or purchase any investment. Its contents are based on
information obtained from sources believed to be reliable but HSBC makes
no representation and accepts no responsibility or liability as to its
completeness or accuracy.
[ANNOUNCE] Orac-1.2.3.tar.gz Perl/Tk Perl DBI Tool
Hi Everyone, Richard Sutherland and I are revamping the Orac Perl/Tk Perl DBI program. This now makes liberal use of Richard's DDL-Oracle package (required for Oracle usage) and we're also beginning to make use of Dean Arnold's DBD-Chart package (not required, but if available on your local Perl system, made use of, if also accompanied by Tk::PNG). Orac-1.2.3 is now available on CPAN, here: = http://www.perl.com/CPAN-local/modules/by-module/DBI/Orac-1.2.3.tar.gz (if your local mirror is still only displaying Orac-1.2.2, you may want to wait for 1.2.3 to propagate, as a few 1.2.2 buggettes needed immediate squashing) DDL-Oracle is available here: = http://www.perl.com/CPAN-local/modules/by-authors/id/R/RV/RVSUTHERL/DDL-Oracle-1.06.tar.gz DBD-Chart is available here: = http://www.perl.com/CPAN-local/modules/by-module/DBD/DBD-Chart-0.30.tar.gz The use of Richard's DDL-Oracle package will hopefully, within a few weeks, allow us to drop any restrictions as we gradually remove all of the old scripts copyrighted to Brian Lomasky, and replace them with DDL-Oracle equivalents to get to a full GPL status. The other main change is that now Oracle Developers can now use Orac, as well as Oracle DBAs. There's not much functionality as yet, but we'll be adding to this constantly. If any Oracle developers would like to send me any wish-lists, I'll do what I can to add them into the program. I'd like to provide an Oracle open source alternative to Toad, if I possibly can. I'm also on the lookout for any DBA/Developer SQL scripts which give name/value information pairings which can be turned into useful charts. You can see examples of these charts here: = http://home.earthlink.net/~darnold/dbdchart/ Finally, we're not taking many prisoners on this Orac development run, and consequently the program will not be super-stable for the immediate future. Orac-1.2.0 is still recommended for stable DBA usage :-) All suggestions welcome! 8) Rgds, AndyD = [EMAIL PROTECTED] O'Reilly's "Oracle and Open Source": = http://www.oreilly.com/catalog/oracleopen/ Orac, Perl/Tk and Perl DBI Database DBA Development Tool: = http://www.perl.com/CPAN-local/modules/by-module/DBI/ANDYDUNC/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
DB2 vs. Oracle
Question: Oracle has been a royal pain in the ass for us in a couple of projects recently done and I am considering switching to DB2. First, I need some opinions of feasibility (or, how difficult it'll be compared to Oracle): The database itself is on an OS/390 mainframe and the front-end is a website based on Perl CGI scripts. Oracle required that the client software be installed, configured, and that a text file be updated manually. Oracle tables also do not resize themselves dynamically and our data is very dynamic, making this a critical need. Individual Table size requirements are highly unpredictable--growing and shrinking by wide margins in different tables each day. What all is involved with installing and configuring the drivers and Perl DBI modules for DB2? Do the whole clients need to be installed as with Oracle? Do I have to explicitly define each connection I will be making in config files for it? (That requirement also prevents us from using Oracle for another project--if DB2 works better, we'll be able to get rid of Oracle on the mainframe and migrate it to Solaris for the systems that still require it). --Matthew
Re: DB2 vs. Oracle
Use locally managed tablespaces in oracle8i and set the autoextend feature ON
for the datafiles. The file/database will just grow 'indefinitely' to accomodate
any growth in objects (provided you have the space). The auto extend feature is
also available in oracle8 but you would have to use a dictionary managed
tablespace.
Kwabena
"Matthew Tedder" [EMAIL PROTECTED] on 21/03/2001 16:38:09
To: Kwabena ASARE/IBEU/HSBC@HIBM, [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: DB2 vs. Oracle
Question:
Oracle has been a royal pain in the ass for us in a couple of projects
recently done and I am considering switching to DB2. First, I need some
opinions of feasibility (or, how difficult it'll be compared to Oracle):
The database itself is on an OS/390 mainframe and the front-end is a website
based on Perl CGI scripts. Oracle required that the client software be
installed, configured, and that a text file be updated manually. Oracle tables
also do not resize themselves dynamically and our data is very dynamic, making
this a critical need. Individual Table size requirements are highly
unpredictable--growing and shrinking by wide margins in different tables each
day.
What all is involved with installing and configuring the drivers and Perl DBI
modules for DB2? Do the whole clients need to be installed as with Oracle? Do
I have to explicitly define each connection I will be making in config files for
it? (That requirement also prevents us from using Oracle for another
project--if DB2 works better, we'll be able to get rid of Oracle on the
mainframe and migrate it to Solaris for the systems that still require it).
--Matthew
This message originated from the Internet. Its originator
may, or may not be who they claim to be, and the information
contained herein may, or may not be accurate.
___
This transmission has been issued by a member of the HSBC group ("HSBC")
for the information of the addressee only and should not be reproduced
and / or distributed to any other person. Each page attached hereto must
be read in conjunction with any disclaimer which forms part of it. Unless
otherwise stated, this transmission is neither an offer nor the solicitation
of an offer to sell or purchase any investment. Its contents are based on
information obtained from sources believed to be reliable but HSBC makes
no representation and accepts no responsibility or liability as to its
completeness or accuracy.
distinguishing NULL from NULL
I'm having a problem where my intention is to insert a NULL value into a
nullable float column, however the result ends up being a floating point
0.
I have an object created by Class::Struct that contains a field for each
row in a particular db table. If I have no value to assign to a field,
I'm entering NULL:
i.e. $obj-member("NULL")
This works fine for (var)char datatypes, but apparently the string NULL is
automatically converted to 0.00 when I do:
my $sth = $dbh-prepare( EOF
insert into owner.table
(column1)
values (?)
EOF
);
$sth-execute($obj-member) or die .
I've tried 2 things to correct this. First, I tried using
$obj-member(NULL), however that is not allowed under strict
subs. Second, I was advised to try $obj-member(undef), however that
caused a segmentation fault (? was replaced by nothing after bind_param).
If I go into isql and manually type NULL... it works. Does anyone know
how I can assign NULL to my object member variable and have it be
correctly interpreted as NULL and not "NULL"?
I'm running this on SunOS 5.6 using Sun's Perl 5.00404, DBI.pm 1.13,
DBD::Sybase 0.21 and Sybase 11.1.1. Upgrading these is not possible... I
just have to live with it.
Thanks,
Curt Crandall
RE: selectall_hashref, a future feature?
Mark,
I agree. Instead of pointing out the intricacies of the docs to you I
think I'll comment on the point of your post...
Yes, I think a selectall_hashref function would be a clean and concise
method that would improve the clarity of the DBI spec.
-Original Message-
From: Mark Stosberg [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 3:06 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: selectall_hashref, a future feature?
[EMAIL PROTECTED] wrote:
It's not undocumented. First we look up
selectall_arrayref. We see:
$ary_ref = $dbh-selectall_arrayref($statement, \%
attr);
This utility method combines /prepare, /execute and
/fetchall_arrayref into a single call. It returns a
reference to an array containing a reference to an array
for each row of data fetched.
I already knew how to do this using fetchall_arrayref, but I don't
believe there is any documentation on how to do this one fell swoop:
perldoc DBI | grep dbi_fetchall_arrayref_attr
That returns no result, but it is explicitly mentioned mentioned
in the code:
sub selectall_arrayref {
my ($dbh, $stmt, $attr, @bind) = @_;
my $sth = (ref $stmt) ? $stmt
: $dbh-prepare($stmt, $attr);
return unless $sth;
$sth-execute(@bind) || return;
my $slice = $attr-{dbi_fetchall_arrayref_attr}; # typically undef
return $sth-fetchall_arrayref($slice);
}
Based on the docs for fetchall_arrayref, I believe this would be the
correct way to call it:
$DBH-selectall_arrayref("SELECT * from FOO", {
dbi_fetchall_arrayref_attr = {} });
I can't find any other way to accomplish this with a single DBI
statement, so I continue to think this is undocumented feature. :) (and
one in need of a handy shortcut. :)
-mark
personal website } Summersault Website Development
http://mark.stosberg.com/{ http://www.summersault.com/
RE: distinguishing NULL from NULL
You can't quote NULL, therefore assign undef to your object and then pass to
execute.
Ilya Sterin
-Original Message-
From: Curt Russell Crandall
To: [EMAIL PROTECTED]
Sent: 3/21/01 10:03 AM
Subject: distinguishing NULL from "NULL"
I'm having a problem where my intention is to insert a NULL value into a
nullable float column, however the result ends up being a floating point
0.
I have an object created by Class::Struct that contains a field for each
row in a particular db table. If I have no value to assign to a field,
I'm entering NULL:
i.e. $obj-member("NULL")
This works fine for (var)char datatypes, but apparently the string NULL
is
automatically converted to 0.00 when I do:
my $sth = $dbh-prepare( EOF
insert into owner.table
(column1)
values (?)
EOF
);
$sth-execute($obj-member) or die .
I've tried 2 things to correct this. First, I tried using
$obj-member(NULL), however that is not allowed under strict
subs. Second, I was advised to try $obj-member(undef), however that
caused a segmentation fault (? was replaced by nothing after
bind_param).
If I go into isql and manually type NULL... it works. Does anyone know
how I can assign NULL to my object member variable and have it be
correctly interpreted as NULL and not "NULL"?
I'm running this on SunOS 5.6 using Sun's Perl 5.00404, DBI.pm 1.13,
DBD::Sybase 0.21 and Sybase 11.1.1. Upgrading these is not possible...
I
just have to live with it.
Thanks,
Curt Crandall
RE: DBI Capability Questions
Yes/no answers would be more than sufficient. Questions: 1. I'd like to provide the user with results to SQL queries to a few databases (Oracle, MySQL, ...). Can the Perl DBI be set up so that it can easily switch between databases? For example, if the user has a form that sends the database type, host, database name, and port info to the Perl DBI, will the database be transparent to the user (assuming all have the same tables present)? yes, unless your app uses some functionality present in one DBMS or driver that is not available in another one (eg calling stored procedures). 2. If #1 is true, can I load multiple modules to support the different databases, or would they conflict with each other? They get along fine in my experience. Open multiple sessions on multiple machines running several different OS's or DBMS's simultaneously if you like. 3. Are some database interfaces better supported than others? Yes. I'm most familiar with the Oracle driver, and it is very solid. 4. If I set up the Perl DBI using CGI on a Win 2K machine, it should work the same on a Linux or Solaris box, correct? I've moved cgi scripts between linux, solaris, hp-ux and NT4 and had them run the same without changing a single line of code. HTH.
DBD::Sybase freezes on execute()
Hi, I am having problems with DBD::Sybase when execute() blocks and never returns - don't know for sure if it's the driver or maybe the client library (I am using DBI 1.14, DBD::Sybase 0.91 and Sybase server 11.0.3 on Linux). Once in a while - approximately once per every 10,000 SQL queries - could be select, or update, or insert, execute() would block and just sit there forever until the process is killed. I worked around this by specifying timeout parameter in DSN and retrying execute if failed on timeout - unfortunately this isn't perfect since when it fails on insert, the data may have been pushed to DB already and the second insert with the same data will fail in most cases because of data integrity constraints. I tried downgrading DBD::Sybase to a few last versions, didn't seem to help. Is anyone else experiencing this problem, or will it help if I switch to Sybase server 12.0? Thanks Vlad Jebelev
[suggest...] how to...
Hi, Is there a particularity, cause if I call a perl script, with undef value (no '' like), but wanted value in execute method, i've got some several problems... Any tips to stop this faillure ? I use CGI.pm currently with DBI 1.14... Thanks, -- Nicolas JOURDEN - (+33) 0681940905 - Uin : 41100039 - [EMAIL PROTECTED] - http://ddx.wedoo.com/ Programmateur Web et Interne... http://wedoo.com - Une nouvelle maniere de surfer !!!
Re: DBD::Sybase freezes on execute()
On Wed, 21 Mar 2001, Vladimir Jebelev wrote: Hi, I am having problems with DBD::Sybase when execute() blocks and never returns - don't know for sure if it's the driver or maybe the client library (I am using DBI 1.14, DBD::Sybase 0.91 and Sybase server 11.0.3 on Linux). Once in a while - approximately once per every 10,000 SQL queries - could be select, or update, or insert, execute() would block and just sit there forever until the process is killed. I worked around this by specifying timeout parameter in DSN and retrying execute if failed on timeout - unfortunately this isn't perfect since when it fails on insert, the data may have been pushed to DB already and the second insert with the same data will fail in most cases because of data integrity constraints. Welcome to the world of deadlocks. I can only recommend some good long reading of the rather excellent Sybase documentation on deadlocks (which will happen even if you upgrade to 12.0 and use row level locking). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: :Sybase freezes on execute()
You could take a look at your approach... perhaps doing all your work in a temporary table before making changes in the real one would help. Like Matt said read the docs, perhaps a simple switch to row-level locking would help. Also, be sure that your changes are atomic, ie all or nothing, see Autocommit = 0 for DBI and begin transaction / end transaction / commit / rollback for Sybase. Then if a resource conflict happened and you had to kill your DBI script to resolve the issue, you could run it again without fear that it did half the work already and now it doesn't know how to recover. transactions really help prevent those probs. -Original Message- From: Vladimir Jebelev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 12:04 PM To: [EMAIL PROTECTED] Subject: DBD::Sybase freezes on execute() Hi, I am having problems with DBD::Sybase when execute() blocks and never returns - don't know for sure if it's the driver or maybe the client library (I am using DBI 1.14, DBD::Sybase 0.91 and Sybase server 11.0.3 on Linux). Once in a while - approximately once per every 10,000 SQL queries - could be select, or update, or insert, execute() would block and just sit there forever until the process is killed. I worked around this by specifying timeout parameter in DSN and retrying execute if failed on timeout - unfortunately this isn't perfect since when it fails on insert, the data may have been pushed to DB already and the second insert with the same data will fail in most cases because of data integrity constraints. I tried downgrading DBD::Sybase to a few last versions, didn't seem to help. Is anyone else experiencing this problem, or will it help if I switch to Sybase server 12.0? Thanks Vlad Jebelev
Re: DBD::Sybase freezes on execute()
Matt Sergeant writes: On Wed, 21 Mar 2001, Vladimir Jebelev wrote: Hi, I am having problems with DBD::Sybase when execute() blocks and never returns - don't know for sure if it's the driver or maybe the client library (I am using DBI 1.14, DBD::Sybase 0.91 and Sybase server 11.0.3 on Linux). Once in a while - approximately once per every 10,000 SQL queries - could be select, or update, or insert, execute() would block and just sit there forever until the process is killed. I worked around this by specifying timeout parameter in DSN and retrying execute if failed on timeout - unfortunately this isn't perfect since when it fails on insert, the data may have been pushed to DB already and the second insert with the same data will fail in most cases because of data integrity constraints. Welcome to the world of deadlocks. I can only recommend some good long reading of the rather excellent Sybase documentation on deadlocks (which will happen even if you upgrade to 12.0 and use row level locking). Sorry Matt, but that's not what's happening at all. If this were a deadlock one of the connections would get a 1205 error (i.e. "your command has been aborted as the deadlock victim"). In this case this is a bug in the network handling code of the original 11.0.3.3 release for linux. Upgrading to 11.0.3.3#6 should fix the problem. Michael -- Michael Peppler - Data Migrations Inc. - [EMAIL PROTECTED] http://www.mbay.net/~mpeppler - [EMAIL PROTECTED] International Sybase User Group - http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
Re: DB2 vs. Oracle
Comments below marked with ###. -- Mac :}) ** I normally forward private database questions to the DBI mail lists. ** Give a hobbit a fish and he'll eat fish for a day. Give a hobbit a ring and he'll eat fish for an age. - Original Message - From: "Matthew Tedder" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 8:38 AM Subject: DB2 vs. Oracle The database itself is on an OS/390 mainframe and the front-end is a website based on Perl CGI scripts. Oracle required that the client software be installed, configured, and that a text file be updated manually. Oracle tables also do not resize themselves dynamically and our data is very dynamic, making this a critical need. Individual Table size requirements are highly unpredictable--growing and shrinking by wide margins in different tables each day. ### Oracle tables will grow as necessary as long as you define the storage parameters correctly. Hopefully you at least know the upper bounds of your data size or you may overflow you disk physical limits. The only ways to schrink a table's storage are to TRUNCATE the table or DELETE it and then CREATE it again. ### If the table sizes only vary by a few tens of megabytes from day to day, you'd be better off just sizing the tables for the maximum size. If they vary by gigabytes, maybe you could combine some of the input streams so fewer tables are affected. ### If the text file you are refering to is tnsnames.ora, you can use the 'ifile=' directive in the client tnsnames.ora file to point to a central copy. You could also use Oracle Names to manage database network names. DBD::Oracle also accepts connect() DSNs in the form "dbi:Oracle:host=$host;sid=$inst" which bypasses tnsnames.ora and Oracle Names completely. What all is involved with installing and configuring the drivers and Perl DBI modules for DB2? Do the whole clients need to be installed as with Oracle? Do I have to explicitly define each connection I will be making in config files for it? (That requirement also prevents us from using Oracle for another project--if DB2 works better, we'll be able to get rid of Oracle on the mainframe and migrate it to Solaris for the systems that still require it). ### I suspect you will have the same problems with DB2. How can you connect to a database without indicating _somewhere_ how to find it.
RE: [suggest...] how to...
Nicolas, sorry but I am not sure what you are talking about. Could you please send us a sample script, or explain a little more. Thanks. Ilya Sterin -Original Message- From: Nicolas JOURDEN To: [EMAIL PROTECTED] Sent: 3/21/01 1:04 PM Subject: [suggest...] how to... Hi, Is there a particularity, cause if I call a perl script, with undef value (no '' like), but wanted value in execute method, i've got some several problems... Any tips to stop this faillure ? I use CGI.pm currently with DBI 1.14... Thanks, -- Nicolas JOURDEN - (+33) 0681940905 - Uin : 41100039 - [EMAIL PROTECTED] - http://ddx.wedoo.com/ Programmateur Web et Interne... http://wedoo.com - Une nouvelle maniere de surfer !!!
Re: DB2 vs. Oracle
On Wed, 21 Mar 2001, Matthew Tedder wrote: Question: Oracle has been a royal pain in the ass for us in a couple of projects recently done and I am considering switching to DB2. First, I need some opinions of feasibility (or, how difficult it'll be compared to Oracle): I may be prejudiced, since I work for IBM, but DB2 is a very slick product. The database itself is on an OS/390 mainframe and the front-end is a website based on Perl CGI scripts. Oracle required that the client software be installed, configured, and that a text file be updated manually. Oracle tables also do not resize themselves dynamically and our data is very dynamic, making this a critical need. Individual Table size requirements are highly unpredictable--growing and shrinking by wide margins in different tables each day. What all is involved with installing and configuring the drivers and Perl DBI modules for DB2? Do the whole clients need to be installed as with Oracle? Do I have to explicitly define each connection I will be making in config files for it? (That requirement also prevents us from using Oracle for another project--if DB2 works better, we'll be able to get rid of Oracle on the mainframe and migrate it to Solaris for the systems that still require it). For better or for worse, DB2 requires a "thick" client install _except_ on Win* and NT where you can have "thin" clients that load DLLs dynamically from a master application server. Connections are defined in DB2-ese by 'cataloging' remote nodes (machines, basically) and adding databases within those nodes to a local database directory. These operations can be performed either from the Control Center (a nice Java GUI app) or by entering DML commands into the CLP (command line processor, somewhat similar to Oracle's SQL prompt). The Perl DBD::DB2 driver is full-featured and solid. I think it's maintained by a person in the DB2 software group in Toronto. Also, AFAIK IBM does not enjoin you from publishing comparitive benchmarks as a condition of licensing. Steve
Re: urgent help! DBD::Informix
liml wrote: now ,I am installing DBD-Informix-0.95, but I don't how to set up the setting DBD_INFORMIX_USE_EPRINTF_CODE and DBD_INFORMIX_DISABLE_ASSERT in the environment before running 'perl Makefile.PL'. Could you help me? Leesa [EMAIL PROTECTED] Please use the current version, 1.00.PC1. It has been current for a year now; 0.95 is very old. In the current version, you have to explicitly enable inserts with DBD_INFORMIX_ENABLE_ASSERT. Do you know that you need the DBD_INFORMIX_USE_EPRINTF_CODE? It is only necessary when your installation is slightly broken (but it does then fix a fairly common problem). Only use it if your main build fails. And if you use DBD_INFORMIX_DISABLE_ASSERT in 0.95 or fail to use DBD_INFORMIX_ENABLE_ASSERT in a later version, you should not need to worry about the code for eprintf() since it is only used when assertions are enabled. Which platform are you working on? Assuming it is Unix/Linux, which shell are you using? You simply need to know how to set environment variables, and if you don't know how to do that, you've got bigger problems than trying to install DBD::Informix, I'm afraid. -- Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) Guardian of DBD::Informix 1.00.PC1 -- see http://www.cpan.org/ #include disclaimer.h
