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.