What error does it fail with? Specific error messages and the actual text of the message are always helpful when claiming that something does not work...
The code snippet is terrible on any number of fronts and a great deal will depend on the context in which it is really being run. Particularly due to point #2 below. But point #3 could also be critical depending on what the real code that really has a problem really does.
Some of the things that I do not like about the code:
0) Keywords are UPPER-CASED in the style of the Progress documentation.
1) The code follows the execrable counter-productive practice of "hungarian notation" prefixing gibberish onto perfectly good variable names for no reason and to no benefit.
2) Record, lock and transaction scope are uncontrolled and global.
3) A parameter is defined ("ipassword") with a name that is completely deceptive and used for another purpose completely (as the userid key) while the apparent function of the parameter is then fulfilled by a constant. (And this in a code snippet that uses hungarian notation which is supposedly all about making it clear about what things are...)
4) The procedure has no RETURN.
Best practice when changing passwords has *always* been to delete and recreate the record and to assign the password along with the userid in a single ASSIGN statement in a strong scoped block. Like this:
Code:
/* usermaint.p
*/
define variable id as character no-undo.
define variable name as character no-undo.
define variable password as character no-undo.
procedure changePassword:
define input parameter usrId as character no-undo.
define input parameter usrName as character no-undo.
define input parameter usrPassword as character no-undo.
define buffer curr_user for _user.
define buffer upd_user for _user.
define variable ok as logical no-undo.
/* this really ought to check that ENCODE( usrPassword ) = _user._password
*/
find curr_user no-lock where curr_user._userid = usrId no-error.
if available curr_user then
ok = yes.
do for upd_user transaction.
find upd_user exclusive-lock where recid( upd_user ) = recid( curr_user ) no-error.
if available upd_user then
delete upd_user.
create upd_user.
assign
upd_user._userid = usrId
upd_user._user-name = usrName
upd_user._password = usrPassword
upd_user._user-misc = ( if ok then "old" else "new" )
.
end.
return.
end.
update
id skip
name skip
password skip
with
frame get_user
side-labels
1 column
.
run changePassword( id, name, password ).
find _user no-lock where _user._userid = id no-error.
display _user with side-labels 1 column frame show_user.
If your code didn't do that and has worked in the past it is almost certainly accidental.
If it is breaking in 11.3 I would expect that that is because Progress has, over time, been plugging holes in the security model and whatever bug was accidentally allowing your old code to work has been fixed. Without knowing the actual error message and the real circumstances under which your code was running it is difficult to say more.