In a previous article i wrote about a solution for passing values from the database via select statements to Ant properties inside Ant build files.

Now I’ve extended the Incanto <sqlplus> Task to do the other way round and pass Ant property sets into the SQL scripts as defined variables.

Within SQL*Plus it is possible to work with defined variables in the form of:

define myusername = SCOTT
define usertable = ALL_USERS
select * from &usertable where username='&myusername';

In case of running SQL scripts from Ant with Incanto one can pass single properties into SQL this way:

<property name="db.username" value="SCOTT" />
<ora:sqlplus silent="true" logon="${db.userid}" failonerror="yes">
 <![CDATA[
    define myusername = '${db.username}'
    select * from all_users where username='&myusername';
 ]]>
</ora:sqlplus>

Ant will replace all ${} style constructions with the given value of the property. But this works only for text content (SQL scripts) inside the tag (CDATA section) not with SQL script files that are called using the start attribute. You have to call the SQL file from within the CDATA section to workaround this drawback:

<property name="db.username" value="SCOTT" />
<ora:sqlplus silent="true" logon="${db.userid}" failonerror="yes">
 <![CDATA[
    define myusername = '${db.username}'
    @mysqlfile.sql
 ]]>
</ora:sqlplus>

I have extended Incanto’s <sqlplus> task to simplify this. It is now possible to include a <propertyset> element within the <sqlplus> task.

<property name="db.username" value="SCOTT" />
<ora:sqlplus silent="true" logon="${db.userid}" failonerror="yes">
  <propertyset>
    <propertyref prefix="db"/>
  </propertyset>
  <![CDATA[       
    select * from all_users where username='&db_username';
  ]]>
</ora:sqlplus>

All properties included by the <propertyset> element now can be used inside the SQL script. The <sqlplus> Task is passing these as defined variables into SQL*Plus. But note: since SQL*Plus has some rigid naming conventions for variable names, the <sqlplus> Task converts all dot (.) characters to underlines. Thus in the prior example I reference the property db.username by db_username.

8 Responses to “Using Ant properties within SQL scripts with Incanto’s <sqlplus> Task”

  1. peter Says:

    Hi,

    I am using the incanto task for updating and patching our development database schemas using SQL*PLUS on a windows XP machine.

    However, the ant task hangs quite frequently when running SQL*PLUS via incanto. Following the ‘hang’, I am unable to access the internet (or any databases using my Oracle tools).

    Have you heard or seen similar problems ?

    peter


  2. No, didn’t noticed similar problems so far. Incanto just start’s the sqlplus.exe and don’t do anything magical with Oracle directly, so it might be some general network configuration or installation issue. However, if u got any detailed information about ORA errors or what SQL-statements may cause any problems, I’ll appreciate bug reports very much … http://sourceforge.net/tracker/?func=add&group_id=136100&atid=734998
    … so we might be able to reproduce it.

    Alex

  3. peter Says:

    hi,

    Follow up to my previous comment here – I reworked my ant task to call SQL*PLUS via the ANT exec task and the problem still occurs.

    So, I agree with you – incanto is NOT to blame !!

    Sorry about that !

    peter

  4. Joe Says:

    I really like what you’ve done with incanto. I’m trying to use it as part of a packaging and deployment mechanism. I’ve found what I think are a couple of minor bugs/anomolies that I hope you can sort out.

    1) It seems that inline SQL statements that have whitespace at the beginning of the line cause them to fail. If I store these in a separate SQL file and call that it works.

    2) I like to use the “dot” command to escape the edit/entry within SQLPLUS followed immediately by the LIST command and forward slash “/” on separate lines.

    e.g.
    alter session set NLS_DATE_FORMAT = “HH24:MI:SS DD.MM.YYYY”
    .
    LIST
    /

    This allows me to have a detailed listing of what statements I want to execute followed by the result messages from SQLPLUS. I like to do this because a spooled log then becomes my documentation of the installation.

    Again, this does not seem to work with inline sql statements and I have to use external SQL files. My peference is do everything inline so that I could generate one big build file via a perl DBI script that extracts code from either a CVS repository or the database itself.

    I’m hoping you can address these two small issues?

    Thanks in advance,
    Joe


  5. Hello Joe,

    thanks for your information.

    2) I never used that “.” and LIST thing before and I’m not quite sure what it does nor what’s the difference to simply using a semicolon. Could you explain, what the “.” does and if there is a difference to “;”?
    It’s somewhat curious, seems that SQL*Plus has only problems with whitespace before a “.” – if I use a semicolon instead it works and I’ll get the desired result and output. The “.” works only when omitting the leading whitespaces. Again: the malefactor seems to be solely the “.” and it seems to be avoidable by using a “;” instead.

    1) Could you mail me or post a bug at sourceforge with a SQL sample. Because the samples I have are all working (except for the “.” thing)

    I fear that there wont be a really good fix to this leading whitespace issue. Cause it will involve other issues when I remove all leading whitespaces from all lines generally by Incanto, because in some cases whitespace might be necessary.

    I found inlining various things (like SQL) in XML always bit fragile due to these whitespace issues. Therefore either I avoid them (yep ugly indentions) or I use external SQL files, which I found much more comfortable to handle anyway.

    Regards, Alex

  6. Joe Says:

    Alex,
    The “.” simply escapes out of the sqlplus edit buffer and back to its command prompt. The “L” or “LIST” command echoes the current statement back to the console. I combing the two along with “/” to get a listing of the statement plus the execution results. The good news for me is that I found that a simple blank line — instead of the “.” — accomplishes the same thing — so I’m happy!

    e.g.
    alter session set NLS_DATE_FORMAT = “HH24:MI:SS DD.MM.YYYY”

    LIST
    /

    Thanks again!
    Joe

  7. Suchi Says:

    Can I use this sql tag inside tag?
    I want to query from existing table and mail that list.

  8. Suchi Says:

    missed in previous mesg …. inside tag? I want to query..


Leave a Reply