T-SQL: Cursor is not advancing to next record

Question

SQL Version:  2008 R2
Problem:  I have the code below which uses a cursor.  The cursor keeps returning the first record and does not advance to the next record in the cursor.  It appears as if the Fetch Next is not being recognized.  The Select
Statement in the cursor declaration returns two records which is the result set I expect to be contained in the cursor record set.
...bob sutor
SQL CODE:
DECLARE
  @ProcessGroupID nchar(4)
 , @RemoveAuditUser nchar(128)
DECLARE CertGroupCursor CURSOR FOR
 SELECT DISTINCT CertGroups.GroupCode, CertGroups.RemoveAuditUser
     --, UserControl.ProcessGroupID, UserControl.VPUserName
 FROM udCertGroups AS CertGroups
  LEFT JOIN udAuditUsers AS UserControl
  ON CertGroups.GroupCode = UserControl.ProcessGroupID
 WHERE CertGroups.GroupCode = UserControl.ProcessGroupID
  AND CertGroups.RemoveAuditUser = UserControl.VPUserName
OPEN CertGroupCursor
 FETCH NEXT FROM CertGroupCursor INTO @ProcessGroupID, @RemoveAuditUser
 WHILE @@FETCH_STATUS = 0
 Print @ProcessGroupID + '-' + @RemoveAuditUser
 DELETE FROM udAuditUsers
  WHERE ProcessGroupID = @ProcessGroupID
   AND VPUserName = @RemoveAuditUser
 FETCH NEXT FROM CertGroupCursor INTO @ProcessGroupID, @RemoveAuditUser
CLOSE CertGroupCursor
DEALLOCATE CertGroupCursor
Bob Sutor

Answer 1

The real question is how to get rid of this mess. Think about the local “@remove_audit_user” as a variable; it's name is a verb, not a noun! and the NVARCHAR(n) lets you use Chinese Unicode. Why? In ISO-11179 rules , “remove_” is a called a role, and the
audit user would be the attribute with the attribute property “_user” in a valid data model. Where is the table that models “audit_users”? It has to be here by definition. 
One of the first rules of data modeling is that a data element has one and only one name. This is a results of the Law of Identity in Logic (A is A: to be is to be something in particular, to be nothing in particular or many things in general is to be nothing
at all). 
So how did “G.remove_audit_user = U.vp_user_name” occur??  ANSWER: lack of a design!
Your “G.group_code = U.process_group_id” is wrong. An identifier is not a code! TOTALLY DIFFERENT type of data elements! Do you have a postal code or a postal id? Blood_type or blood_id?  Etc.? Have you ever read a book on basic data modeling? 
The purpose of PRINT is debugging and not output. We had  joke in the ANSI X3H2 Committee that SQL means “scarcely Qualified as a Language” because there is no I/O. PRINT will screw up performance in so many ways. 
In a properly designed schema, we seldom use SELECT DISTINCT; we have keys and a valid schema that does not produce redundant duplicate rows. It might be valid, but after 30+ years of SQL, I would bet against it. 
Your statement would use an EXISTS() predicate to handle multiple columns and conditions. But you did not bother with DDL, as required by basic Netiquette, so here is the skeleton I can give you. 
DELETE FROM UD_Audit_Users
 WHERE EXIST
       (SELECT *
          FROM UD_Cert_Groups AS G
         WHERE G.process_group_id = ?? 
           AND G.vp_user_name = ??;
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL