4 Zgjidhje kur kufizimi unik ju pengon të futni një regjistrim të ri SQL Server

Nëse nuk keni arritur të futni një rekord të ri në një tabelë për shkak të kufizimit unik, mos harroni të lexoni këtë artikull. Do t'ju ndihmojë të zgjidhni këtë problem.

Në këtë artikull, ne do të prezantojmë 4 metoda për të zgjidhur problemin kur nuk arrini të futni një rekord të ri sepse ai shkel kufizimin unik të tabelës në SQL Server.

Një rast i vërtetë:

Tani le të shohim një rast real. Ne kemi një bazë të dhënash të quajtur "Produkt" dhe ekziston një tabelë e quajtur "DataNumenProdukt” në bazën e të dhënave. Ekzistojnë dy fusha në tabelë, p.sh., "ProductId" dhe "ProductName", me llojet e të dhënave përkatësisht "int" dhe "varchar". Dhe "ProductId" është një çelës kryesor me kufizime unike.

Aktualisht ka disa të dhëna në tabelë, si më poshtë:Regjistrimet në tabelë "DataNumenProdukt"

Figura 1 Regjistrimet në tabelë "DataNumenProdukt"

Duke supozuar se ka dy DBA për bazën e të dhënave, p.sh., Jim dhe Tom. Një ditë, Jim fshiu rekordin e parë në tabelë, si më poshtë:

DELETE FROM DataNumenProduct
WHERE ProductId=1;

Ditën e dytë, Tom futi një rekord të ri në tabelë, i cili ka të njëjtin çelës primar me rekordin e fshirë, si më poshtë:

INSERT INTO DataNumenProduct
VALUES(1,'DataNumen OutLook Repair');

Pra, tabela jonë ka të dhënat e mëposhtme, si më poshtë:

Regjistrimet e përditësuara në tabelë "DataNumenProduktet”

Figura 2 Regjistrimet e përditësuara në tabelë "DataNumenProduktet”

Tani nëse Jim dëshiron të rivendosë të dhënat e fshira përsëri në tabelë, ai do të shkelë kufizimin unik të çelësit primar "ProductId". Në një rast të tillë, ne mund të përdorim një nga zgjidhjet e mëposhtme për të zgjidhur problemin.

Zgjidhja 1: Ndryshoni çelësin kryesor të regjistrimit të ri për të parandaluar konfliktin

Ne mund të modifikojmë çelësin primar të rekordit për t'u futur në një vlerë të re e cila është e ndryshme nga ato të të gjitha rekordeve ekzistuese në tabelë. Merrni rastin e mësipërm si shembull, për të futur rekordin, ne mund të modifikojmë vlerën e çelësit primar nga 1 në 5. Më pas mund të rivendosim rekordin e ri të gjeneruar përsëri në tabelë, si më poshtë:

INSERT INTO DataNumenProduct VALUES(5, 'DataNumen Access Repair');

Më poshtë janë të dhënat përfundimtare në tabelë:Të dhënat përfundimtare në tabelë "DataNumen Produktet”

Figura 3 Regjistrimet përfundimtare në tabelë "DataNumen Produktet”

Zgjidhja 2: Ndrysho çelësin kryesor të regjistrimit ekzistues për të parandaluar konfliktin

  1. Së pari, duhet të përditësojmë vlerën e çelësit primar të rekordit ekzistues që mund të shkaktojë konflikt, si më poshtë:
UPDATE DataNumenProduct
SET ProductId = 6
WHERE ProductId = 1;

Më poshtë janë të dhënat e përditësuara në tabelë:

Regjistrimet e përditësuara në tabelë "DataNumen Produktet”

Figura 4 Regjistrimet e përditësuara në tabelë "DataNumen Produktet”

  1. Pastaj ne mund të rivendosim rekordin e fshirë përsëri në tabelë, si më poshtë:
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair ');

Tani le të shohim versionin përfundimtar, si më poshtë:

