Can someone tell why myproc2 is more effecient than myproc1?

create or replace table mytable(
username varchar(100),
connectionstatus bit
);
------------
create or replace procedure myproc1()
--myproc1 sets all connectionstatus = 0
begin
for mycurs as curs sensitive cursor for
select username as current_username from mytable where connectionstatus = 1
--time1
do
    update mytable set connectionstatus = 0 where username = current_username;
    waitfor delay '00:00:30';
--time2     
end for;
end;
------------
create or replace procedure myproc2()
--myproc2 sets all connectionstatus = 0
begin
--time3
declare repeatloop bit;
declare current_username varchar(100);
set repeatloop = 1;
while repeatloop = 1 loop
    select top 1 username into current_username from mytable
        where connectionstatus = 1 order by 1;
    if current_username is null then
        break;
    end if;
    update mytable set connectionstatus = 0 where username = current_username;
    if not exists (select 1 from mytable 
        where connectionstatus = 1) then
        set repeatloop = 0;
    end if;
    waitfor delay '00:00:30';
end loop;
--time4
end;

There is also another concurrent process (not shown in code above) which connects sporadically to the database (with a separate connection than myproc1 / myproc2) and sets the connectionstatus to 1.

The problem with myproc1 is that it can't set all connectionstatus's to 0;

For me it looks like that the building of the cursor (scanning mytable) happens at the begining (at time1) (despite the cursor is declared with sensitive clause). How can I change the declaration of the cursor so that it scans mytable again at the end (at time2)?

In other words, if at the begining of iteration n-1 there was only one user (say user1) with connectionstatus = 1, and during the execution of this iteration the connectionstatus for another user (say user2) was set to 1, then I am missing the iteration n intended to set connctionstatus = 0 for user2.

Unfortunately it is difficult to post the code for the other process to reproduce the error, but I tested it several times and at the end the solution came only by using myproc2.