Four months ago, Kevin P. joined a well-known health care provider as a project lead. Little did he know what he would find himself leading.

After a complete overhaul of the architecture (or what passed for an architecture), K.P. still deals with little nuggets of joy like this every day...

DECLARE PatientConfirmRec CURSOR FOR
SELECT ConfirmFlag
FROM Patient where policyGUID = @PolicyGUID
OPEN PatientConfirmRec
FETCH NEXT FROM PatientConfirmRec
WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE Patient
SET ConfirmFlag = 'N'
WHERE CURRENT OF PatientConfirmRec
FETCH NEXT FROM PatientConfirmRec
END
CLOSE PatientConfirmRec
DEALLOCATE PatientConfirmRec

The best we can tell, this is nothing more than an amusing way of saying:

UPDATE Patient SET ConfirmFlag = 'N'
WHERE PolicyGUID = @PolicyGUID

K.P. adds, You may notice the use of GUIDs. The resident developers were nearly moved to tears at the news that we would be eliminating GUIDs as row identifiers. Apparently a former “guru” had informed them that numeric row Ids are for row counting, and it is safest to use GUIDs for each PK, “just in case we ever have to use replication.”

Needless to say, K.P. has his work cut out for him.