Det er ikke ualmindeligt, at man ser C# kode som herunder, hvor == operatoren benyttes til at sammenligne to variable.

MyClass o1 = ...;
MyClass o2 = ...;

if (o1 == o2)
{
  // ...
}

Muligheden for at overloade == operatoren (og Equals) i C# giver problemer med ovenstående if-statement.  Når man bruger == eller Equals, skal man skal kende implementation af MyClass nøje for at vide præcis, hvad ovenstående kode gør.  Ejeren af MyClass kan tilføje eller fjerne overload af == operatoren og dermed ændre resultatet af betingelsen i ovenstående if-statement.  Det kan vel nærmest sammenlignes med, at man en dag opdager, at ikke alene kan man bruge sin bilnøgle til sin egen bil, men man kan bruge samme nøgle til alle andre Porscher i verden (forudsat at man kører Porsche).

Ikke nok med at ejeren af ovenstående skal kende detaljerne i implementationen af MyClass.  Udviklere, som skal vedligeholde ovenstående kode, skal også vide, hvad hensigten med koden egentlig er.  Er hensigten at sammenligne objektreferencer, eller er hensigten at sammenligne en eller anden form for identity defineret af MyClass?

Man kan gøre sig selv den tjeneste aldrig at bruge Equals eller == operator, hvis man ønsker at sammenligne objektreferencer.  I stedet kan man gøre hensigten mere tydelig ved altid at bruge Object.ReferenceEquals, når man ønsker at sammenligne referencer.

C++ er lidt sejere på det punkt, i det der er forskel på pointer equality og objekt equality.  Man kan ikke overloade == operatoren for pointers, og identity mellem to objekter er kun defineret, hvis man overloader == for klassen.  Det betyder, at uden en == operator overload, giver linje 7 herunder en compile fejl.  Har man sådan en overload, vil b1 være sand (formentlig – afhængig af ens overload) og b2 vil være falsk.

   1:  MyClass *t1 = new MyClass();
   2:  MyClass *t2 = new MyClass();
   3:   
   4:  t1->value = 2;
   5:  t2->value = 2;
   6:   
   7:  bool b1 = *t1 == *t2; // Kræver operator overload
   8:  bool b2 = t1 == t2;

Ifm. sletning af store mængder data i SQL Server, kan det være en god idé at disable alle constraints og index på de omfattede tabeller først og enable dem igen, når DELETE operationen er færdig.

For en tabel kan man disable constraints og index med følgende SQL:

ALTER TABLE MyTable NOCHECK CONSTRAINT all

Nogle gange er det nemmeste bare at disable alle constraints på alle tabeller, og der kan det være en smule møjsommeligt at vedligeholde et script, der gør det for hver tabel. Heldigvis har SQL Server en udokumenteret stored procedure sp_msforeachtable, der kan udføre den samme SQL stump for alle tabeller i en database. For at disable alle constraints for alle tabeller i en database kan man bruge følgende:

EXEC sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"

Bemærk “?” hvor tabelnavnet indsættes. Som sagt er sp_msforeachtable udokumenteret, men iflg. Google er sp_msforeachtable en velkendt hemmelighed, og andre en Microsoft har skrevet en udmærket dokumentation, hvor man også kan se, at sp_msforeachtable tager flere nyttige parametre. Et eksempel på det kan man f.eks. se med følgende, hvor vi enabler alle constraints igen mens tabelnavnene printes ud. Her bruges parametrene @command1 og @command2. For hver tabel køres @command1 først og derefter @command2:

EXEC sp_msforeachtable @command1="print '?'", @command2="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

Og nej, det er ikke en fejl, at der står “CHECK CHECK”.