Dan,
This is exactly the solution to all our SQLLoader problems that I was
trying to force into minds of our DB people during the last 2 months
since we first discovered the bug. Unfortunately, I am only responsible
for the client part of the project and they did not agree with me. Now I
am taking all the troubles after their brave decision. The funny thing
is they are too can no longer work with the database now because most of
our DB design/maintenance code also depends on DBI/DBD heavily.
Thanks,
Ivan Adzhubei
Dan Horne wrote:
>
> Hi Ivan
>
> I'm not sure if this is relevant or even useful, as I don't know your
> system, project timelines or software complexity, but I recently changes
> all of our SQL*Loader routines in one of our systems to use DBD-CSV to
> read the file, and DBD-Oracle to insert the data. Our main driver is that
> we wanted to move from a vendor-specific load tool, to a generic solution.
> In addtion, we have parameterised the loads so that a perl variable holds
> the csv field definition and another holds the table, so we have a perl
> configuration file that serves the same purpose as the SQL*Loader control
> file.
>
> We were using conventional, not direct-path loads, so the performance is
> roughly the same in our case.
>
> Dan
---
Anything is possible on paper.
-- Ron McAfee
