Re: perl dbi sybase error handling question
Hi Glen, I hope you don't mind the (nearly) fullquote to keep the list informed. G S [EMAIL PROTECTED] wrote: Hi Hans, Thank you for your response. I was able to capture $retCode using your suggestion. I eventually removed the error handler (after the ||) just to isolate something I do not understand. I am tracking down an issue where errors are not returned from $sth-execute() when a parameter data type mismatch occurs when calling a stored procedure. It actually looks like it might be a bug somewhere. Maybe in the Sybase driver. Here is my example with updated comments. The problem is in scenario 2. Do you have an explanation for it? Thanks. Glen # Execute query. Capture $retCode for later examination. $retCode = $sth-execute() # Examine $retCode, err, and errstr print BRafter execute retCode is: $retCode br; printf(dbh-execute():br . dbh-err= '%s'br . dbh-errstr= '%s'br, $dbh-err, $dbh-errstr ); [ ... ] scenario 2 -- Here I deliberately passed an incorrect data type as a parameter to the stored procedure. As you can see, there was an error, but the value returned from $sth-execute() was -1. I would expect it to be undefined. This looks like a bug, maybe in the Sybase driver. What do you think? after execute retCode is: -1 dbh-execute(): dbh-err= '257' dbh-errstr= 'Server message number=257 severity=16 state=1 line=0 server=SCATS1P_SQL procedure=sc_deal_update text=Implicit conversion from datatype 'VARCHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run this query.' [ ... ] As I am no sybase expert, I am bringing the question back to the list. Perhaps you could send a sample SQL code that demonstrates the problem to the list? Other potentially useful information includes the version of DBD::Sybase you are using, the DBI version, the version of your Sybase (or FreeTDS) client library, and of your DB Server. Hans -- Hans Ranke [EMAIL PROTECTED] Lehrstuhl fuer Institute for Entwurfsautomatisierung Electronic Design Automation Technische Universitaet Muenchen, Germany Phone +49 89 289 23660 Fax +49 89 289 63666
Segmentation Fault when building .rpm from DBD-Sybase-0.94.tar.gz
Hi,
I am a happy user of DBD::Sybase to enable my perl to talk with MS SQL
Server.
The DBD::Sybase I am using is .tar.gz, I need distribution in .rpm as the
deployment machine don't have make :)
What I have done is the following:-
(1)
/usr/lib/rpm/cpanflute2 DBD-Sybase-0.94.tar.gz // convert .tar.gz to
.src.rpm
(2)
vi perl-DBD-Sybase.spec // change the following line, so SYBASE environment
variable is set
CFLAGS=$RPM_OPT_FLAGS SYBASE=/usr perl Makefile.PL
(3)
rpm -bb perl-DBD-Sybase.spec //build the .rpm from .spec file, DONE
(4)
rpm -ivh perl-DBD-Sybase-0.94-8.i386.rpm // Done, 100% complete
(5)
// try a connetion test script (see below...) from freetds.org
perl sybasetest.pl
segmentation fault
Please advice and where should I start looking for any mistake I made?
Thank you,
Calvin
==
## sybasetest.pl
#!/usr/bin/perl -w
use DBI;
my $dbh = DBI-connect(dbi:Sybase:server=192.168.250.71, 'lbs', 'lbs',
{PrintError = 0});
die Unable for connect to server $DBI::errstr
unless $dbh;
my $rc;
my $sth;
#$sth = $dbh-prepare(select [EMAIL PROTECTED]@servername);
$sth = $dbh-prepare(select * from AP_INFO);
if($sth-execute) {
while(@dat = $sth-fetchrow) {
print @dat\n;
}
}
=
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: Using perl 5.8.0?
Lincoln Stein wrote: My test case is part of a big script that requires BioPerl. What I'll do is to pull it out into a self-contained script. Frankly I don't think that this has anything to do with DBI, but rather something fundamental that changed with Perl's IO handling. A whole bunch of symptoms showed up in 5.8: 1) tied print in mod_perl stopped working Which version of mod_perl. The internal implementation of tied filehandles changes between perl 5.6 and perl 5.7/8. The first version of mod_perl which will provide tied print with 5.8.1 is 1.27. I don't know if the required patch is in any 2.x version of mod_perl. -- Charles Jardine - Computing Service, University of Cambridge [EMAIL PROTECTED]Tel: +44 1223 334506, Fax: +44 1223 334679
DBI::Format in DBI-1.34 vs. DBI-Shell-11.91
There seem to be conflicting versions of DBI::Format in DBI-1.34 and DBI-Shell-11.91. After upgrading to the recent DBI-1.34 I again get a warning from the CPAN r command which reports that there is a more recent version of DBI::Format to be found in DBI-Shell-11.91.tar. When I read that the new DBI-1.34 removed the old DBI::Shell from distribution, I was surporised that it kept DBI::Format. I couldn't find any perl references in DBI-1.34 that refered to DBI::Format, so perhaps if the official DBI::Format is being kept up to date in DBI-Shell-11.91, you could either remove it from this package, or add a not describing where to get the most recent version. What do you think?
Bug in Sybase driver?
I am tracking down an issue where an error condition is not returned from a call to $sth-execute(). Here is my example code with comments. I show the output for 3 tests. Test 1 and test 2 produce results that I understand. The problem is in test 3. In test 3 I would expect the returned value (retCode) for the error condition to be undefined or 0. Instead it is -1. Is this a bug in the Sybase driver? If so, how do I report such bugs? Do you have an explanation for it? --- code example - # Execute query. Capture $retCode for later examination. $retCode = $sth-execute() # Examine $retCode, err, and errstr print BRafter execute retCode is: $retCode br; printf(dbh-err= '%s'br . dbh-errstr= '%s'br, $dbh-err, $dbh-errstr ); --- test 1 -- Here is the output from successful execution. You can see that retCode is -1, which is what I would expect in a successful $sth-execute(). after execute retCode is: -1 dbh-err= '' dbh-errstr= '' --- test 2 -- Here I deliberately changed the stored procedure name to an incorrect one. $retCode is not defined, which is what I would expect in an $sth-execute() error condition. after execute retCode is: dbh-err= '2812' dbh-errstr= 'Server message number=2812 severity=16 state=5 line=22 server=SCATS1P_SQL text=Stored procedure 's_deal_update' not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output). ' --- test 3 -- Here I deliberately passed an incorrect data type as a parameter to the stored procedure. As you can see, there was an error, but the value returned from $sth-execute() was -1 (indicating success?). I would expect it to be undefined. This looks like a bug, maybe in the Sybase driver. What do you think? If it is a bug, how and where do I report it? after execute retCode is: -1 dbh-err= '257' dbh-errstr= 'Server message number=257 severity=16 state=1 line=0 server=SCATS1P_SQL procedure=sc_deal_update text=Implicit conversion from datatype 'VARCHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run this query.' _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
How do I respond to a thread?
I have been posting messages here by emailing to [EMAIL PROTECTED] Is there a way to post messages so that they are part of an ongoing thread? Thanks. _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
DBD:oracle installtion problem
I searched google, but could not find the answer. We are using oracle 9.2.0.2.0 SunOS enigma 5.7 Generic_106541-18 sun4u sparc SUNW,Ultra-4 This is perl, v5.6.1 built for sun4-solaris DBI 1.34 but when I was trying to install DBD:Oracle 1.12 at make test, I got Test returned status 255 (wstat 65280, 0xff00) t/plsql.Can't load 'blib/arch/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: libwtc8.so: open failed: No such file or directory at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at t/plsql.t line 17 Compilation failed in require at t/plsql.t line 17. BEGIN failed--compilation aborted at t/plsql.t line 17. t/plsql.dubious Test returned status 255 (wstat 65280, 0xff00) t/reauthskipped test on this platform Failed Test Status Wstat Total Fail Failed List of Failed t/base.t 52 40.00% 4-5 t/general.t 255 65280?? ?? % ?? t/long.t 255 65280?? ?? % ?? t/ph_type.t 255 65280?? ?? % ?? t/plsql.t255 65280?? ?? % ?? 1 test skipped. Failed 5/6 test scripts, 16.67% okay. 2/5 subtests failed, 60.00% okay. *** Error code 29 make: Fatal error: Command failed for target `test_dynamic' could somebody help me out? Thanks _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
DBD::CSV
Hello, I have changed from MySQL DB to CSV File (DBD::CSV). And also from Linux to Windows A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? B) I have a select like this: ...WHERE ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) values1,values1,values1,values2,values2,values2,values3,values3,values3 with Linux this is not a problem, but under Windows I get no data and also no error. I removed the field3 only then I got data with Windows, but the result looks like WHERE ((field1 like ?) OR (field2 like ?)) has been used for the search. C) There is a different in the order of a table when I use it under Linux or Windows. Under Windows the order is fine but under Linux it looks mixed up. Thanks for any help in advance! Peter
Re: How do I respond to a thread?
On Sat, 01 Mar 2003 12:02:15 -0800 G S [EMAIL PROTECTED] wrote: I have been posting messages here by emailing to [EMAIL PROTECTED] Is there a way to post messages so that they are part of an ongoing thread? That is a function of your email client. Normally, if you reply to a message, the message id of the message you replied to is included in the new message's headers. The receiving email client can then thread the messages using the message id. Threading by subject is also fairly common. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: Strange security problem...Solved?
I ended up changing all my references to CGI-BIN to cgi-bin and ran into the same problem as before when I'd purposely *uppercase* the cgi-bin portion of the url. I ended up creating a shortcut to cgi-bin which is called CGI-BIN and added that directory to the appropriate sections of the httpd.conf file and all seems to be well. Is this how to effectively deal with this situation? Thanks in advance, Cory On Friday, February 28, 2003, at 08:21 PM, Cory Rau wrote: I was messing around at home with a test web server (Windows 2000 Professional, Apache and ActivePerl (all the latest versions of each)) which resides in my office and I typed in the url of a perl script. I purposely mistyped the url with 'cgi-bin' rather than what it actually is, 'CGI-BIN' just to see what would happen. I ended up getting the entire *code* of the perl script in my web browser (latest version of Safari on Mac OS X 10.2.3)! This worries me because my code contains passwords to our database. Is it a well known problem to capitalize the CGI-BIN directory? Should I make it lower case and change my Apache config file as well as any paths to it in my perl scripts? Or is it just a permissions problem? If I re-type the url using upper case CGI-BIN, it works as expected. I'm relatively new to Perl and Apache so forgive me if this is a well know faux pas. I was just wondering if others are aware of this issue. Regards, Cory Rau
Re: DBI::Format in DBI-1.34 vs. DBI-Shell-11.91
On Sat, Mar 01, 2003 at 11:10:34AM -0800, David Dyck wrote: There seem to be conflicting versions of DBI::Format in DBI-1.34 and DBI-Shell-11.91. After upgrading to the recent DBI-1.34 I again get a warning from the CPAN r command which reports that there is a more recent version of DBI::Format to be found in DBI-Shell-11.91.tar. When I read that the new DBI-1.34 removed the old DBI::Shell from distribution, I was surporised that it kept DBI::Format. So was I :) I'd meant to remove it and will do for the next release. Tim.
Re: Strange security problem...Solved?
On Mon, 3 Mar 2003 08:23:11 -0500 Cory Rau [EMAIL PROTECTED] wrote: I ended up changing all my references to CGI-BIN to cgi-bin and ran into the same problem as before when I'd purposely *uppercase* the cgi-bin portion of the url. I ended up creating a shortcut to cgi-bin which is called CGI-BIN and added that directory to the appropriate sections of the httpd.conf file and all seems to be well. Is this how to effectively deal with this situation? It would be more useful to ask in a CGI forum. http://search.cpan.org/author/TIMB/DBI/DBI.pm#Why_doesn_t_my_CGI_script_work_right_ -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
RE: DBD::CSV
Hello, I have changed from MySQL DB to CSV File (DBD::CSV). And also from Linux to Windows There's the first two mistakes! :) A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? THE OS !! WINDOWS is an expensive resource cow, designed to stop working every 2.5 years And make you think you can't live with out it. B) I have a select like this: ...WHERE ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) values1,values1,values1,values2,values2,values2,values3,values 3,values3 with Linux this is not a problem, but under Windows I get no data and also no error. I removed the field3 only then I got data with Windows, but the result looks like WHERE ((field1 like ?) OR (field2 like ?)) has been used for the search. On this one are the tables *exactly* the same? C) There is a different in the order of a table when I use it under Linux or Windows. Under Windows the order is fine but under Linux it looks mixed up. That depends again on if the tables are *exactly* the same and *exactly* what query you use and *exactly* how the software is installed on the OS, and how you assemble the results. Windows and unix behave differently. If you can hack it I'd highly recommend sticking to a flavor of unix. Too many variables to figure out why they are coming back different. Thanks for any help in advance! Peter
RE: Strange security problem...
Not sure with windows, probably should see apache.org for details, but it seems That perhaps There is a 'ScriptAlias' directive for CGI-BIN but not cgi-bin. I'd try adding that in your httpd.conf file or making some kind of symlink or alias with each other for both versions. Also it may be an ExecCGI directive needs to be added for the cgi-bin version. Whatever the case it seems to be an apache configuration isssue since the script works right. It's just that that version of the directory isn't allowed/doesn't know how to execute a script. A better solution would be to install any flavor of unix and use your Windows cd as a coaster and use the manual to make the table legs even. To many Winders issues to make anythign work relyably. DMuey I was messing around at home with a test web server (Windows 2000 Professional, Apache and ActivePerl (all the latest versions of each)) which resides in my office and I typed in the url of a perl script. I purposely mistyped the url with 'cgi-bin' rather than what it actually is, 'CGI-BIN' just to see what would happen. I ended up getting the entire *code* of the perl script in my web browser (latest version of Safari on Mac OS X 10.2.3)! This worries me because my code contains passwords to our database. Is it a well known problem to capitalize the CGI-BIN directory? Should I make it lower case and change my Apache config file as well as any paths to it in my perl scripts? Or is it just a permissions problem? If I re-type the url using upper case CGI-BIN, it works as expected. I'm relatively new to Perl and Apache so forgive me if this is a well know faux pas. I was just wondering if others are aware of this issue. Regards, Cory Rau
RE: Strange security problem...
Sounds like the cgi-bin directory is in the document_root hierarchy it doesn't match the ScriptAlias and get executed so it is just returned as a text file. Make sure the cgi-bin is in a different directory path not in document root then you'll just get a Document not found error. NOTE: Pure conjecture like others I would never consider running Apache/DBI on a windows platform. Among other things windows isn't free :) Ken. -Original Message- From: Dan Muey [mailto:[EMAIL PROTECTED] Sent: 03 March 2003 15:04 To: Cory Rau; [EMAIL PROTECTED] Subject: RE: Strange security problem... Not sure with windows, probably should see apache.org for details, but it seems That perhaps There is a 'ScriptAlias' directive for CGI-BIN but not cgi-bin. I'd try adding that in your httpd.conf file or making some kind of symlink or alias with each other for both versions. Also it may be an ExecCGI directive needs to be added for the cgi-bin version. Whatever the case it seems to be an apache configuration isssue since the script works right. It's just that that version of the directory isn't allowed/doesn't know how to execute a script. A better solution would be to install any flavor of unix and use your Windows cd as a coaster and use the manual to make the table legs even. To many Winders issues to make anythign work relyably. DMuey I was messing around at home with a test web server (Windows 2000 Professional, Apache and ActivePerl (all the latest versions of each)) which resides in my office and I typed in the url of a perl script. I purposely mistyped the url with 'cgi-bin' rather than what it actually is, 'CGI-BIN' just to see what would happen. I ended up getting the entire *code* of the perl script in my web browser (latest version of Safari on Mac OS X 10.2.3)! This worries me because my code contains passwords to our database. Is it a well known problem to capitalize the CGI-BIN directory? Should I make it lower case and change my Apache config file as well as any paths to it in my perl scripts? Or is it just a permissions problem? If I re-type the url using upper case CGI-BIN, it works as expected. I'm relatively new to Perl and Apache so forgive me if this is a well know faux pas. I was just wondering if others are aware of this issue. Regards, Cory Rau
RE: DBD::CSV
From: Dan Muey [EMAIL PROTECTED] A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? THE OS !! WINDOWS is an expensive resource cow, designed to stop working every 2.5 years And make you think you can't live with out it. Please stop flaming based on your personal tastes. It is true that Windows use more resources than Linux in the default setup, but the difference Dan sees has nothing to do with this. It's caused by the DBD::CSV. If he installed Mysql and kept using DBD::mysql he'd see roughly the same results. Dan, you may want to take a look at DBD::SQLite if you do not want to install mysql. Jenda P.S.: Dan, could you try to run the script using DBD::CSV, using the same data, under Linux and let us know how long did it take? = [EMAIL PROTECTED] === http://Jenda.Krynicky.cz = When it comes to wine, women and song, wizards are allowed to get drunk and croon as much as they like. -- Terry Pratchett in Sourcery
Re: Strange security problem...
On Fri, 28 Feb 2003 20:21:29 -0500, Cory Rau wrote: I purposely mistyped the url with 'cgi-bin' rather than what it actually is, 'CGI-BIN' just to see what would happen. I ended up getting the entire *code* of the perl script in my web browser This is OT for perl-DBI, but... I think that your cgi-bin directory must be lying inside your normal webspace. You should move it outside, so the only way to reach it is via that ScriptAlias. -- Bart.
RE: DBD::CSV
Hello, thanks for your answers. I would also like to stick to MySQL, but I have to change it, since there is no DB-Server available. Use a remote one, your isp's perhaps. Anywho... Dan, yes the data of the tables are *exactly* the same!!! How about posting the first few lines form the linux one and form the windows one? When ftping the CSV files up did you do it as binary. ( I've found once when using CSV that they look identicle if you FTP them in ASCII and binary, but if I didn't do them in binary everythingn was screwy ) The querry I use for C) is like: where (field1=?) and (field2=?) order by field3 again the same data and the same query! For showing the data I just use a while loop and display record by record. Again using the same script here and there. Regards - Original Message - From: Dan Muey [EMAIL PROTECTED] To: Peter Schuberth [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 03, 2003 3:35 PM Subject: RE: DBD::CSV Hello, I have changed from MySQL DB to CSV File (DBD::CSV). And also from Linux to Windows There's the first two mistakes! :) A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? THE OS !! WINDOWS is an expensive resource cow, designed to stop working every 2.5 years And make you think you can't live with out it. B) I have a select like this: ...WHERE ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) values1,values1,values1,values2,values2,values2,values3,values 3,values3 with Linux this is not a problem, but under Windows I get no data and also no error. I removed the field3 only then I got data with Windows, but the result looks like WHERE ((field1 like ?) OR (field2 like ?)) has been used for the search. On this one are the tables *exactly* the same? C) There is a different in the order of a table when I use it under Linux or Windows. Under Windows the order is fine but under Linux it looks mixed up. That depends again on if the tables are *exactly* the same and *exactly* what query you use and *exactly* how the software is installed on the OS, and how you assemble the results. Windows and unix behave differently. If you can hack it I'd highly recommend sticking to a flavor of unix. Too many variables to figure out why they are coming back different. Thanks for any help in advance! Peter
Re: How do I respond to a thread?
On Sat, 01 Mar 2003 12:02:15 -0800, G S wrote: I have been posting messages here by emailing to [EMAIL PROTECTED] Is there a way to post messages so that they are part of an ongoing thread? Select reply to respond. Make sure [EMAIL PROTECTED] is amongst the recipients. That's it, basically. -- Bart.
RE: Running SQL from files - was: Your DBI book
I have already realized that simply stripping out the semi-colon will not work with
all situations. I even posted something to that effect.
It would have been nice to know if, say, someone had worked out something to process
SQL files since this is such a common task and developers who don't use perl but work
with Oracle frequently use SQL files.
Having worked with SQL*Plus and Oracle for many years now, I am quite familiar with
it's limitations and its nature. I am not so gullible as to presume that other tools
understand sqlplus syntax.
Please don't characterize anyone as being naive since it assumes that you are not. It
was a simple question. If the answer doesn't not come to you easily in perl then
please don't try to make me question myself. I hate it when people try to educate you
but sidestep the original question.
-Original Message-
From: M Addlework [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 10:16 AM
To: Fernando Luna
Cc: [EMAIL PROTECTED]
Subject: RE: Running SQL from files - was: Your DBI book
Fernando,
It's very naive to view this is just a task for split /;/.
Sqlplus has its own little language, with a grammar and
sytntax, variable substitution, etc. Consider this sqlplus
script:
@defines
whenever sqlerror exit failure
create table prefix._snafu(col varchar2(10))
/
whenever sqlerror continue
insert into prefix._snafu values (:prefix)
/
set scan off
insert into some_table values ('this that');
and it's depdendent script @defines.sql
define prefix='fubar'
var prefix varchar2(30)
exec :prefix := 'prefix'
This is a contrived example, but not at all unrealistic for
real-world sqlplus. Perl's 'split' won't be quite enough :-).
You also need to add support for:
- amper substitution variables
- bind variables, define statements
- sqlplus exec function
- sqlplus 'set' commands and their effect on interpreting sql code
- included @ files (and finding them, following $ENV{SQLPATH}, etc
- etc, etc, etc..
I suggest you step way back and ask yourself various key questions,
such as:
- who controls the source code that is the input to your module?
- what control do you have over them?
- what do you _really_ need to accomplish here?
(especially in light of the fact that you have a working
shell-script solution, no?)
The gist is that unless you can exert complete control over the
sql source code, you will be taking on a potentially endless hassle
because if the programmers generating the source are writing for
sqlplus, you will have to effectively implement a sqlplus emulator.
What's the point? You will spend a _lot_ of time, and how will the
end result be different (better) from your current solution? I'm not
saying it can't be better, but rather saying that you should have
a very clearly identified and defined objective of what exactly
that added value will be, and ask yourself if it will be worth the
price, and/or if there isn't some simpler way to add that value.
Cheers,
Mark
--- Fernando Luna [EMAIL PROTECTED] wrote:
The only problem I see with the approach of stripping out
semi-colons
before passing DDL statements to Oracle is that CREATE PACKAGE
statements have semi-colons all over the place... in fact, you can't
have a PACKAGE Specification and body without the semi-colons which
terminate each statement in PL/SQL.
Will $dbh-do() cough and gag on that?
One problem you may be facing in your current approach is
the semicolons -- remember they may have to be stripped off
before being
passed to a $dbh-do(), at least some DBDs don't want to see
the semicolons.
--
Jeff
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: DBD::CSV
Peter Schuberth wrote: On the same hardware system the same select for the same table Please check your version of SQL::Statement which is the module that determines the speed and capabilities of DBD::CSV. Put these two lines at the top of the scripts: use SQL::Statement; print $SQL::Statement::VERSION; It sounds to me like you may have the XS version of the module on one install and the pure perl version on the other. You can read about the difference between the two at http://www.vpservices.com/jeff/programs/sql-compare.html If you have a moderately large data set and speed is an issue, then the XS version will be better but MySQl, PostgreSQL, or SQLlite will be even faster. DBD::CSV is really meant for relatively small data sets and relatively uncomplicated querries. Another issue: if you are trying to access the same data file from both windows and linux, you'll need to specifically set the csv_eol for the table. It doesn't really matter which you choose, either \015\012 or \012. If the script sets it to either one of those and the data matches, then the same file can be accessed from both windows and linux without changing the file or the script. That sort of multi-platform accessibility can be achieved with the other DBDs, but probably not as simply. You may be running into some bugs I am working on relatvie to parentheses in WHERE clauses. I'd appreciate it if you could send me any sample queries that don't work for you. -- Jeff
Re: DBD::CSV--Execution ERROR: Couldn't find column names!.
Snethen, Jeff wrote: I've worked with the DBI some, but I'm now starting to experiment with DBD::CSV. I'm trying to read a table without column headers, letting CSV create the column names for me. If I understand the documentation correctly, an empty array reference should cause the driver to name the columns for me. Thanks for pointing out this bug. I have fixed it and will be uploading a corrected version of the module (1.006) shortly. -- Jeff
Re: Running SQL from files - was: Your DBI book
On Mon, 3 Mar 2003 09:42:51 -0800 Fernando Luna [EMAIL PROTECTED] wrote: It would have been nice to know if, say, someone had worked out something to process SQL files since this is such a common task and developers who don't use perl but work with Oracle frequently use SQL files. Bulk creation of tables, and other database objects is probably better left in SQL files; especially since they will probably have to be maintained by people who aren't familiar with Perl. I think dbish and SQL Minus (?) are supposed to be able to handle some of the things you are talking about, but I would consider it unlikely that they would be able to follow all twists and turns that Oracle may allow in SQL*Plus syntax. Having worked with SQL*Plus and Oracle for many years now, I am quite familiar with it's limitations and its nature. I am not so gullible as to presume that other tools understand sqlplus syntax. Just because DBI is an excellent hammer doesn't mean every problem is a nail. Use whichever works better for the particular task. -Original Message- From: M Addlework [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 10:16 AM To: Fernando Luna Cc: [EMAIL PROTECTED] Subject: RE: Running SQL from files - was: Your DBI book I suggest you step way back and ask yourself various key questions, such as: - who controls the source code that is the input to your module? - what control do you have over them? - what do you _really_ need to accomplish here? (especially in light of the fact that you have a working shell-script solution, no?) The gist is that unless you can exert complete control over the sql source code, you will be taking on a potentially endless hassle because if the programmers generating the source are writing for sqlplus, you will have to effectively implement a sqlplus emulator. What's the point? You will spend a _lot_ of time, and how will the end result be different (better) from your current solution? I'm not saying it can't be better, but rather saying that you should have a very clearly identified and defined objective of what exactly that added value will be, and ask yourself if it will be worth the price, and/or if there isn't some simpler way to add that value. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: DBD::CSV
On Mon, Mar 03, 2003 at 10:07:29AM -0800, Jeff Zucker wrote: Peter Schuberth wrote: On the same hardware system the same select for the same table Please check your version of SQL::Statement which is the module that determines the speed and capabilities of DBD::CSV. Put these two lines at the top of the scripts: use SQL::Statement; print $SQL::Statement::VERSION; Or run this command perl -MSQL::Statement= and it'll say something like SQL::Statement required--this is only version X.YY Tim.
DBD::ORACLE (1.12) DBI(1.30) - NESTED TABLE
I am trying to do either :- Retrieve data from an Oracle table with a nested table column or Retrieve data from an Oracle object table based on an object which contains a nested table Either attempt results in :- DBD::Oracle::db selectrow_array failed: ERROR OCIDefineObject call needed but not implemented yet Works when attempting a select against a table with no objects in it. So I am guessing this is not supported. Is there a way around this issue?
Re: Bug in Sybase driver?
Hi Michael,
Attached are 2 files. One is a build script for a Sybase stored procedure
(fill in the database name). The other is a perl script (fill in the
connection information).
The reason I am raising this issue is that I found I had to code for special
conditions during error handling because execute() was returning a -1 in a
specific error condition. I am assuming that undef should be returned in
error conditions.
Thanks.
Glen Sievertson.
From: Michael Peppler [EMAIL PROTECTED]
To: G S [EMAIL PROTECTED]
Subject: Re: Bug in Sybase driver?
Date: 03 Mar 2003 08:02:11 -0800
On Sat, 2003-03-01 at 11:43, G S wrote:
I am tracking down an issue where an error condition is not returned
from a
call to $sth-execute().
Here is my example code with comments. I show the output for 3 tests.
Test
1 and test 2 produce results that I understand. The problem is in test
3.
In test 3 I would expect the returned value (retCode) for the error
condition to be undefined or 0. Instead it is -1. Is this a bug in the
Sybase driver? If so, how do I report such bugs?
Please send me (the author of the module) a script that illustrates the
problem.
You can also enter a bug at http://www.peppler.org/cgi-bin/bug.cgi
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
_
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
use ??
go
create proc error_test
@msg char(30)
as
begin
print @msg
return 0
end
go
grant execute on error_test to
go
#!/usr/bin/perl
use DBI;
$msg = 12345;
$dbh = DBI-connect(DBI:Sybase:server=???;database=???, ???, ???);
# This query is set up to produce a successful result. All values returned
from DBI
#methods are -1.
# To force an error in this query, remove the quotes around $msg. This
produces an datatype
#mismatch error, but a -1 is returned from $sth-execute(). I believe
undef would
#be the correct return value.
# To force a different error, change the stored_procedure name to one that
does not match
#a stored procedure object in your database. This produces an error, and
undef is
#returned from $sth-execute(), which I think is the correct return
value for the error.
# Whichever way is correct, it would be nice if the returned values were
consistent. This
#would allow for the consistent coding of error handlers.
$sql_query = qq[
declare [EMAIL PROTECTED] char(30)
declare [EMAIL PROTECTED] int
exec error_test
[EMAIL PROTECTED]$msg,
[EMAIL PROTECTED]@status output
];
$sth = $dbh-prepare(qq[$sql_query]);
$retCode = $sth-execute();
print \nafter execute retCode is: $retCode \n;
printf(dbh-err= '%s'\n .
dbh-errstr= '%s'\n,
$dbh-err,
$dbh-errstr
);
do
{
while($data = $sth-fetch)
{
if($sth-{syb_result_type} == 4042)
{ # it's a param result
$status = $data-[0];
}
}
}
while($sth-{syb_more_results});
print \nafter fetch\n;
printf(dbh-err= '%s'\n .
dbh-errstr= '%s'\n,
$dbh-err,
$dbh-errstr
);
$retcode = $sth-finish();
print \nafter finish retCode is: $retCode \n;
printf(dbh-err= '%s'\n .
dbh-errstr= '%s'\n,
$dbh-err,
$dbh-errstr
);
$retcode = $dbh-disconnect();
print \nafter disconnect retCode is: $retCode \n;
printf(dbh-err= '%s'\n .
dbh-errstr= '%s'\n,
$dbh-err,
$dbh-errstr
);
Re: DBD::ORACLE (1.12) DBI(1.30) - NESTED TABLE
On Mon, 3 Mar 2003 20:50:09 - Simon Taylor [EMAIL PROTECTED] wrote: I am trying to do either :- Retrieve data from an Oracle table with a nested table column or Retrieve data from an Oracle object table based on an object which contains a nested table Either attempt results in :- DBD::Oracle::db selectrow_array failed: ERROR OCIDefineObject call needed but not implemented yet Works when attempting a select against a table with no objects it it. So I am guessing this is not supported. Is there a way around this issue? As the error says, not implemented yet. Include the individual data elements directly in the SELECT if you can. Another dodge would be to use a package procedure to manage the query and return the row values. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: DBD::ORACLE (1.12) DBI(1.30) - NESTED TABLE
Ok thanks - just wanted to check it wasn't down to how I was using it Michael A Chase [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, 3 Mar 2003 20:50:09 - Simon Taylor [EMAIL PROTECTED] wrote: I am trying to do either :- Retrieve data from an Oracle table with a nested table column or Retrieve data from an Oracle object table based on an object which contains a nested table Either attempt results in :- DBD::Oracle::db selectrow_array failed: ERROR OCIDefineObject call needed but not implemented yet Works when attempting a select against a table with no objects it it. So I am guessing this is not supported. Is there a way around this issue? As the error says, not implemented yet. Include the individual data elements directly in the SELECT if you can. Another dodge would be to use a package procedure to manage the query and return the row values. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
DBD :Oracle - Nested Table
I am trying to insert into a table which has a nested table. I have an array in Perl which I want to load into the nested table. I have a variable number of entries in the array and dont want to have to enumerate them. How can I load my data into a nested table?
DBI on Solaris 8
Please has anybody got a similar problem and a fix I've already installed DBI.1.21 on 2 Sun servers with Solaris 8 ...one was a 32 bit and the other a 64 without any problems well not too many !! But on this server its proving impossible ...I've also tried a different dbi ..1.34 See attached text file perl-dbi Mary perl-dbi Description: perl-dbi
Re: DBD::CSV
On 2003-03-03 13:35:36 +0100, Peter Schuberth wrote: I have changed from MySQL DB to CSV File (DBD::CSV). And also from Linux to Windows Neither seems like a smart move to me. Changing two things at once definitely isn't. A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? or of DBD::CSV? Depending on the size of the tables and the complexity of the query DBD::CSV can be a lot slower that MySQL. B) I have a select like this: ...WHERE ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) values1,values1,values1,values2,values2,values2,values3,values3,values3 with Linux this is not a problem, but under Windows I get no data and also no error. I removed the field3 only then I got data with Windows, but the result looks like WHERE ((field1 like ?) OR (field2 like ?)) has been used for the search. Have you tried the same query with DBD::CSV on Linux? Or with DBD::MySQL on Windows? C) There is a different in the order of a table when I use it under Linux or Windows. Under Windows the order is fine but under Linux it looks mixed up. If you want the result of a select to be ordered you have to use an ORDERED BY clause. Tables have NO defined order in SQL. hp -- _ | Peter J. Holzer | Unser Universum wäre betrüblich |_|_) | Sysadmin WSR / LUGA | unbedeutend, hätte es nicht jeder | | | [EMAIL PROTECTED]| Generation neue Probleme bereit. __/ | http://www.hjp.at/ | -- Seneca, naturales quaestiones pgp0.pgp Description: PGP signature
Re: DBD::CSV
Hello, thanks for your answers. I would also like to stick to MySQL, but I have to change it, since there is no DB-Server available. Dan, yes the data of the tables are *exactly* the same!!! The querry I use for C) is like: where (field1=?) and (field2=?) order by field3 again the same data and the same query! For showing the data I just use a while loop and display record by record. Again using the same script here and there. Regards - Original Message - From: Dan Muey [EMAIL PROTECTED] To: Peter Schuberth [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 03, 2003 3:35 PM Subject: RE: DBD::CSV Hello, I have changed from MySQL DB to CSV File (DBD::CSV). And also from Linux to Windows There's the first two mistakes! :) A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? THE OS !! WINDOWS is an expensive resource cow, designed to stop working every 2.5 years And make you think you can't live with out it. B) I have a select like this: ...WHERE ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) AND ((field1 like ?) OR (field2 like ?) OR (field3 like ?)) values1,values1,values1,values2,values2,values2,values3,values 3,values3 with Linux this is not a problem, but under Windows I get no data and also no error. I removed the field3 only then I got data with Windows, but the result looks like WHERE ((field1 like ?) OR (field2 like ?)) has been used for the search. On this one are the tables *exactly* the same? C) There is a different in the order of a table when I use it under Linux or Windows. Under Windows the order is fine but under Linux it looks mixed up. That depends again on if the tables are *exactly* the same and *exactly* what query you use and *exactly* how the software is installed on the OS, and how you assemble the results. Windows and unix behave differently. If you can hack it I'd highly recommend sticking to a flavor of unix. Too many variables to figure out why they are coming back different. Thanks for any help in advance! Peter
Re: DBD::CSV
Hello Jenda, I have used the same data under Linux and Windows, also the same scripts. The times I gave in A) are only for the select of the CSV table not for the script. But comparing the select query with the execution of the rest of the script, select is taking most of the time. Under Windows (Script total 2.5 sec. Search 2.0 sec). I have also changed now to Apache 2.00.44, then the query is 0.15 seconds faster under Win. Peter - Original Message - From: Jenda Krynicky [EMAIL PROTECTED] To: Peter Schuberth [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 03, 2003 4:22 PM Subject: RE: DBD::CSV From: Dan Muey [EMAIL PROTECTED] A) But now I discovered few problems: On the same hardware system the same select for the same table 1) Linux the select takes 0.4 seconds 2) Windows the select takes 2.1 seconds Using Apache 1.3.27 and under Windows ActivePerl. Is it a problem of Apache, Perl or the OS? THE OS !! WINDOWS is an expensive resource cow, designed to stop working every 2.5 years And make you think you can't live with out it. Please stop flaming based on your personal tastes. It is true that Windows use more resources than Linux in the default setup, but the difference Dan sees has nothing to do with this. It's caused by the DBD::CSV. If he installed Mysql and kept using DBD::mysql he'd see roughly the same results. Dan, you may want to take a look at DBD::SQLite if you do not want to install mysql. Jenda P.S.: Dan, could you try to run the script using DBD::CSV, using the same data, under Linux and let us know how long did it take? = [EMAIL PROTECTED] === http://Jenda.Krynicky.cz = When it comes to wine, women and song, wizards are allowed to get drunk and croon as much as they like. -- Terry Pratchett in Sourcery
DBD::ORACLE (1.12) DBI(1.30) - NESTED TABLE
I am trying to do either :- Retrieve data from an Oracle table with a nested table column or Retrieve data from an Oracle object table based on an object which contains a nested table Either attempt results in :- DBD::Oracle::db selectrow_array failed: ERROR OCIDefineObject call needed but not implemented yet Works when attempting a select against a table with no objects in it. So I am guessing this is not supported. Is there a way around this issue?
DBD::ORACLE (1.12) DBI(1.30) - NESTED TABLE
I am trying to do either :- Retrieve data from an Oracle table with a nested table column or Retrieve data from an Oracle object table based on an object which contains a nested table Either attempt results in :- DBD::Oracle::db selectrow_array failed: ERROR OCIDefineObject call needed but not implemented yet Works when attempting a select against a table with no objects in it. So I am guessing this is not supported. Is there a way around this issue?
DBI 1.34 error?
I have this script:
use strict;
use warnings;
use DBI;
my %attr = (
PrintError = 0,
RaiseError = 1
);
my @drivers = DBI-available_drivers();
foreach my $driver(@drivers) {
print Driver: $driver\n;
my @dataSources = DBI-data_sources($driver);
foreach my $dataSource(@dataSources) {
print \t$dataSource\n;
}
print \n;
}
It simply gives me a list of DBD drivers installed. Ran fine until I upgrade
to 1.34 at which point I get the following error now:
install_driver(Proxy) failed: Global symbol $this requires explicit
package name at C:/Perl/site/lib/DBD/Proxy.pm line 272.
BEGIN not safe after errors--compilation aborted at
C:/Perl/site/lib/DBD/Proxy.pm line 414.
Compilation failed in require at (eval 3) line 3.
Nothing ground breaking...just thought you should know.
Bob
Re: DBI 1.34 error?
On Mon, Mar 03, 2003 at 04:25:13PM -0500, Bob X wrote:
I have this script:
use strict;
use warnings;
use DBI;
my %attr = (
PrintError = 0,
RaiseError = 1
);
my @drivers = DBI-available_drivers();
foreach my $driver(@drivers) {
print Driver: $driver\n;
my @dataSources = DBI-data_sources($driver);
foreach my $dataSource(@dataSources) {
print \t$dataSource\n;
}
print \n;
}
It simply gives me a list of DBD drivers installed. Ran fine until I upgrade
to 1.34 at which point I get the following error now:
install_driver(Proxy) failed: Global symbol $this requires explicit
package name at C:/Perl/site/lib/DBD/Proxy.pm line 272.
BEGIN not safe after errors--compilation aborted at
C:/Perl/site/lib/DBD/Proxy.pm line 414.
Compilation failed in require at (eval 3) line 3.
Nothing ground breaking...just thought you should know.
Thanks. I believe the appended patch fixes it.
Tim.
*** lib/DBD/Proxy.pm2003/02/28 17:50:06 11.12
--- lib/DBD/Proxy.pm2003/03/03 22:37:14
***
*** 269,275
# to let people trade safety for speed if they need to.
undef $dbh-{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh-{'proxy_client'};
! $this-SUPER::STORE('Active' = 0);
1;
}
--- 269,275
# to let people trade safety for speed if they need to.
undef $dbh-{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh-{'proxy_client'};
! $dbh-SUPER::STORE('Active' = 0);
1;
}
RE: Using perl 5.8.0?
From: Tim Bunce [mailto:[EMAIL PROTECTED] Anyone using perl 5.8.0? After a lot of upgrades (seg fault, DBI connect hangs), we seem to have one old RedHat server happy w/ 5.8.0. Linux version 2.4.7-10 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.9 6-98)) #1 Thu Sep 6 17:27:27 EDT 2001 This is perl, v5.8.0 built for i686-linux DBI-1.34 DBD-Informix-1.04.PC1 csdk280_uc21lin_ux DBD-Sybase-0.95 freetds-0.61 Cheers, j
connect_cached question
connect_cached creates a _new_ connection on the second call
in this sample (only difference being PrintError attribute)
DBI-connect($data_source, $user, $auth, {PrintError=1});
DBI-connect($data_source, $user, $auth, {PrintError=0});
I would submit that this is wrong behavior, and that the
PrintError behavior is not an integral part of the user's
conception of a database connection, but rather is a _state_
of a given connection. Accordingly, the second call should
return the same db handle, but change the PrintError state
before doing so.
Comments? Am I right? Or do people explicitly depend
on getting new connections unpon changing a DBI-specific
atribbute?
Thanks,
Mark
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: DBI 1.34 error?
Tim Bunce wrote:
On Mon, Mar 03, 2003 at 04:25:13PM -0500, Bob X wrote:
I have this script:
[...]
It simply gives me a list of DBD drivers installed. Ran fine until I upgrade
to 1.34 at which point I get the following error now:
install_driver(Proxy) failed: Global symbol $this requires explicit
package name at C:/Perl/site/lib/DBD/Proxy.pm line 272.
BEGIN not safe after errors--compilation aborted at
C:/Perl/site/lib/DBD/Proxy.pm line 414.
Compilation failed in require at (eval 3) line 3.
Nothing ground breaking...just thought you should know.
Thanks. I believe the appended patch fixes it.
Tim.
*** lib/DBD/Proxy.pm2003/02/28 17:50:06 11.12
--- lib/DBD/Proxy.pm2003/03/03 22:37:14
***
*** 269,275
# to let people trade safety for speed if they need to.
undef $dbh-{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh-{'proxy_client'};
! $this-SUPER::STORE('Active' = 0);
1;
}
--- 269,275
# to let people trade safety for speed if they need to.
undef $dbh-{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh-{'proxy_client'};
! $dbh-SUPER::STORE('Active' = 0);
1;
}
Silly question time, Tim; does the fact that we don't support Perl
5.004 allow you to change line 270 now?
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
#include disclaimer.h
Guardian of DBD::Informix 1.04.PC1 -- http://dbi.perl.org/
ANNOUNCE: IBM Informix Database Driver for Perl Version 2003.03.0303 (2003-03-03) released
IBM Informix Database Driver for Perl Version 2003.03.0303 (2003-03-03) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.005 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.8.0, you should be planning to upgrade to it). You will need the code for DBI version 1.33 or later as well. The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at [EMAIL PROTECTED] Note that ItWorks does not ** send email to anybody; you have to do that yourself. New in release 2003.03.0303: * Pre-requisite version of DBI is now 1.33. There were a number of changes made in the support code for DBI that this version of DBD::Informix relies upon. * Fix various minor problems as noted in the ChangeLog. * Overhaul the infrastructure to align better with DBI specifications. * Revise infrastructure to exploit ExtUtils::AutoInstall. If it causes you problems (because you don't have Internet access, for example), read the notes at the top of Makefile.PL on how to avoid the problems. * Provide support for $dbh-get_info() and $dbh-type_info_all(). * No longer supporting obsolete versions of ESQL/C: 5.0x, 6.0x, 7.0x, 7.1x, 7.2x other than 7.24, 9.0x, and 9.1x prior to 9.16. All of these are at least 5 years out of date. See also FUTURE DIRECTION in ChangeLog. * This release is supported by Jonathan Leffler [EMAIL PROTECTED]. * Moving to version numbering scheme with 3-part major, minor, release numbering as recommended in: http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html Just to be contrarian, the version number will be date-based. New in release 1.04.PC1: * This release is supported by Jonathan Leffler. It isn't clear what IBM's official stance on the product is. However, they do support DBD::DB2 so there is likely to be minimal objection to this work. * This release provides support for INSERT cursors. * This release provides support for UPDATE of blobs (BYTE and TEXT). * This release provides semi-tested support for BEGIN WORK WITHOUT REPLICATION. * This release works with ClientSDK 2.80; the prior versions of DBD::Informix do not because the version string changed radically. * Has better support for non-standard Perl installations. * You can tell DBD::Informix to avoid testing smart blobs if you have IDS 9.x but no smart blob spaces. You can also say which smart blob space to use if you don't want to use 'sbspace'. * Fix up file locations so it works better with CPAN. Scheduled next version: 2003.02.00. * Feature content still dependent on time available. * Expected to contain sqlda version of the code (WIP - Work In Progress WIP - at last). As always, see the ChangeLog file for details about what has changed. Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) @(#)$Id: Announce,v 2003.3 2003/02/28 21:31:22 jleffler Exp $ -- Jonathan Leffler #include disclaimer.h STSM, Informix Database Engineering, IBM Data Management Phone: +1 650-926-6921 Fax: +1 650-926-6971 Tie-line: 630-6921 Email: [EMAIL PROTECTED] Guardian of DBD::Informix v1.04.PC1 -- http://dbi.perl.org
Anyone have DBI code that depends on $sth-{NAME} containing tablename.fieldname?
I've discovered that DBD::mysql will return tablefoo.fieldbar as
the NAME of the field in a select like:
SELECT tablefoo.fieldbar FROM tablefoo
It does that simply because that's what the underlying mysql client
API tell it is the name of the field.
I believe this is very rare (I know of no others drivers that do that)
and I'm considering changing the DBI specification to clarify that NAME
should only contain the fieldname.
I appreciate that there's a loss of information here and that
statements like this:
SELECT table1.field, table2.field FROM table1, table2 WHERE ...
will return the same NAME value for both fields.
However, I'm currently of the opinion that removing the table name
to make NAME be consistent with the behaviour of other drivers is
of greater benefit than retaining the table name.
I'd welcome any examples of code that *relies* in the table name
being present in the NAME attribute and can't easily be changed.
Note that in the specific case of DBD::mysql, the table name of
each field is also availble in the $sth-{mysql_table} attribute,
so any application that needs the table name for each field can
still get it.
Tim.
Re: Anyone have DBI code that depends on $sth-{NAME} containing tablename.fieldname?
At 0:18 + 3/4/03, Tim Bunce wrote:
I've discovered that DBD::mysql will return tablefoo.fieldbar as
the NAME of the field in a select like:
SELECT tablefoo.fieldbar FROM tablefoo
That's not what I observe. Is this a recent change in the MySQL C client
library? The library has not returned a table name before, because
the table name is in a separate member of the MYSQL_FIELD structure.
It does that simply because that's what the underlying mysql client
API tell it is the name of the field.
I believe this is very rare (I know of no others drivers that do that)
and I'm considering changing the DBI specification to clarify that NAME
should only contain the fieldname.
I appreciate that there's a loss of information here and that
statements like this:
SELECT table1.field, table2.field FROM table1, table2 WHERE ...
will return the same NAME value for both fields.
However, I'm currently of the opinion that removing the table name
to make NAME be consistent with the behaviour of other drivers is
of greater benefit than retaining the table name.
I'd welcome any examples of code that *relies* in the table name
being present in the NAME attribute and can't easily be changed.
Note that in the specific case of DBD::mysql, the table name of
each field is also availble in the $sth-{mysql_table} attribute,
so any application that needs the table name for each field can
still get it.
Tim.
