How do I get the trigger_body from the user-triggers table in C#

Question

Background: I'm actually trying to identify autoincrement columns in an Oracle table from a C# program. I have already discovered that in Oracle autoincrement is done using a sequence and a trigger, and have identified the sequences and triggers in an example database using SQL Developer.

So, next step, get the triggers: this I can do with a query - "Select * from USER_TRIGGERS". No problem. There is even a TABLE_NAME field to check against the table I want to examine. (There is also a COLUMN_NAME column which might be useful, but that always seems to be empty).

Now there seems to be no alternative but to parse the TRIGGER_BODY field - but there's the rub. SQL Developer shows me that there is a meaningful-looking string in TRIGGER_BODY, but in my DataTable, returned from the query, the TRIGGER_BODY field is always blank.

I've hunted around on the web, and it seems that TRIGGER_BODY is in fact a LONG, although C# says the column is of type string, so I don't understand that. The only suggestion I've found so far is to use the TO_LOB() (or possibly TO_CLOB()) function to somehow convert the contents of the field, however that just throws an "inconsistent datatypes" exception.

I'm using C# 4.5, and Oracle.DataAccess for the data access objects. Oracle is at Version 11g.

Any suggestions would be gratefully received.

Answer 1

Once you have the owner and name of your trigger from dba_|all_|user_triggers , the easiest option is generally to use the dbms_metadata package to generate the DDL to create the trigger. That will be a CLOB that your front end should be able to work with.

DBMS_METADATA.GET_DDL('TRIGGER', <<name of trigger>>, <<owner of trigger>> )

Unfortunately, the LONG data type in Oracle was a very short-lived dead end data type. It was introduced some time in the Oracle 7 days if memory serves and was depricated by 8.1.5 in favor of the CLOB ( BLOB for the depricated LONG RAW ). Oracle has been recommending that people not use that data type for roughly 20 years. There are a whole host of restrictions on working with this data type. For the most part, it only exists in very old legacy apps and in the data dictionary tables where it was added since Oracle wants to ensure backwards compatibility of those views. Most front end tools today don't build in support for LONG data types because at the OCI layer it involves jumping through quite a few hoops that you only have to jump through to work with a LONG .