Here's a very short testcase that demonstrates a technique of passing shell variables to Oracle SQL -

Code:

$
$
$ # display the content of the shell script "f36"
$ cat -n f36
    1  #!/usr/bin/bash
    2  EMPNAME="Napoleon Bonaparte"
    3  EMPID="1"
    4  EMPBDATE="15-Aug-1769"
    5  sqlplus -s test/test <<EOF
    6    INSERT INTO TBL1 (EMP_NAME, EMP_ID, BIRTH_DATE)
    7    VALUES ('$EMPNAME', $EMPID, TO_DATE ('$EMPBDATE','DD-Mon-YYYY'));
    8  EOF
$
$
$ # execute the shell script
$ ./f36
 
1 row created.
 
$
$
$ # verify that the record was inserted
$ echo "select emp_name, emp_id, to_char(birth_date, 'dd-Mon-yyyy') bdate from tbl1;" | sqlplus -s test/test
 
EMP_NAME                 EMP_ID BDATE
-------------------- ---------- -----------
Napoleon Bonaparte            1 15-Aug-1769
 
1 row selected.
 
$
$

I'll let you figure out the details of tailoring it for your scripts.

A few observations about your script:

(a) The Oracle documentation recommends the use VARCHAR2 datatype instead of VARCHAR. Check the Concepts Guide or the SQL Reference guide in the documentation set.

(b) Your "if" condition is redundant. The record count of a table is always 0 or something greater than 0. It can *never* be negative. So your "if" condition will always be true. In fact, I am not sure why you'd want to run a count(*) query before inserting a record into a table!!

(c) The exception handler "when others then null;" is a classic logical bug. That's because "when others" is a catch-all for all exceptions that you either don't know about or don't care about.

These exceptions could be something completely unrelated to your code; serious things like:

ORA-01000: maximum open cursors exceeded due to cursor leakage that could bring your Oracle database to a grinding halt,

or

ORA-1652: unable to extend temp segment by 1024 in tablespace <blah>
which means your temp tablespace is full and requires DBA intervention

or

the dreaded ORA-00600 internal kernel errors that might require you to contact Oracle support

etc. You don't want to "swallow" such exceptions (NULL; statement does exactly that). You want to raise such exceptions to your client program as soon as possible so you or your DBA could do something about it.

Instead of a NULL; there should be a RAISE; statement in "when others then" exception handler. Or better yet, leave it out altogether, and Oracle will do the escalation for you.

It's something like this - if you are on a vacation, and your house catches fire, you'd want to know that as soon as possible! You'd want to let go of your vacation and get back as soon as possible. The NULL statement gives you the impression that everything is fine and dandy, whereas you'd come back to a charred house!

Finally, Neo's suggestion is noteworthy. Small Oracle projects (such as yours apparently) that deal mainly with strings or "string-like" data may be fine with Unix shells. But as the project increases in scope and volume, and as you keep on adding more and more complex datatypes - LOBs, XML, timestamps, Collections - nested tables, varrays etc. the use of a wrapper API like Perl DBI or PHP or JDBC will make your life easier. They are very robust, well tested and bind quite tightly with complex Oracle types.

tyler_durden