Debugging Noetix View Administrator's View Regeneration Process

I find that after a cloning of an instance (especially a development or testing environment), my xu2 or xu5 invocations cause various errors during a Noetix View Administrator (NVA) view regeneration.  

Typically, when working in newly cloned instance (especially in a development or testing environment), there are set-ups associated with my new development (e.g. grants, missing objects like a package which a new xu2 or new xu5 script might depend) that should be done before one would want to run a regeneration of the Noetix Views.  In most cases, it would makes sense to have a MD120 documents for all new development (set-up and installation document created as you work on new development ....why would you not?).  If you do not document these set-ups, I find that this is common source of problem when I receive errors that occur when the makeview*.sql files are executed.

The standard xu2 or xu5 spool files are pretty easy to read and search for errors (see other posts), but I wanted to post on situations that seem more opaque.  Specifically, what if you are not receiving any errors in your xu2 or xu5 spool files, yet the Noetix View Administrator is throwing an error during the regeneration process. 

The purpose of this post is to document an approach to addressing these opaque situations (no xu2 or xu5 error, yet the regeneration process is failing).

Here are simple things that can be done to address this:

1.       Other Sessions causing problems: I have noticed that a number of problems with the NVA session terminating can be attributed with another user's database sessions with locks on various records in the Noetix schema.  With this problem, one would want to resolve/identify how to have those locks removed (e.g. have users complete their work and commit or rollback).

2.        Identify the last Script Invoked prior to the termination of the NVA session: I am assuming that you are working with an NVA installed on a Window server.  With this scenario, you might want to investigate what script was last invoked before the Noetix View Administrator terminated. I just start a Windows Explorer session (using a details view) and find the last spooled file (*.lst) updated in the script home.

3.       Look at the finderr.lst file:  Another approach that one can use is a variation of using the “seeded” approach of using the error messages at the end of an NVA regeneration process (specifically stage 4).  Suppose you logged out of the NVA and have returned to your work later.  One can just look at the finder.lst file (again in the script home file) and exhaustively examine every error thrown.

4.        Look at the last text associated with terminal output (with the NVA) and query the file using powershell (comes with windows 7 desktops):

e.g. find the SQL exception

Get-ChildItem -Path "\\server_name\Noetix Corporation\NoetixViews\Installs\NOETIX_SYS_ERPTST" -Filter "*.lst" | Select-String -pattern "ORA-[0-9]+"

e.g. find the last terminal output text

Get-ChildItem -Path "\\server_name\Noetix Corporation\NoetixViews\Installs\NOETIX_SYS_ERPTST" -Filter "*.sql" | Select-String -pattern " Add columns from base tables”

5.       Leverage the terminal output script, noetixd.sql.  This is a very uncomplicated script which one can change the level of the NVA’s terminal output for the purpose of debugging.  Of course, make a copy of the original file and then enable the level of debugging that one wants.  I personally find modifying the level of output very interesting (just to be cognizant of what scripts are being invoked at any given time).  Chances are, if you are seriously considering this choice in terms of your debugging, you probably should also be considering submitting a help desk ticket to Noetix.

Happy debugging!