Re: controlling SQLLdr's commit operations

[Quoted] "Ron Reidy" <rereidy_at_indra.com> wrote news:3BF031E8.7543E07F_at_indra.com...
> IMHO, You should always load into tables that are not a permanent
part
> of your application's "normal" schema (i.e. staging tables). If
there
> is a problem, you can always truncate and start again after the fix.
> From there you can use PL/SQL or some other method to move into your
> "normal" tables.

Thank you for your responses.
Since building a PLSQL program to load the tables into oracle using UTL_file is not very difficult
and has the benefit of leaving transaction control totally under my control I was wondering whether doing:

file --> PLSQL with readline, string manipulation and dynamic SQL insert clauses --> DB

is significantly slower than :

file --> SQLLDR --> staging table --> PLSQL moving data from staging table to real table --> DB

?

If not, is it then true to say that the only merits in the staging table approach is that the PLSQL code in the second case (which uses staging tables) is probably simpler and also that the staging table approach can leverage on SQLLDR's advanced capabilities ? Received on Tue Nov 13 2001 - 20:32:57 CET