help needed with a data update routine

number3son

New Member
This past weekend we upgraded from sxe 3.1.104 chui running progress 9.1.e to sxe 6.0.08 chui running progress 10.2.b05.

We have several existing qd's that we use from time to time and those with an "update" command don't seem to be working after the upgrade. Here is one in example that worked before but doesn't now (# sign is replaced with specific criteria)

disable triggers for load of poeh
for each poeh where poeh.cono = # and
poeh.pono = ##### and
poeh.posuf = ##
exclusive-lock:
display poeh.pono poeh.posuf. update poeh.stagecd.

The intent of this is to display the record(s) with an editable display of poeh.stagecd. Once displayed we can either change the value or leave as is.

Now when we run this command we get these two messages:
** "nxtrend.gpp" was not found. (293)
** Could not understand line 1. (193)

If I remove the update statement, the two fields display correctly with no errors, but this is not the goal.

Not sure what I am doing wrong here and what's different between the older vs newer versions causing this to not work. We have several other qd's that are similar in structure, but for different tables and I suspect they will all result in the same type of error.

Any help is appreciated. Thanks to anyone who responds with a possible answer.
 
As I recall "nxtrend.gpp" is an include file used in the "validate" statements in the data dictionary.

"Validate" makes a good demo but should never, ever be used in real code. Apparently someone at Trend missed that memo.

Chances are this is just showing you that your PROPATH is incorrect.
 
Hi, try this:

Code:
[COLOR=#333333]disable triggers for load of poeh[/COLOR]
[COLOR=#333333]for each poeh where poeh.cono = # and[/COLOR]
[COLOR=#333333]poeh.pono = ##### and[/COLOR]
[COLOR=#333333]poeh.posuf = ##[/COLOR]
[COLOR=#333333]exclusive-lock:[/COLOR]
[COLOR=#333333]display poeh.pono poeh.posuf. 
update poeh.stagecd[B] with no-validate[/B].[/COLOR]

Regards.
 
Err, if this is a trigger which is providing some relational integrity checks and the like, then disabling it and allowing free modification is *not* the right answer!
 
Hi Thomas, accordingly, as the word implies (NO-VALIDATE) it is obvious that there is a risk of not applying some important validation.Usually I reply with an example without much explanation because my English is pretty bad.
Regards.

Sergio
 
Yes, but depending on what is in that trigger, you may be introducing errors even beyond the no-validate. E.g., suppose the trigger is updating a denormalized total in another table.
 
Back
Top