In the Uniface IDE, when attempting to delete a signature related to a component, it fails with the following error:

I/O function: D, mode: 0, on file/table: USOPER
ORA-01407: cannot update ("USYS10_CARS_DEV"."USIOPER"."USPECNAM") to NULL
ORA-06512: at "USYS10_CARS_DEV.USOPER_D", line 8
ORA-04088: error during execution of trigger 'USYS10_CARS_DEV.USOPER_D'
ORACLE Driver Error [-29]: Delete driver function failed.

The referential integrity on the repository is supplied by Uniface. In looking at the database trigger, I can't understand why it would be setting a non-nullable field to null; this obviously won't work.

How would I be able to successfully delete the signature using the IDE? I realize it would be risky to do this at the database repository level itself but I can see no other alternative.

Our Uniface version is 10.3.02.056.

Thank you.

This is a known issue that affect (AFAIK) the MSS (Microsoft SQL Server), ORA (Oracle) and SYB (Sybase) connectors. The recommended workaround is to not use the DBMS referential constraints and set 'ri = uniface' in the DBMS connector params. The IDE itself will make sure that the repository data is consistent.

I hope this helps.

------------------------------
Daniel Iseli
Principal Technical Support Engineer
Uniface Services
Rocket Software, Switzerland
------------------------------

Thank you for your reply Daniel.

I dropped the offending triggers from the database and was able to successfully delete the signature. I didn't need the "ri=uniface" connector parameter; Uniface cascaded the delete down to the many entities without this setting.

Any idea on when this issue will be fixed? You referred to the solution as a workaround so I assume this means there will be a permanent fix to this problem at some point.

Thank you again Daniel.

No, this issue has a medium priority and is currently not very high on the maintenance backlog. The required repository changes could only be done in a major release. And the next one would be 10.5. So far there are, however, no concrete plans for that (yet). In the end it will be a matter of priorities and available resources if this could be picked or not. Sorry.

For the time being it is recommended to use the available workaround.

 I hope this clarifies this matter.