The Updtick is a technical column on the database layer, and a systems column used on classes and representations.

Accessing the property in the way you pointed out requires an implicit convertion, causing the error. Rather declare a variable of type Integer and reference that in the read statement.

Local Integer XAUPDTICK

[L]XAUPDTICK= [POH]UPDTICK 

Read [F:YCFPJOB]ZCFPJOB = [POH]POHNUM;[L]ZCLF_DOC_TYPE;[L]XAUPDTICK

Hello Regard

Thank you very much for your help.

I've tried it with an integer variable. The variable is declared outside the foor loop.

Unfortunately I still get the same error.

Could It be a problem that later in the loop the purchase order gets printed out with ALIM_ETAT and PRINT_ETAT leading to an increment of UPDTICK? I think rather not because this happens after the read statement of a POH record.

Kind regards

I have tried not to use [POH]UPDTICK in the Filter statement for achieving the same result. So I loop through the custom table only by POHNUM and ZDOCTYPE. If there is a record where ZDOCUPDTICK is equal to UPDTICK I return.

Even then I get the mentioned error. 

Hi Bense
Can you please indicate your X3 version: App and runtime please ?

Always start with versions information 

also, please details your custom table structure and data type.

Hello Bruno Bruno Gonzalez

Thank you for your reply.

We are using 2023 R1 (12.0.33) Version 90.33.115. The runtime version is 95.2.97.

That are the columns of the custom table ZCLFPENDJOBS:

Below are the indexes:

[L]ZCLF_DOC_TYPE is an integer variable. [ZSETUP] is a setup table which is open in this context. The column ACTIV is the local menu 1. AEXPFRM is a column of type AFF. The expression can be entered in a mask. At the time of executing this code the expression was:

ZPLNNUM is a custom alphanumeric column.

At the moment I'm trying if the error not occurs when I join the table PORDER with ZCLFPENDJOBS in a query stored in a clob variable instead of the filter on POH. I hope this way the error not occurs. 

Kind regards

I wonder if it isn't simply because the updtick gets updated in between by something else. Test your fstat if by any chance, it is equal to 6.

Generally speaking, I would advise you not to use UPDTICK for your development as Sage X3 internal code is using it, notably with classes.

If you need a counter, create your own, either with a trigger like you mentioned or preferably with a dedicated column perhaps based on a db sequence through uniqid instruction or even through call NUMERO

Later in the script we print the purchase orders.

This leads to a change in PRNFLG and therefore to an increment of UPDTICK. I thought this would not be a problem, because we read the UPDTICK before and at the time in the background UPDTICK of PORDER changes we are already at the next PORDER in the loop.

But maybe it sees that in the list of filtered records purchase orders are which no longer have the same UPDTICK value. Even though I don't want to read them and only the next ones it then probably throws the error because of this.

Thank you for the advice. At the moment I tend, as you suggested, to make a custom counter column and a workflow from type object with an action. In the action script I then update the custom counter , value with [F]CUST_COUNTER =+ 1.

Is the performance impact smaller with a workflow than with a SQL trigger? Can I increment the counter in the action script without making another write or rewrite statement? Does it make the write or rewrite statement at the end of the action with the current values in the table?

Are workflows save from updates? I don't see a field for an activity code.

I think a workflow is better because we don't need always to remember when we write a table at a new place to increment the custom counter. The counter is always updated. With the custom counter we don't get errors like mentioned here. Some hacks in the code are still necessary this way but I think it is ok. 

Thank you very much. 

Kind regards

Is the performance impact smaller with a workflow than with a SQL trigger?
=> depends... Workflow consumes a good amount of CPU, but if not called 1000 times per lines, should OK. Triggers can be fine as well until the PO gets updated all the time, which shouldnt be the case. If the table was BPCUSTMVT, I would have said "HELL YES"
Can I increment the counter in the action script without making another write or rewrite statement?
=> I don't remember when the workflow catches the modification: before or after the DB commit.

Does it make the write or rewrite statement at the end of the action with the current values in the table?
=> If you put the new column inside PORDER, then make sure the equivalent F and M class are loaded with the value. If the rewrite hasn't been made yet, then it will be taken into account. If it has been made, then you need to do it yourself, or just do an update statement since you only want to update 1 column on record where you have the PK. Careful with the DB transaction (see above).
Are workflows save from updates? I don't see a field for an activity code
=> Yes, custom manual workflows are considered settings and won't get erased, and not protected. You can still patch them to deliver them though.

Thanks a lot Bruno for your help.