Regjistrimet përfundimtare në tabelë "DataNumen Produktet”

Figura 5 Regjistrimet përfundimtare në tabelë "DataNumen Produktet”

Zgjidhja 3: Çaktivizoni përkohësisht kufizimin unik nëpërmjet SQL

  1. Për të zgjidhur problemin, mund ta fshijmë përkohësisht kufizimin e çelësit primar "pk" në tabelë, si më poshtë:
ALTER TABLE DataNumenProduct
DROP CONSTRAINT pk;
  1. Pastaj ne mund të shtojmë përsëri rekordin e fshirë në tabelë, si më poshtë:
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair');

Tani le të shohim të dhënat në tabelë:

Regjistrimet e përditësuara në tabelë "DataNumen Produktet”

Figura 6 Regjistrimet e përditësuara në tabelë "DataNumen Produktet”

  1. Pastaj duke qenë se dy rekorde kanë të njëjtat vlera kryesore kryesore, ne duhet të modifikojmë njërën prej tyre për të parandaluar konfliktin, si më poshtë:
UPDATE DataNumenProduct SET ProductId = 5
WHERE ProductName = 'DataNumen Outlook Repair';
  1. Më në fund, ne shtojmë përsëri kufizimin e çelësit primar "pk" në tabelë, si më poshtë:
ALTER TABLE DataNumenProduct
ADD CONSTRAINT pk PRIMARY KEY(ProductId);

Tani ka disa të dhëna në tabelë, si më poshtë:

Përmbajtja e përditësuar në tabelë "DataNumen Produktet”

Figura 7 Përmbajtja e përditësuar në tabelë "DataNumen Produktet”

Zgjidhja 4: Çaktivizoni përkohësisht kufizimin unik nëpërmjet SQL Server Studio Menaxhimi:

  1. Në radhë të parë, ne fshijmë kufizimin kryesor të çelësit "pk" në tabelë përmes GUI, si më poshtë:

Fshini kufizimin e çelësit primar "pk" përmes GUI

Figura 8 Fshini kufizimin e çelësit primar “pk” nëpërmjet GUI

  1. Më pas fusim rekordin e fshirë në rastin real në tabelë, si më poshtë.
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair');

Tani ka disa të dhëna në tabelë, si më poshtë:

Përmbajtja e përditësuar në tabelë "DataNumen Produktet”

Figura 9 Përmbajtja e përditësuar në tabelë "DataNumen Produktet”

  1. Pastaj ne modifikojmë vlerën e çelësit primar të rekordit ekzistues në tabelë, si më poshtë:
UPDATE DataNumenProduct
SET ProductId = 5
WHERE ProductName = 'DataNumen Outlook Repair';
  1. Më në fund, ne shtojmë përsëri kufizimin kryesor të çelësit "pk" në tabelë përmes GUI, si më poshtë:Shtoni përsëri kufizimin e çelësit primar "pk" nëpërmjet GUI

Figura 8 Shtoni përsëri kufizimin e çelësit primar “pk” nëpërmjet GUI

Zgjidh SQL Server Korrupsioni i bazës së të dhënave

Përveç kufizimeve unike, SQL Server korrupsioni është gjithashtu një problem shumë i zakonshëm që i bezdis DBA-të. Normalisht mund të përdorim SQL Server komandat e integruara për të zgjidhur problemet. Sidoqoftë, nëse ato nuk funksionojnë, atëherë mund t'i drejtohemi disa palëve të treta SQL Server mjetet e rikuperimit të të dhënave.

Hyrje e autorit:

Jim Hu është një ekspert i rikuperimit të të dhënave në DataNumen, Inc., e cila është lider botëror në teknologjitë e rikuperimit të të dhënave, duke përfshirë Riparimi i aksesit dbf riparimin e produkteve softuerike. Për më shumë informacion vizitoni www.datanumen.com

Komentet janë të mbyllura.