I'm working with an AREV 3.12 application. A user found that after saving a row on a window, then in using Alt-O (Copy contents of field previously displayed) on a new row, modifying the value. Once they move out of that prompt the value reverts back to the value the Alt-O put into the prompt. We've only had this happen when the Alt-O value has a period (.) in it.

The steps are:

Create a row, in the Parts Number prompt (no restrictions or validations, free form) put a number like 10.10028.

Save the row, without leaving the window.

Create a new row.

In the Parts Number prompt, enter Alt-O, edit the value then hit enter to move to the next prompt.

At this point the Prompt Number value will have reverted back to 10.10028.

Does anyone have any idea of why this happens and if there is anything I or my user can do about it? My impression so far from my research is this may be a system related happening that I may not be able to do anything about. But I'm still researching the problem.

Thanks,

Michael Slack

It probably has to do with numeric precision and the conversion of string to numeric variable types.

Try adding a user conversion that either converts the '.' to some non-numeric character other then e, E, +, or - or adds/removes an alpha character to the beginning of the string.

Is there any conversion on this field

No, I've checked the prompt on the screen in question and the column dictionary definition. Neither one has any sort of conversion.

The prompt is defined with a display length of 16 and a justification of "L" and lower case as "No".

The dictionary definition has a justification of "T" and display length of 60.

Neither one has a data type, output format or validation pattern.

One of the things I tried yesterday on the prompt definition was to set the data type to VARCHAR(100). That was after determining that all but a few rows (less than 10) had values over 100 characters. Most were below 30 characters. That didn't help anything. Actually it made things worst in that it (for some unknown reason) changed the prompt width to bigger than originally defined. This made it overlap into neighboring prompts.

Thanks,

Michael Slack

Are you sure there's not a post prompt or pre-prompt on the next field or perpetual process?

I tried this using the number you gave (10.10028) and it worked as expected.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

I checked the prompt and the next 3 prompts and no pre or post prompt processes. The prompts were about as basic as you can get. No perpetual processes either. I checked the window's processes and no perpetual processes there either. In checking the window's Customize settings, it's almost blank. The Locking, Menu and Protect Help prompts are set. Nothing strange or new there, they are set the same way for just about all of out windows. In wandering around thru other window related settings, couldn't find anything that would cause this or that was out of the ordinary.

I then checked all of the configuration settings but didn't see anything that might be the cause or out of the ordinary.

Thanks,

Michael Slack

In trying to figure out why this is happening, I may have stumbled onto a piece of information.

It seems to make a difference if the prompt is a single value or a multi-value. If it's a single value, things work as expected. But if it's a multi-value then this problem can occur.

Additionally, I was able to ALT-O the value into a multi-value prompt and change every character / digit except the very last one. Once I left the prompt, the last (right most) digit reverted back to the that of the ALT-O value. It seems that this happens only when the only character changed was the last one. For example, Alt-O the value 10.10028 into the prompt, then change the 8 to 9 (10.10029), then leave the prompt, the value reverts back to 10.10028.

I was able to replicate this in a different window attached to a different table.

Thanks,

Michael Slac

Sorry, but I still can't duplicate this.

The Sprezzatura Blog

World leaders in all things RevSoft

Thank you for trying and looking into this. I'm hoping that I'll be able to get with the original user who reported it to see if anything has been lost in translation that might help determine what is going on. Otherwise, we'll just have to be mindful of this particular situation if or until we can figure it out.

Thanks,

Michael Slack

View this thread on the forum...