What would cause setuserid to return false? How can I resolve this issue? I have deleted the use and added it back with the same results. All other users have no issues.
I can run the following ABL.
There is only one "Myuser" in the table. The domain name is blank. In this case the password is blank.
FIND FIRST myDB._user WHERE myDB_user._userid = 'Myuser' NO-LOCK NO-ERROR.
The record is available.
lResult = SETUSERID ('Myuser', '', "myDB").
lResult is false.
error status is false.
FIND FIRST myDB._user WHERE myDB_user._userid = 'Myuser'
and myDB._user._Domain-Name = '' NO-LOCK NO-ERROR.
The record is available.
lResult = SETUSERID ('Myuser', '', "myDB").
lResult is false.
error status is false.
for each myDB._user WHERE myDB_user._userid = 'Myuser' NO-LOCK
returns 1 record.
OE11.5.1, 64-bit, windows server
Thank you for your input. I discovered the root cause.
From idxfix
Error:Found a duplicate delete holder entry(32bit) (17467)
Error:The error entry is for transaction 77260175, index 0, dbkey is 23072 (17466)
Which takes us to KB Article Number 000058872
[View:http://knowledgebase.progress.com/articles/Article/Some-users-fail-to-login-with-error-710?q=000058872&l=en_US&fs=Search&pn=1:550:50]
You show no code demonstrating that the password is blank, if it is blank, it needs to be equal to ENCODE( "" ).
Additionally, is the user really called 'myuser' or is it something else that may contain invalid (for a user id) characters?
Thank you for your input. I discovered the root cause.
From idxfix
Error:Found a duplicate delete holder entry(32bit) (17467)
Error:The error entry is for transaction 77260175, index 0, dbkey is 23072 (17466)
Which takes us to KB Article Number 000058872
[View:http://knowledgebase.progress.com/articles/Article/Some-users-fail-to-login-with-error-710?q=000058872&l=en_US&fs=Search&pn=1:550:50]
what tool can be used online to do the same as; IdxBuild to rebuild the _user table indices( by table):
idxfix and idxcompact did not get the job done.
> idxfix and idxcompact did not get the job done.
Did you use the low (50%) packing factor with idxcompact?
How full is dbkey 23072? Check with proutil db -C idxblockreport _User._Userid
The result of idxblockreport _User._userid is
Error: Both table and index numbers are required. (16145)
Mea culpa. I missed that idxblockreport does not work with index number 0.
If you have an off-line copy of the database then you can use dbrpr to dump the block.
I made an off line copy of the DB. Ran dbrp to dump the block.
dbrpr
13. Display Block Contents
2. Dump Index Block Details
6. Start Dbkey: 23072
What can be done with the block .dmp file values?
Schema Area (6) Extent 1 Block 722
-----------
0000 bk_dbkey: 0x00005a20 23072
bk_type: 0x04 4 (Free Block)
bk_frchn: 0x00 0 (FREECHN)
bk_incr: 0x000e 14
bk_nextf: 0x0010a320 1090336
bk_updctr: 0x00000666 1638
Post the first two lines.
For example:
>0000 8000 0000 027F 0100 0000 0000 6F01 0000 >0010 0101 0100 0000 0000 B200 530A 0000 0000
where 0xB200 is the number of index entries
and 0x530A is the number of the used bytes
>0000 205A 0000 0400 0E00 20A3 1000 6606 0000
>0010 0000 0000 0000 0000 0000 0000 0000 0000
bk_type: 0x04 4 (Free Block)
Strange. It should be "Index Block".
DISPLAY BLOCK MENU
------------------
1. Dump Data Block Details
ON 2. Dump Index Block Details
3. Select Block Type
4. Start Block: none
5. End Block: none
ON 6. Start Dbkey: 23072
ON 7. End Dbkey: 23072
8. Change Current Working Area
G. Go
Q. Return to Main Menu
(Current Working Area: Schema Area)
Choice: G
Schema Area (6) Extent 1 Block 722
-----------
0000 bk_dbkey: 0x00005a20 23072
bk_type: 0x04 4 (Free Block)
bk_frchn: 0x00 0 (FREECHN)
bk_incr: 0x000e 14
bk_nextf: 0x0010a320 1090336
bk_updctr: 0x00000666 1638
OOPS, I think I fixed the offline version of the DB using idxbuild.
Will idxfix report on this db copy the previous error?:
Error:The error entry is for transaction 77260175, index 0, dbkey is 23072 (17466)
I will create the off line copy of the DB and dump the block info again.
dbrpr, 4 - dump block, dbkey 23072 creates 23072.dmp
The first 2 lines are
>0000 205A 0000 027F 0E00 0000 0000 6406 0000
>0010 0101 0000 0000 0000 C500 820A 0000 0000
Block contains 197 index entries that use 2690 bytes. But it's the only block of the _Userid index (it's a both root and leaf block).
Try proutil db -C idxcompact _User._Userid 50
I did not check this but idxcompact might delete the index entry locks when the used space in a single block is higher that the packing factor. If it does happen then the block dump will show the different numbers on the second line.
proutil db -C idxcompact _User._Userid 50
Error: Both table and index numbers are required. (16145)
With any packing factor?
Idxcompact and idxblockreport seem to share the same code. ;-(
Thank you George for your time. I will switch my focus to schedule some DB downtime to use idxbuild. I got a lot out of the attempts and steps you offered.
Make it a great day.