This content has been marked as final. Show 5 replies
I have found the problem yesterday night. By checking the ALL_WM_VT_ERRORS I found that one of the triggers on the table had became unfunctional, beacuse one of it's code's row which was originaly commented out by -- sign became uncommented in the code that the workspace manager had genereated from it. I only can guess that the problem with that row of code was mainly that it has the original table name in it, which could make the code generator of the workspace manager fail. I don't mark the question answerered yet, I would like to find out more about that issue. Should I use /* */ always for commenting?
Btw, I had to disable the versioning of the table to fix the problem, using both disableversioning('TABLE_NAME', true) to force disable, and disableversioning('TABLE_NAME', ignore_last_error=>true). After deleting the commented line and recompile the trigger it was all ok.
What version of Workspace Manager are you using?
You should be able to use either type of comment within triggers. Was there a quote within the comment? If so, you may have run into a bug that has since been fixed. Upgrading to the latest version should solve the problem. If not, I would be interested in seeing the trigger body.
We are using 188.8.131.52.0.
I'm including the whole script we run to create the trigger:
create or replace trigger TRG_VEZSZAKOK_AUR
-- after update on VEZSZAKOK_LTS for each row
after insert or update on VEZSZAKOK for each row
As you can see we have kept the beginddl and commitddl rows just like the row with the _LTS table commented out, if we would like to run it on the table after version enabling it.
This does appear to be a bug. The comment in the description part of the trigger definition isn't expected. As a result, the schema name is appended to the wrong table name. It would have worked if the comment came after the actual description. Also, this affects both types of comments.
If you need a fix for 184.108.40.206, I would suggest filing a SR.