Attempt to update data exceeding 32000. (12371) **Unable to update field. (142)

[PrJlndni]

Hi good day!

I would like to ask some help of your expertise.

I only wanted to search for data using a button "find". But everytime I enter the data, I cannot search. This error prompts immediately. I tried to remark the "set/update findstr with frame f-find" and message something to check if it's working. It worked. Now I can see that the problem is the "set/update" field.

Please help. Thank you.

 

[TomBascom]

You might want to consider sharing a code snippet that illustrates the problem.

 

[PrJlndni]

Good day Sir,

The following are the codes that I'm currently working on.

ON choose of b-find IN FRAME fr-buttons DO:
DISABLE ALL WITH FRAME fr-buttons.
UPDATE findstr2 WITH FRAME fr-find.
END.

[HASHTAG]#Whenever[/HASHTAG] I pressed the ENTER button, this error prompts:
Attempt to update data exceeding 3
** Unable to update Field. (142)


Please help. Thank you.

 

[RealHeavyDude]

You do not reveal the complete code therefore we do not see how findstr2 is defined. Nevertheless, if I would be forced to, I would speculate that the variable definition does not contain the no-undo option which causes the undo limit of rougly 32000 bytes for a single procedure to be blown.

You might want to have a look here:
http://knowledgebase.progress.com/articles/Article/P23274

Heavy Regards, RealHeavyDude.

 

[PrJlndni]

Hi Sir RealHeavyDude,

Your speculation is indeed true. Now, my problem is solved. Thank you very very very very much for your help.

But Sir, I have a question. Why is it that the our system is running fine for many years already without the NO-UNDO option? It's just weird that only last week, it crashed.


Best Regards,

PrJlndni

 

[Cringer]

What else has changed?

 

[RealHeavyDude]

Firstly, not using the no-undo option in variable definitions is bad practice. There are only a handful of use cases where you want that the changes to variables during a transaction are undone when the transaction is rolled back ( undone ). Therefore, defining variable and temp-tables with the no-undo options is good practice unless you deliberately require them to be undo when a transation is rolled back.

To answer your question one can only speculate: I think that a user entered more than what was left on the undo stack for that procedure. Probably she/he pasted the clipboard contents into it. Since the update statement not only allows the data to be entered into the screen buffer - but also assigns the variable buffer in one step you have no way to validate the user input before the variable buffer gets assigned. In order to have more control what happens you can use the combination of display, prompt-for and assign to achieve the same functionaly but keep full control.

The online help pretty much explains the behavior of the update statement.

Heavy Regards, RealHeavyDude.

 

[PrJlndni]

Thank you Sir for that very informative response. Now, I know the importance of the NO-UNDO option.

Thank you again.


Best Regards,

PrJlndni