RE: MS SQL Server Connectivity
The Archives are your freind: http://www.xray.mpe.mpg.de/mailing-lists/dbi/ Ask your question here and you will get tons of information ie "msql server from linux" hint : perldoc DBI::ProxyServer perldoc DBD::Proxy Neil > -Original Message- > From: Joel Divekar [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 30, 2001 2:57 PM > To: Steve Howard; [EMAIL PROTECTED] > Subject: RE: MS SQL Server Connectivity > > > Hi > > At 09:19 AM 4/28/2001 -0500, Steve Howard wrote: > >What OS are you using? > > My Perl script runs from Linux, it first reads and parses > mails received on > POP3 server thn it dumps the relevant info in MySql tables > under Linux, now > we want to dump this data again in MS SQL Server running on > Windows 2000. > > > If it is an MS Operating System, then all you really > >need is DBI and DBD::ODBC. You'll have to get your DSN > configured, and make > >your connection right. If you need more details, I can probably help > > > >If you are using a different OS, someone else will probably > have to help. > > > > Thanks Steve > > >Steve Howard > > > >-Original Message- > >From: Joel Divekar [mailto:[EMAIL PROTECTED]] > >Sent: Saturday, April 28, 2001 4:28 AM > >To: [EMAIL PROTECTED] > >Subject: MS SQL Server Connectivity > > > > > >Hi All > > > >How to make Perl to talk to MS SQL Server ? > > > >Regards > > > >Joel > > > Regards > > Joel > > > -- > QuantumLink Communications, Bombay, India > > __ Please Note : Only the intended recipient is authorised to access or use this e-mail. If you are not the intended recipient, please delete this e-mail and notify the sender immediately. The contents of this e-mail are the writer's opinion and are not necessarily endorsed by the Gunz Companies unless expressly stated. We use virus scanning software but exclude all liability for viruses or similar in any attachment.
RE: MS SQL Server Connectivity
Hi At 09:19 AM 4/28/2001 -0500, Steve Howard wrote: >What OS are you using? My Perl script runs from Linux, it first reads and parses mails received on POP3 server thn it dumps the relevant info in MySql tables under Linux, now we want to dump this data again in MS SQL Server running on Windows 2000. > If it is an MS Operating System, then all you really >need is DBI and DBD::ODBC. You'll have to get your DSN configured, and make >your connection right. If you need more details, I can probably help > >If you are using a different OS, someone else will probably have to help. > Thanks Steve >Steve Howard > >-Original Message- >From: Joel Divekar [mailto:[EMAIL PROTECTED]] >Sent: Saturday, April 28, 2001 4:28 AM >To: [EMAIL PROTECTED] >Subject: MS SQL Server Connectivity > > >Hi All > >How to make Perl to talk to MS SQL Server ? > >Regards > >Joel Regards Joel -- QuantumLink Communications, Bombay, India
RE: Problem installing DBI 1.15 on AIX 4.3 (Perl 5.0005_03)
Where did this go? Any resolution? There is Something about the Dynaloader
for 5.00503 from memory. I'd suggest rebuilding for 5.6.1.
Neil
> -Original Message-
> From: Paul Scott [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 26, 2001 11:03 PM
> To: [EMAIL PROTECTED]
> Subject: Problem installing DBI 1.15 on AIX 4.3 (Perl 5.0005_03)
>
>
> Hi all,
>
> I am having great difficulty in getting DBI installed on an
> AIX 4.3 box.
> Basically the Makefile.PL works great, Makefile works fine,
> but make test
> returns a load of "No such file or directory errors." from
> DynaLoader.PM.
>
> Details below - errors in the make test section
>
> Can anyone help me out with this?
>
> Many Thanks
>
> Paul
>
> /home/scottp/perl/DBI-1.15 465$ perl -v
>
> This is perl, version 5.005_03 built for aix
>
> Copyright 1987-1999, Larry Wall
>
> Perl may be copied only under the terms of either the
> Artistic License or
> the
> GNU General Public License, which may be found in the Perl
> 5.0 source kit.
>
> Complete documentation for Perl, including FAQ lists, should
> be found on
> this system using `man perl' or `perldoc perl'. If you have
> access to the
> Internet, point your browser at http://www.perl.com/, the
> Perl Home Page.
>
> /home/scottp/perl/DBI-1.15 466$
>
>
>
>
> /home/scottp/perl/DBI-1.15 458$ perl Makefile.PL
> *** Note:
> The optional PlRPC-modules (RPC::PlServer etc) are not installed.
> If you want to use the DBD::Proxy driver and DBI::ProxyServer
> modules, then you'll need to install the RPC::PlServer,
> RPC::PlClient,
> Storable and Net::Daemon modules. The CPAN Bundle::DBI
> may help you.
> You can install them any time after installing the DBI.
> You do *not* need these modules for typical DBI usage.
>
> Optional modules are available from any CPAN mirror, in particular
> http://www.perl.com/CPAN/modules/by-module
> http://www.perl.org/CPAN/modules/by-module
> ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module
>
> Checking if your kit is complete...
> Looks good
> Writing Makefile for DBI
>
> Remember to actually *read* the README file!
> Use 'make' to build the software (dmake or nmake on Windows).
> Then 'make test' to execute self tests.
> Then 'make install' to install the DBI and then delete
> this working
> directory before unpacking and building any DBD::* drivers.
>
> /home/scottp/perl/DBI-1.15 459$
>
>
>
> /home/scottp/perl/DBI-1.15 461$ make
> mkdir blib
> mkdir blib/lib
> cp lib/DBI/W32ODBC.pm blib/lib/DBI/W32ODBC.pm
> cp lib/DBD/ExampleP.pm blib/lib/DBD/ExampleP.pm
> cp lib/DBI/Shell.pm blib/lib/DBI/Shell.pm
> cp lib/DBI/FAQ.pm blib/lib/DBI/FAQ.pm
> cp lib/DBI/ProxyServer.pm blib/lib/DBI/ProxyServer.pm
> cp lib/Bundle/DBI.pm blib/lib/Bundle/DBI.pm
> cp lib/DBD/Proxy.pm blib/lib/DBD/Proxy.pm
> cp lib/DBD/Multiplex.pm blib/lib/DBD/Multiplex.pm
> cp DBIXS.h blib/arch/auto/DBI/DBIXS.h
> cp dbd_xsh.h blib/arch/auto/DBI/dbd_xsh.h
> cp dbi_sql.h blib/arch/auto/DBI/dbi_sql.h
> cp lib/DBD/NullP.pm blib/lib/DBD/NullP.pm
> cp lib/DBD/Sponge.pm blib/lib/DBD/Sponge.pm
> cp lib/DBI/Format.pm blib/lib/DBI/Format.pm
> cp Driver.xst blib/arch/auto/DBI/Driver.xst
> cp lib/DBI/DBD.pm blib/lib/DBI/DBD.pm
> cp lib/Win32/DBIODBC.pm blib/lib/Win32/DBIODBC.pm
> cp DBI.pm blib/lib/DBI.pm
> cp dbipport.h blib/arch/auto/DBI/dbipport.h
> cp lib/DBD/ADO.pm blib/lib/DBD/ADO.pm
> /usr/bin/perl "-I/usr/opt/perl5/lib/5.00503/aix"
> "-I/usr/opt/perl5/lib/5.00503" -e 'use ExtUtils::Mksymlists;
> Mksymlists("NAME" => "DBI", "DL_FUNCS" => { }, "FUNCLIST" =>
> [], "DL_VARS"
> => []);'
> /usr/bin/perl -p -e "s/~DRIVER~/Perl/g" <
> blib/arch/auto/DBI/Driver.xst > Perl.xsi
> /usr/bin/perl -I/usr/opt/perl5/lib/5.00503/aix
> -I/usr/opt/perl5/lib/5.00503
> /usr/opt/perl5/lib/5.00503/ExtUtils/xsubpp
> -typemap /usr/opt/perl5/lib/5.00503/ExtUtils/typemap Perl.xs
> >xstmp.c && mv
> xstmp.c Perl.c
> gcc -c -D_ALL_SOURCE -D_ANSI_C_SOURCE
> -D_POSIX_SOURCE -O
> -DVERSION=\"1.15\" -DXS_VERSION=\"1.15\"
> -I/usr/opt/perl5/lib/5.00503/aix/CORE -DDBI_NO_THREADS Perl.c
> /usr/bin/perl -I/usr/opt/perl5/lib/5.00503/aix
> -I/usr/opt/perl5/lib/5.00503
> /usr/opt/perl5/lib/5.00503/ExtUtils/xsubpp
> -typemap /usr/opt/perl5/lib/5.00503/ExtUtils/typemap DBI.xs
> >xstmp.c && mv
> xstmp.c DBI.c
> gcc -c -D_ALL_SOURCE -D_ANSI_C_SOURCE
> -D_POSIX_SOURCE -O
> -DVERSION=\"1.15\" -DXS_VERSION=\"1.15\"
> -I/usr/opt/perl5/lib/5.00503/aix/CORE -DDBI_NO_THREADS DBI.c
> Running Mkbootstrap for DBI ()
> chmod 644 DBI.bs
> LD_RUN_PATH="" ld -o blib/arch/auto/DBI/DBI.so
> -bhalt:4 -bM:SRE
> -bI:/usr/opt/perl5/lib/5.00503/aix/CORE/perl.exp -bE:DBI.exp
> -b noentry -lc
> DBI.o
> chmod 755 blib/arch/auto/DBI/DBI.so
> cp DBI.bs blib/arch/auto/DBI/DBI.bs
> chmod 644 blib/arch/auto/DBI/DBI.bs
> mkdir blib/lib/auto/DBI
>
RE: DBD::ODBC doesn't work!!!
> Big Brother tells me that Bodo Eing wrote:
> > Jack,
> >
> > > Help! I cannot get DBD::ODBC to work. I am
> connecting to the
> > > MSSQL 2000 database with:
> > >
> > > $db = DBI->connect("dbi:odbc:MSSQLTEST");
> > >
> >
> > In the first place, try connecting with the correct
> capitalization of
> > the driver and add error checking:
> >
> > $db = DBI->connect("DBI:ODBC:MSSQLTEST") or die DBI::errstr();
DBI->connect("dbi:ODBC:MSQLTEST") or die DBI::errstr(); # or whatever
Nonetheless I am immediately suspect about this. What is the full
information on the DSN? More importantly have you verified this connection
with any external tools as well as providing a DSNless connect string to the
DBI?
Note that your error is from unixODBC so it is what is having problems with
"MSQLTEST". Not DBI.
Neil
__
Please Note :
Only the intended recipient is authorised to access or use this e-mail. If
you are not the intended recipient,
please delete this e-mail and notify the sender immediately. The contents
of this e-mail are the writer's
opinion and are not necessarily endorsed by the Gunz Companies unless
expressly stated.
We use virus scanning software but exclude all liability for viruses or
similar in any attachment.
Works (NOT)
I have DBD::ODBC installed using Openlink with iodbc. Whe I run a script from the
shell it works as is expected. Same script yet run via a web page and it returns the
following error.
Couldn't connect to database[OpenLink][ODBC]RPC: Unknown host (SQL-08004)
[OpenLink][ODBC]Connection rejected by data source (SQL-08004)(DBD:
db_login/SQLConnect err=-1) at /home/httpd/cgi-bin/hafa.pl line 18.
What could I be doing wrong ?
##Þ
print "\n Welcome to NEPP";$Þ=1;while ($Þ){
print "\n$Þ";$Þ++;if ($Þ == 1000) {
print "\n$Þ"."\nWell almost never ending :þ";exit;}}
##Þ
Re: Still experiencing problems with DBD-Oracle/DBI and Intel Solaris
What version of Oracle are you using on Solaris 8? The only versions of Oracle that are certified for Solaris 8 are 8.1.7, 8.1.6, 8.1.6(64 bit) and 8.0.6. Jared On Sunday 29 April 2001 08:47, Tuanjai Sampannon wrote: > Hello (again), > > I am still experiencing the same problems I posted a week ago. > > I have: > - Perl 5.6.1 > - Tk800.022 > - DBI-1.15 > - DBD-Oracle-1.06 > - Intel Solaris 8 > - Multi-processor machine > > Someone suggested downgrading DBI to 1.14 might help, but no such luck. > Someone suggested downgrading Perl to 5.6.0 might help, but also no such > luck. > > I still get core dumps for the first to tests... > > I compile everything with the same compiler, and I can connect to my > databases with e.g. SQL*Plus, and I have LD_LIBRARY_PATH set to > $ORACLE_HOME/lib... > > Could this be because my system is multi-processor??? > > I am getting a bit desperate... > > Please help!!! > > With kind regards, > > Roland Slegers > > [EMAIL PROTECTED] > > Copy of make test log: > > == > make test TEST_VERBOSE=1 > == > PERL_DL_NONLAZY=1 > /usr/bin/perl -Iblib/arch -Iblib/lib > -I/usr/local/lib/perl5/5.6.1/i86pc-sola ris -I/usr/local/lib/perl5/5.6.1 -e > 'use Test::Harness qw(&runtests $verbose); $verbose=1; runtests @ARGV;' > t/*.t > t/base..dubious > Test returned status 0 (wstat 139, 0x8b) > test program seems to have generated a core > t/general...1..16 > ok 1 > ok 2 > dubious > Test returned status 0 (wstat 139, 0x8b) > test program seems to have generated a core > DIED. FAILED tests 3-16 > Failed 14/16 tests, 12.50% okay > t/long..create table dbd_ora__drop_me ( idx integer, lng LONG, > dt date ) > 1..140 > long_data0 length 10240 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng LONG, dt date ) > --- insert some LONG data > ok 1 > ok 2 > ok 3 > ok 4 > --- fetch LONG data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 5 > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > --- fetch LONG data back again -- truncated - LongTruncOk == 0 > LongReadLen 81910, LongTruncOk > ok 11 > ok 12 > ok 13 > ok 14 > ok 15 > ok 16 > --- fetch LONG data back again -- complete - LongTruncOk == 0 > LongReadLen 82920, LongTruncOk > ok 17 > ok 18 > ok 19 > ok 20 > ok 21 > ok 22 > ok 23 > ok 24 > --- fetch LONG data back again -- via blob_read > Skipped blob_read tests for LONGs with OCI8 - not currently supported. > ok 25 > ok 26 > ok 27 > ok 28 > ok 29 > ok 30 > ok 31 > ok 32 > ok 33 > ok 34 > ok 35 > long_data0 length 20480 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng LONG RAW, dt date ) > --- insert some LONG RAW data > ok 36 > ok 37 > ok 38 > ok 39 > --- fetch LONG RAW data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 40 > ok 41 > ok 42 > ok 43 > ok 44 > ok 45 > --- fetch LONG RAW data back again -- truncated - LongTruncOk == 0 > LongReadLen 40955, LongTruncOk > ok 46 > ok 47 > ok 48 > ok 49 > ok 50 > ok 51 > --- fetch LONG RAW data back again -- complete - LongTruncOk == 0 > LongReadLen 82920, LongTruncOk > ok 52 > ok 53 > ok 54 > ok 55 > ok 56 > ok 57 > ok 58 > ok 59 > --- fetch LONG RAW data back again -- via blob_read > Skipped blob_read tests for LONGs with OCI8 - not currently supported. > ok 60 > ok 61 > ok 62 > ok 63 > ok 64 > ok 65 > ok 66 > ok 67 > ok 68 > ok 69 > ok 70 > long_data0 length 10240 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng CLOB, dt date ) > --- insert some CLOB data > ok 71 > ok 72 > ok 73 > ok 74 > --- fetch CLOB data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 75 > ok 76 > ok 77 > ok 78 > ok 79 > ok 80 > --- fetch CLOB data back again -- truncated - LongTruncOk == 0 > LongReadLen 81910, LongTruncOk > ok 81 > ok 82 > ok 83 > ok 84 > ok 85 > ok 86 > --- fetch CLOB data back again -- complete - LongTruncOk == 0 > LongReadLen 82920, LongTruncOk > ok 87 > ok 88 > ok 89 > ok 90 > ok 91 > ok 92 > ok 93 > ok 94 > --- fetch CLOB data back again -- via blob_read > ok 95 > ok 96 > ok 97 > ok 98 > ok 99 > ok 100 > ok 101 > ok 102 > ok 103 > ok 104 > ok 105 > long_data0 length 10240 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng BLOB, dt date ) > --- insert some BLOB data > ok 106 > ok 107 > ok 108 > ok 109 > --- fetch BLOB data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 110 > ok 111 > ok 112 > ok 113 > ok 114 > ok 115 > --- fetch BLOB data back again -- truncated - LongTruncOk == 0 > LongReadLen 81910, LongTruncOk > ok 116 > ok 117 > ok 118 > ok 119 > ok 120 > ok 121 > --- fetch BLOB data back again -- complete - LongTruncOk == 0 > LongReadLen 82920
Re: Can DBD::Oracle connect to various versions of Oracle?
Hmm. I wonder why our Oracle developer has several different Makefiles to build stuff based on the Oracle version? He does tend to be overly cautious and makes a lot of assumptions, so I guess that's the case here. Thanks again! On Sun, Apr 29, 2001 at 10:50:57AM +0200, Mark Vandenbroeck <[EMAIL PROTECTED]> wrote: > David, > > By the way : the same answers is good for Pro*C : with one particular Pro*C program, >you can connect > to any Oracle version. No need to recompile. > > Brgds, > > Mark > > > David Good wrote: > > > Thanks! That's just the info I was looking for. I want to replace all of > > the old Pro*C stuff with DBI and I'm glad I won't have to have a different > > version of DBD::Oracle for every different version of Oracle. > > > > On Sat, Apr 28, 2001 at 05:37:39PM +0200, Mark Vandenbroeck ><[EMAIL PROTECTED]> wrote: > > > David, > > > > > > Sure, no problem. I have Oracle 8.1.7, Perl and DBI, DBD::Oracle on my Linux > > > laptop and connect without problem to a plethora of Oracle versions, ranging from > > > 7.1.6 to 9i beta. > > > > > > The only limitation is that you have to use SQL*Net v2 on older versions of > > > Oracle. Up to 7.3.4, SQL*Net v1 was still supported. Starting from 7.3.4, you > > > can't use v1 anymore. So, if you want to connect to pre-7.3.4 versions, make sure > > > you have the SQL*Net v2 listener configured and running. > > > > > > Hope this helps, > > > > > > Mark > > > > > > > > > David Good wrote: > > > > > > > I've been wondering. We support a number of clients running various > > > > versions of Oracle and I'd like to have just one copy of DBD::Oracle that > > > > would be able to connect to them all. We currently have some custom Pro*C > > > > apps and to hear the developers talk about it, they have to be compiled > > > > alot differently for each version of Oracle they want it to run against. > > > > > > > > Is it possible to have one copy of DBD::Oracle that'll work with Oracle 7, 8 > > > > and maybe even 9? > > > > > > > > -- > > > > David Good [EMAIL PROTECTED] > > > > > > > > This space intentionally left blank. > > > > > > -- > > > Mark Vandenbroeck Mobile : +32-495-59.55.62 > > > Business Process Manager Email : [EMAIL PROTECTED] > > > EMEA Support Information Systems AIM: markvdb > > > > > > > > > > -- > > David Good [EMAIL PROTECTED] > > > > This space intentionally left blank. > > -- > Mark Vandenbroeck Mobile : +32-495-59.55.62 > Business Process Manager Email : [EMAIL PROTECTED] > EMEA Support Information Systems AIM: markvdb > > -- David Good [EMAIL PROTECTED] This space intentionally left blank.
Re: bind_param and dates
Correction, those dates I was sending are OK I mistakenly sent the reference to them instead of the value. However, the value "NULL" still doesn't work. In one case, I'm getting the value straight from an SQL query... so it's actually undef... then I quote() it which is supposed to properly convert it to a SQL NULL... yet I still get the conversion error. --Curt
bind_param and dates
I'm getting conversion errors (VARCHAR to [SMALL]DATETIME) on an
insert. I have a structure that contains a list of params that need to be
inserted into a db table. Prior to insertion, I make sure that undef
values are treated as SQL NULLs:
for (my $i = 0; $i <= $#array; $i++)
{
if ((!DBI::looks_like_number($array[$i]) && (!$array[$i]))
{
$array[$i] = $dbh->quote($array[$i];
}
}
Then I go through and use bind_param on all the array members, specifying
each params SQL data type:
$sth->bind_param(1, \$array[0], SQL_DATE);
I have 4 date values that are inserted into the db... the corresponding db
types are SMALLDATETIME, DATETIME, DATETIME, DATETIME. The values I'm
inserting are (NULL, NULL, 20010429 14:01:35, 20010429 14:10:22). I can
see where NULL may get misinterpreted, but why would the last two values
be misinterpreted as VARCHAR... in fact, it was my understanding that
specifying SQL_DATE would automatically format these values properly.
Prior to doing this, I used a stored proc to insert values like
NULL... the sp was able to tell that NULL meant SQL_NULL and not
"NULL". However, Sybase won't let me bind values to a stored proc call
(those significantly slowing the application since I have to prepare each
time in the loop) and the version of Perl I am using will not let me pass
undef to an SQL statement w/o causing a SEGV signal and a core dump. I
cannot change the Perl setup I have so I have to code around them.
Thanks,
Curt Crandall
Still experiencing problems with DBD-Oracle/DBI and Intel Solaris
Hello (again), I am still experiencing the same problems I posted a week ago. I have: - Perl 5.6.1 - Tk800.022 - DBI-1.15 - DBD-Oracle-1.06 - Intel Solaris 8 - Multi-processor machine Someone suggested downgrading DBI to 1.14 might help, but no such luck. Someone suggested downgrading Perl to 5.6.0 might help, but also no such luck. I still get core dumps for the first to tests... I compile everything with the same compiler, and I can connect to my databases with e.g. SQL*Plus, and I have LD_LIBRARY_PATH set to $ORACLE_HOME/lib... Could this be because my system is multi-processor??? I am getting a bit desperate... Please help!!! With kind regards, Roland Slegers [EMAIL PROTECTED] Copy of make test log: == make test TEST_VERBOSE=1 == PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.1/i86pc-sola ris -I/usr/local/lib/perl5/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=1; runtests @ARGV;' t/*.t t/base..dubious Test returned status 0 (wstat 139, 0x8b) test program seems to have generated a core t/general...1..16 ok 1 ok 2 dubious Test returned status 0 (wstat 139, 0x8b) test program seems to have generated a core DIED. FAILED tests 3-16 Failed 14/16 tests, 12.50% okay t/long..create table dbd_ora__drop_me ( idx integer, lng LONG, dt date ) 1..140 long_data0 length 10240 long_data1 length 81920 long_data2 length 71680 create table dbd_ora__drop_me ( idx integer, lng LONG, dt date ) --- insert some LONG data ok 1 ok 2 ok 3 ok 4 --- fetch LONG data back again -- truncated - LongTruncOk == 1 LongReadLen 20, LongTruncOk 1 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 --- fetch LONG data back again -- truncated - LongTruncOk == 0 LongReadLen 81910, LongTruncOk ok 11 ok 12 ok 13 ok 14 ok 15 ok 16 --- fetch LONG data back again -- complete - LongTruncOk == 0 LongReadLen 82920, LongTruncOk ok 17 ok 18 ok 19 ok 20 ok 21 ok 22 ok 23 ok 24 --- fetch LONG data back again -- via blob_read Skipped blob_read tests for LONGs with OCI8 - not currently supported. ok 25 ok 26 ok 27 ok 28 ok 29 ok 30 ok 31 ok 32 ok 33 ok 34 ok 35 long_data0 length 20480 long_data1 length 81920 long_data2 length 71680 create table dbd_ora__drop_me ( idx integer, lng LONG RAW, dt date ) --- insert some LONG RAW data ok 36 ok 37 ok 38 ok 39 --- fetch LONG RAW data back again -- truncated - LongTruncOk == 1 LongReadLen 20, LongTruncOk 1 ok 40 ok 41 ok 42 ok 43 ok 44 ok 45 --- fetch LONG RAW data back again -- truncated - LongTruncOk == 0 LongReadLen 40955, LongTruncOk ok 46 ok 47 ok 48 ok 49 ok 50 ok 51 --- fetch LONG RAW data back again -- complete - LongTruncOk == 0 LongReadLen 82920, LongTruncOk ok 52 ok 53 ok 54 ok 55 ok 56 ok 57 ok 58 ok 59 --- fetch LONG RAW data back again -- via blob_read Skipped blob_read tests for LONGs with OCI8 - not currently supported. ok 60 ok 61 ok 62 ok 63 ok 64 ok 65 ok 66 ok 67 ok 68 ok 69 ok 70 long_data0 length 10240 long_data1 length 81920 long_data2 length 71680 create table dbd_ora__drop_me ( idx integer, lng CLOB, dt date ) --- insert some CLOB data ok 71 ok 72 ok 73 ok 74 --- fetch CLOB data back again -- truncated - LongTruncOk == 1 LongReadLen 20, LongTruncOk 1 ok 75 ok 76 ok 77 ok 78 ok 79 ok 80 --- fetch CLOB data back again -- truncated - LongTruncOk == 0 LongReadLen 81910, LongTruncOk ok 81 ok 82 ok 83 ok 84 ok 85 ok 86 --- fetch CLOB data back again -- complete - LongTruncOk == 0 LongReadLen 82920, LongTruncOk ok 87 ok 88 ok 89 ok 90 ok 91 ok 92 ok 93 ok 94 --- fetch CLOB data back again -- via blob_read ok 95 ok 96 ok 97 ok 98 ok 99 ok 100 ok 101 ok 102 ok 103 ok 104 ok 105 long_data0 length 10240 long_data1 length 81920 long_data2 length 71680 create table dbd_ora__drop_me ( idx integer, lng BLOB, dt date ) --- insert some BLOB data ok 106 ok 107 ok 108 ok 109 --- fetch BLOB data back again -- truncated - LongTruncOk == 1 LongReadLen 20, LongTruncOk 1 ok 110 ok 111 ok 112 ok 113 ok 114 ok 115 --- fetch BLOB data back again -- truncated - LongTruncOk == 0 LongReadLen 81910, LongTruncOk ok 116 ok 117 ok 118 ok 119 ok 120 ok 121 --- fetch BLOB data back again -- complete - LongTruncOk == 0 LongReadLen 82920, LongTruncOk ok 122 ok 123 ok 124 ok 125 ok 126 ok 127 ok 128 ok 129 --- fetch BLOB data back again -- via blob_read ok 130 ok 131 ok 132 ok 133 ok 134 ok 135 ok 136 ok 137 ok 138 ok 139 ok 140 ok t/plsql.1..63 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 ok 15 ok 16 ok 17 ok 18 ok 19 ok 20 ok 21 ok 22 ok 23 ok 24 ok 25 ok 26 ok 27 ok 28 ok 29 ok 30 ok 31 ok 32 ok 33 ok 34 ok 35 ok 36 ok 37 ok 38 ok 39 ok 40 ok 41 ok 42 ok 43 ok 44 ok 45 ok 46 ok 47 ok 48 ok 49 ok 50 ok 51 ok 52 ok 53 ok 54 dubious Test returned status 0 (wstat 139, 0x8b) test program seems to have generated a core DIED. FAILED tests 55-63 Failed
Re: code to auto insert sysdate into corresponding table for each user insert
Oracle's fine manuals include examples of similar triggers. Reading them would be a good idea. Once you've written the CREATE TRIGGER statement, you can use $dbh->do() to load it, but it would probably be easier to just keep it in its own .sql file and use SQL*Plus to create it. -- 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: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, April 28, 2001 9:06 PM Subject: code to auto insert sysdate into corresponding table for each user insert > Would like to see example of how to update or insert > a field in a corresponding table with the system date > ( sysdate ). The insert should happen based on > an insert of a column in the current table? So, the > current table experiences an insert by the user and > the trigger automatically inserts a sysdate into another > table based on the event. > > In other words, how would I write the PL/SQL trigger to do this? > > Or can this trigger/procedure be done through > DBI script which sets up the procedure in the first place > rather than running a PL/SQL sqlplus script ? > > Either way, I'd like to see the PL/SQL to write the trigger.
problems with DBD-Oracle compiling on 64 bit Oracle, Perl and SGI IRIX.
Hi, I am trying to get DBD-Oracle working on Oracle 8.1.6 on IRIX. As Oracle 8.1.6 is 64 bit only, I need to use 64 bit perl. I have successfully installed the DBI stuff, but when I try to install the DBD-Oracle stuff, I get the following problem: Using DBI 1.15 installed in /usr/freeware/lib/perl5/site_perl/5.005/irix-64/auto/DBI Writing Makefile for DBD::Oracle Argument "_ABIN32" isn't numeric in eq at /usr/freeware/lib/perl5/site_perl/5.005/sys/types.ph line 11. Argument "_ABIN32" isn't numeric in eq at /usr/freeware/lib/perl5/site_perl/5.005/sys/types.ph line 30. Argument "_ABIN32" isn't numeric in eq at /usr/freeware/lib/perl5/site_perl/5.005/sys/types.ph line 39. Argument "_ABIN32" isn't numeric in eq at /usr/freeware/lib/perl5/site_perl/5.005/sys/types.ph line 50. Argument "_ABIN32" isn't numeric in ne at /usr/freeware/lib/perl5/site_perl/5.005/sys/types.ph line 124. *** If you have problems, read the README and README.help files *** (Of course, you have read README by now anyway, haven't you?) For completeness here is the output from perl -V: bill 81% perl5.00503-n64 -V Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=irix, osvers=6.2, archname=irix-64 uname='irix neteng 6.2 12160003 ip22 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc -64 -mips3', optimize='-O3 -IPA', gccversion= cppflags='-D_BSD_TYPES -D_BSD_TIME -DLANGUAGE_C' ccflags ='-D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1184 -OPT:Olimit=0:space=ON ' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=8, ptrsize=8, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='cc -64 -IPA', ldflags =' -IPA' libpth=/usr/local/lib64 /usr/local/lib /usr/freeware/lib64 /usr/gnu/lib /usr/lib64 /lib64 libs=-lm libc=/usr/lib64/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-rpath,/usr/freeware/lib/perl5/5.00503/irix-64/CORE' cccdlflags=' ', lddlflags='-64 -shared ' Characteristics of this binary (from libperl): Built under irix Compiled at Jan 12 2000 14:22:12 @INC: /usr/freeware/lib/perl5/5.00503/irix-64 /usr/freeware/lib/perl5/5.00503 /usr/freeware/lib/perl5/site_perl/5.005/irix-64 /usr/freeware/lib/perl5/site_perl/5.005 /usr/freeware/lib/perl5/sgi_perl/irix-64 /usr/freeware/lib/perl5/site_perl . and here is the full output from the perl Makefile.PL bill 82% perl5.00503-n64 Makefile.PL Using DBI 1.15 installed in /usr/freeware/lib/perl5/site_perl/5.005/irix-64/auto/DBI Configuring DBD::Oracle ... >>> Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /u01/oracle/app/oracle/product/8.1.6 Found /u01/oracle/app/oracle/product/8.1.6/rdbms/demo/demo_rdbms.mk Found /u01/oracle/app/oracle/product/8.1.6/otrace/demo/atmoci.mk Using /u01/oracle/app/oracle/product/8.1.6/rdbms/demo/demo_rdbms.mk Reading /u01/oracle/app/oracle/product/8.1.6/rdbms/demo/demo_rdbms.mk. Reading /u01/oracle/app/oracle/product/8.1.6/rdbms/lib/env_rdbms.mk. Deleting ORA_NLS = $(ORACLE_HOME)/ocommon/nls/admin/data/ because it is not already set in the environment and it can cause ORA-01019 errors. Deleting ORA_NLS33 = $(ORACLE_HOME)/ocommon/nls/admin/data/ because it is not already set in the environment and it can cause ORA-01019 errors. Discovering Oracle OCI build rules... Oracle oci build prolog: RDBMSLIB changed after being used Building client shared library libclntsh.so ... Call script /u01/oracle/app/oracle/product/8.1.6/bin/genclntsh ... echo genclntsh genclntsh Built /u01/oracle/app/oracle/product/8.1.6/lib/libclntsh.so ... DONE true cc -Wl,`if [ "-64" = "-n32" ]; then echo "-n32" ; \ elif [ "-64" = "-64" ]; then echo "-64" ; \ Oracle oci build command: else echo "-64" ; fi` -Wl,-woff,16,-woff,84,-woff,85,-woff,134,-rdata_shared,-multigot,-mips3 -o build -rpath /u01/oracle/app/oracle/product/8.1.6/lib -L/u01/oracle/app/oracle/product/8.1.6/network/lib/ -L/u01/oracle/app/oracle/product/8.1.6/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh Found header files in rdbms/demo. System: perl5.00503 irix neteng 6.2 12160003 ip22 Compiler: cc -64 -mips3 -O3 -IPA -D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1184 -OPT:Olimit=0:space=ON Linker: /usr/bin/ld Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(QACCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) Using value of SGI_ABI from environment: -64 Using value of SGI_ABI from environment: -64 Evaluating `if [ "-64" = "-n32" ]; then echo "-n32" ; \ elif [ "-64" = "-64" ]; then echo "-64" ; \ else echo "-64" ; fi` returned '-64' Using value of SGI_ABI from environment: -64 Using value of SGI_ABI from envir
Re: Can DBD::Oracle connect to various versions of Oracle?
David, By the way : the same answers is good for Pro*C : with one particular Pro*C program, you can connect to any Oracle version. No need to recompile. Brgds, Mark David Good wrote: > Thanks! That's just the info I was looking for. I want to replace all of > the old Pro*C stuff with DBI and I'm glad I won't have to have a different > version of DBD::Oracle for every different version of Oracle. > > On Sat, Apr 28, 2001 at 05:37:39PM +0200, Mark Vandenbroeck ><[EMAIL PROTECTED]> wrote: > > David, > > > > Sure, no problem. I have Oracle 8.1.7, Perl and DBI, DBD::Oracle on my Linux > > laptop and connect without problem to a plethora of Oracle versions, ranging from > > 7.1.6 to 9i beta. > > > > The only limitation is that you have to use SQL*Net v2 on older versions of > > Oracle. Up to 7.3.4, SQL*Net v1 was still supported. Starting from 7.3.4, you > > can't use v1 anymore. So, if you want to connect to pre-7.3.4 versions, make sure > > you have the SQL*Net v2 listener configured and running. > > > > Hope this helps, > > > > Mark > > > > > > David Good wrote: > > > > > I've been wondering. We support a number of clients running various > > > versions of Oracle and I'd like to have just one copy of DBD::Oracle that > > > would be able to connect to them all. We currently have some custom Pro*C > > > apps and to hear the developers talk about it, they have to be compiled > > > alot differently for each version of Oracle they want it to run against. > > > > > > Is it possible to have one copy of DBD::Oracle that'll work with Oracle 7, 8 > > > and maybe even 9? > > > > > > -- > > > David Good [EMAIL PROTECTED] > > > > > > This space intentionally left blank. > > > > -- > > Mark Vandenbroeck Mobile : +32-495-59.55.62 > > Business Process Manager Email : [EMAIL PROTECTED] > > EMEA Support Information Systems AIM: markvdb > > > > > > -- > David Good [EMAIL PROTECTED] > > This space intentionally left blank. -- Mark Vandenbroeck Mobile : +32-495-59.55.62 Business Process Manager Email : [EMAIL PROTECTED] EMEA Support Information Systems AIM: markvdb
