[ms sql] dubbele records in autonummerings veld

[TeeDee]

Hoe is het mogelijk dat er in een Id veld met autonummering (kweenie hoe je dat precies noem) dubbele Id's staan.

Dus:
1, 2, 3, 1, etc. etc.???

Dat zou toch niet mogen?

[whoami]

Dat zou wel sterk zijn.... Ben je zeker dat het autonr is?

[TeeDee]

yup...

als hij in ms sql op identity staat is het toch autonummering?

[robjanssen]

Is het veld ook PRIMARY KEY?

[whoami]

Volgens mij moet een autoincr niet noodzakelijk een PK zijn om hem uniek te maken. 'k Zal het eens testen.

edit: dat hoeft dus niet. Ik heb net eens een tabel aangemaakt in Acces met een auto-inc field dat geen PK was en waar er geen unique constraint op lag. Access zorgt gewoon dat de nrs ge-autogeincrementeerd worden.

[TeeDee]

Dus:

het probleem is er. Maar door die dubbele waardes werkt een stuk van mij code niet meer.

Ik kan vanuit de enterprise manager die velden niet verwijderen. Waarom weet ik niet precies.

Is er een mogelijk om handmatig die records te verwijderen?

/edit: gek genoeg gaat het nu wel goed. Alleen de eerste paar waren fout (+/- 15 records)

Ik heb met testrecords van mezelf iets geprobeerd. Delete uit SQL where ID = Id (zeg maar )
Maar dan delete ie alle 2 de dubbele records.

[Crazy D]

Identity is auto increment, iig in sql7, dus dubbele id's zou dan wel heel vaag zijn. Zeker weten dat er niet een ander veld de boosdoener is?

[edit]woei volgende keer eerst refreshen voor replyen ben wel erg traag...

[TeeDee]

Op woensdag 29 mei 2002 20:12 schreef Crazy_D het volgende:
Identity is auto increment, iig in sql7, dus dubbele id's zou dan wel heel vaag zijn. Zeker weten dat er niet een ander veld de boosdoener is?

Nope,

ik kan je een screendumpie geven als je me niet geloof

/edit:
ik krijg het dus niet voor elkaar om die Id te wijzigen.

/edit2:
het zijn ook exact dezelfde records. Dus het lijkt net of ze dubbel geinsert zijn. Maar dan zou ie nog de id moeten optellen!

[Annie]

Heb je niet toevallig met identity_insert on op de tabel inserts/imports gedaan?
Of met dbcc checkident de seed opnieuw ingesteld?

Btw om het probleem op te lossen kan je de tabel importeren in een kopie van de tabel met een nieuw identity veld (waarbij je de oude niet meeneemt). Daarna kan je de oude tabel droppen en de nieuwe renamen en opschonen.
Andere optie (niet getest overigens) is de identity eigenschap verwijderen en een nieuwe identity kolom aanmaken met identity. Je hebt dan weer een unieke key voor je rows, ... enz.

[whoami]

Op woensdag 29 mei 2002 22:47 schreef Annie het volgende:
Heb je niet toevallig met identity_insert on op de tabel inserts/imports gedaan?
Of met dbcc checkident de seed opnieuw ingesteld?

Btw om het probleem op te lossen kan je de tabel importeren in een kopie van de tabel met een nieuw identity veld (waarbij je de oude niet meeneemt). Daarna kan je de oude tabel droppen en de nieuwe renamen en opschonen.
Andere optie (niet getest overigens) is de identity eigenschap verwijderen en een nieuwe identity kolom aanmaken met identity. Je hebt dan weer een unieke key voor je rows, ... enz.

Om de rows terug in de nieuwe tabel te plaatsen kun je het ook zo doen:

code:

INSERT INTO nieuwe tabel (veld1, veld2, veld3, ...)
SELECT DISTINCT veld1, veld2, veld3 ... FROM oudetabel

Als je zegt dat alle rijen er dubbel inzitten, maar met een ander id selecteer je gewoon iedere rij in een distinct zonder dat je het id mee selecteert. SQL Server zal er wel voor zorgen dat ze in de nieuwe tabel een nieuwe key krijgen.

