That should have read 8.1.7.0.0. And maybe I'll just patch it up to 8.1.7.4 before I try to go to 9i.

Has anyone run Pro-IV kernel 4.6 5.2.3 (glovia) with Oracle 8.1.7.4 on windows?

I found this in a trace file and have no idea what it means by "READ COMMAND ** DOES NOT EXIST **"

113705.095-OraCmdExec: Execute OK - rc = 0
113705.095-qgSqlFProc - FCB = 18FB1D0C, PFCB->FCRB = 00008004
113705.095-qgSqlFProc - NO TIB EXISTS
113705.095-qgSqlFProc: Open File and allocate new TIB
113705.095-qgStmCmp: exit TRUE, fMode1 0 fMode2 0 pFInst1 15892834 pFInst2 15892834
113705.095-qgSqlFOpen: tib 158D4070, pFcb 18FB1D0C, 'ODOM_OUT' -- Full Function
113705.095- Current ProIV function U_NXTVAL ls 1 fldno 68, curfile 1, 'ODOM_OUT'
113705.095-qgSqlFProc: FCB TIB = 158D4070
113705.095-qgPrmPreFSql: FULL FUNCTION COMMAND
113705.095-qgPrmPreRefs: ColumnReference ptr = 15892844
113705.095-qgSqlFProc: READ COMMAND **DOES NOT** EXIST
113705.095-qgStmCmp: XCPT_THROW (pStm1 != pStm2)

Without knowing if your predecessor had changed any stored procedures or not, I think you need to check:

1) The stored procedure U_NXTVAL which writes output to the ODOM_OUT table
2) The SL function U_NXTVAL which reads data from the table ODOM_OUT

Had they changed?

THANK YOU TO EVERYONE WHO HELPED ME WITH THIS ISSUE.

Here is the final resolution:

A custom program was going into an infinite loop. At some point the Pro32srv service would run out of resources and stop. It would appear all of the other error messages I received were symptoms of this root cause. I modifed the program and the Pro32srv service has not crashed since. Nor have I received any further errors in my trace files.

More info:
The custom function was specific to Mitsubishi and automated labor entry. The function read the table WO to get the next sequence (key) to add to the file LAB_TIM. The insert failed and then the program looped forevever as it had no Error logics. I simply added an sql call in the before read to query the LAB_TIM table and get the last sequence; add one and then insert. Just in case, I added error logics as well.

scminter,

Just curious, but why are you querying WO to get the next WO sequence instead of using an odometer?

I guess scminter is using an USER_ALPHA field to act as a sequence odometer for each WO LINE for LAB_TIM

I take slight offense. This is not my code, but standard Glovia 5.4.

They have two tables:

WO:

K CCN
K WO_NUM
K WO_LINE
WO_LAB_LASTSEQ

and

LAB_TIM:

K CCN
K MAS_LOC
K WO_NUM
K WO_LINE
K LAB_SEQ

Standard Glovia stores the value of the last labor sequence for a WO in the WO table. The consultant who created the customization basically started with a copy of Glovia's WOLTES function and modified it.

I added an SQL call to get the last seq from the table and increment before attempting the insert.

This design by Glovia could be a hold-over from when they were a flat file system. I do not know if it still exists in the current Glovia release.

scminter,

I admit, I quickly read your post, previous to my post about the odometer, and originally thought that you were querying the WO file to get the next valid WO sequence...hence my question. I realized my mistake shortly after my posting but since it was not a condemming post, as you thought it was, I didn't attempt to post a correction, and I apologize for that.

But, Dude, you need to take a chill pill. Take a look at all the people that tried to help you figure out this problem. While 99.9% of the people in this forum will offer constructive advice, you must take the pain from the salt that results from the other .1%. Typically, when people post requests for help, they don't give the full developmental life history of the code. When we say "you" or "your code" it is only "your code" in so far as to say that it was you that brought the code to us. These terms aren't meant to infer that you personally wrote the code.

Lastly, I've looked up a sample of LAB_TIM in C_RTGSCU, and if that is the way it was written that produced "the error", not "your error", then something is quirky because this is how most child records are maintained in Glovia, and it should work. It's exactly how I would've done it and there shouldn't be a need to SQL out to get the next value.

Ciao.