Just an idea but how about using Java Stored Procedures? They would allow
better control over OS files. Also they would be housed within the
database. Combine this with some Oracle XML technology your work could be
made alittle easier. Although memory intensive.
>From: Jared Still <jkstill_at_cybcon.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: Re: Flat file generation integrity ideas...
>Date: Sat, 26 Oct 2002 20:38:30 -0800
>
>
> >
> > And I don't have proof, but I am absolutely positive that using UTL_FILE
>is
> > faster then Perl...I just know it is....it's gotta be.......
>
>:)
>
>I'm currently working on a little project for someone to create a table
>unloader in PL/SQL. Before you ask, I can't share on this one, it's
>proprietary. And it has to be done from the database. :(
>
>A limitation of UTL_FILE is that the output line length is limited to 32767
>characters. 32768 including the LF.
>
>Some problems with unloading in PL/SQL are obvious:
>
>What if the line is longer than 32767? I'm going to create continuation
>lines in the file. An external utility will need to be run to 'correct'
>these
>lines.
>
>What if there is a LONG column. Ugh. These can be dealt with, but it
>ain't pretty. Think global temporary tables and the TO_LOB SQL function
>to convert them to a LOB, so that DBMS_LOB may be used to read them.
>
>I'm going to allow NCLOBS, CLOBS only. No BLOB or LONG RAW columns.
>I don't know of any way to load these from sqlldr if the column length
>exceeds 32767. ( via utl_raw package )
>
>Of course, none of this may be a problem with your data.
>
>Jared
>
>
>
>
> >
> > I will take a look at sqlunldr.pl, thanks.
> >
> > CG
> >
> >
> > -----Original Message-----
> > From: Jared Still [mailto:jkstill_at_cybcon.com]
> > Sent: Sat 10/26/2002 10:45 PM
> > To: ORACLE-L_at_fatcity.com; Tim Gorman; Grabowy, Chris
> > Cc:
> > Subject: Re: Flat file generation integrity ideas...
> >
> >
> >
> >
> > I was going to suggest MD5 as well. Though I was thinking of the Perl
> > version.
> >
> > The DBMS_OBFUSCATION version is fine, but I was thinking of the unload
> > method.
> >
> > Chris, how are you creating the flat files? UTL_FILE? SqlPlus?
> >
> > Perl is much faster than sqlplus, dunno about UTL_FILE, as I haven't
> > compared them for speed. (yet)
> >
> > PL/SQL also requires about 10x more code for this kind of thing than
>Perl.
> >
> > You *could* just modify the sqlunldr.pl script in "Perl for Oracle
>DBA's"
> > to add MD5 checksums at the beginning of the line. You could also
>easily\
> > MD5 the entire file in one line of code.
> >
> > If you're using C, well, you're just working too hard. ;)
> >
> > Jared
> >
> > On Thursday 24 October 2002 15:24, Tim Gorman wrote:
> > > RE: Flat file generation integrity ideas...DBMS_OBFUSCATION_TOOLKIT
>has
> > > an (undocumented) function called MD5 which uses that protocol (MD5)
>to
> > > calculate checksums. Look at $OH/rdbms/admin/dbmsobtk.sql... -----
> > > Original Message -----
> > > From: Jamadagni, Rajendra
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: Thursday, October 24, 2002 12:46 PM
> > > Subject: RE: Flat file generation integrity ideas...
> > >
> > >
> > > you could also use dbms_utility.get_hash_value ... to compute hash
> > > value for the whole row and store that as an additional column. Be
>syre
> > > to use the same parameters on both sides to compute and test, else it
> > > will fail the check.
> > >
> > > Raj
> > > ______________________________________________________
> > > Rajendra Jamadagni MIS, ESPN Inc.
> > > Rajendra dot Jamadagni at ESPN dot com
> > > Any opinion expressed here is personal and doesn't reflect that of
> > > ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an
> > > art!
> >
> > ----------------------------------------
> > Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
> > Content-Transfer-Encoding: quoted-printable
> > Content-Description:
> > ----------------------------------------
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Jared Still
> INET: jkstill_at_cybcon.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
Internet access plans that fit your lifestyle -- join MSN.
http://resourcecenter.msn.com/access/plans/default.asp
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jay Wade
INET: fish_dba_at_hotmail.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Sun Oct 27 2002 - 15:53:27 CST