[Delphi32]

Op woensdag 29 mei 2002 22:50 schreef whoami het volgende:
Om de rows terug in de nieuwe tabel te plaatsen kun je het ook zo doen:

code:

INSERT INTO nieuwe tabel (veld1, veld2, veld3, ...)
SELECT DISTINCT veld1, veld2, veld3 ... FROM oudetabel

Ja, zou moeten werken. Dit trouwens ook:

code:

ALTER TABLE foutetabel SET IDENTITY_INSERT OFF;
INSERT INTO foutetabel (veld1, veld2, veld3, ...)
SELECT veld1, veld2, veld3 FROM foutetabel WHERE ID = (die dubbele);
DELETE FROM foutetabel WHERE ID = (die dubbele);

waarbij zij opgemerkt dat veld1, veld2 en veld3 NIET het identity-veld mogen zijn.

[TeeDee]

Hmm,

DISTINCT werkte ook niet helemaal goed, want volgnummer is niet altijd helemaal even uniek (weet ik, is een foutje!, maar toch).

Hoe nu gedaan?
Data geexporteerd naar Excel. "Ontdubbelt", en geimporteerd in een nieuwe table.

Tevens weet ik denk hoe het gebeurd kan zijn:
Er moest wel eens eerder data geimporteerd worden, alleen in een andere table (met dezelfde structuur). Vraag me niet waarom maargoed Ik denk dat er daar iets fout is gegaan. Maar dat verklaart nog niet waarom die Id er dan dubbel instaat.

Voor de liefhebbers: je kan het testen en je zult zien dat dat idd zo is.(als je Id op autoincr. hebt staan en nietop unique o.i.d

Thanks iig voor de hulp.
En ja, ik weet het, had het beter via een commando kunnen laten lopen, maar ik kwam er ff niet zo gauw op (ivm met die distinct en volgnummer) en we hebben hier toch professionele "ontdubbelaars" zitten.

[Annie]

Op donderdag 30 mei 2002 07:30 schreef TeeDee het volgende:
Voor de liefhebbers: je kan het testen en je zult zien dat dat idd zo is.(als je Id op autoincr. hebt staan en nietop unique o.i.d

[zonder te testen]
Tja, maar volgens mij heb je dan toch echt de identity_insert optie aangegeven bij de import.
[/zonder te testen]

[Verwijderd]

Kun je ook aub erbij vertellen hoe de records in de tabel zijn verschenen? Want als je een tabel in SQLServer aanmaakt met een identity PK en daarna records gaat inserten, is de key generation atomair en irreversable. Je kunt bv niet met 2 of meer users dezelfde keys genereren. Ook gaat de teller niet terug wanneer je records delete. Dit riekt naar een import van een blok data, daarna een veld als identity bombarderen of specifiek aan de constraint rommelen.

[TeeDee]

Op donderdag 30 mei 2002 09:58 schreef Otis het volgende:
Kun je ook aub erbij vertellen hoe de records in de tabel zijn verschenen? Want als je een tabel in SQLServer aanmaakt met een identity PK en daarna records gaat inserten, is de key generation atomair en irreversable. Je kunt bv niet met 2 of meer users dezelfde keys genereren. Ook gaat de teller niet terug wanneer je records delete. Dit riekt naar een import van een blok data, daarna een veld als identity bombarderen of specifiek aan de constraint rommelen.

Ik heb hem niet op PK gezet (volgens mij).
Data is geimporteerd.
Niet aan de constraint gerommeld en verder zelf niks als identity gebombardeerd.

Ik zei paar reply's hierboven al:
Als ik 1 van de dubbele records middels een sql delete verwijder, werden alle 2 de records verwijderd.

[whoami]

brakke tafel?

[TeeDee]

Denk het

Het is nu opgelost, en als ik tijd over heb ga ik uitzoeken hoe het is gekomen / kan.

Personal memo aan mezelf:
Goed opletten bij Import van Data