[SQL] INSERT INTO probleem

[Verwijderd]

Ik heb een access database geupsized naar SQL server 2000
Na het upsizen zijn er in de SQL server database veel wijzigingen aangebracht. (In relaties, indexen enz)
In de struktuur dus geen wijzigingen gemaakt

Om alle klanten die nog de access database gebruiken ook over te laten stappen op SQL server heb ik in access een nieuwe db gemaakt waarin ik een koppeling gemaakt heb naar alle tabellen van de te converteren acccess database, en een ODBC naar deSQL server database (die ik eerst weer leeg heb gemaakt)

Vervolgens heb ik voor elke tabel een toevoegquery gemaakt die alle waarden inclusief de ID (primary key) overzet in de nieuwe SQL server tabellen.

Het is namelijk van belang dat als ik bijvoorbeeld de tabel tblEmployees overzet, dat elke Employee zijn eigen EmployeeID behoudt. Het blijkt dat ondanks dat in SQL server voor het veld EmployeeID de eigenschap IDENTITY is aangezet je toch met zo'n toevoegquery deze ID's zelf in kunt vullen!

Wat wil nu het geval?

Het gaat goed bij de eerste tabel.

Bij het starten van de toevoegquery voor de tweede tabel krijg ik direct een foutmelding:

Niet alle records kunnen worden toegevoegd ... 9 records ten gevolge van sleutelconflicten (de hele tabel bestaat uit g records, en hij heeft dus niks toegevoegd)

Maar het allergekste komt nog: Als ik acces afsluit en weer opstart en vervolgens de query weer start dan wil het ineens wel!!

dus ga ik vrolijk naar de derde query: Weer die foutmelding.

Dus weer access afsluiten en weer opstarten, en het wil weer.

Ik kan dus steeds 1 query doen. Wel heel irritant omdat het meer dan 50 tabellen zijn, en ik nog heel wat klanten moet doen!

Weet iemand waar dit aan zou kunnen liggen??

[bigtree]

Verwijderd schreef op 30 August 2003 @ 15:01:
Het is namelijk van belang dat als ik bijvoorbeeld de tabel tblEmployees overzet, dat elke Employee zijn eigen EmployeeID behoudt. Het blijkt dat ondanks dat in SQL server voor het veld EmployeeID de eigenschap IDENTITY is aangezet je toch met zo'n toevoegquery deze ID's zelf in kunt vullen!

Dit kun je per tabel toestaan/tegengaan met de optie IDENTITY_INSERT. Let op; er kan maar één tabel per sessie zijn waar de optie 'ON' staat, zie document.

[...]
Bij het starten van de toevoegquery voor de tweede tabel krijg ik direct een foutmelding:

Niet alle records kunnen worden toegevoegd ... 9 records ten gevolge van sleutelconflicten (de hele tabel bestaat uit g records, en hij heeft dus niks toegevoegd)

Kan je achterhalen of het om een unique key gaat of het ontbreken van een achterliggend record in een andere tabel?

[Verwijderd]

bigtree schreef op 30 August 2003 @ 16:30:
[...]
Dit kun je per tabel toestaan/tegengaan met de optie IDENTITY_INSERT. Let op; er kan maar één tabel per sessie zijn waar de optie 'ON' staat, zie document.

Klopt, maar ik ben er zojuist achter gekomen dat als ik net de query voor tblEmployees gestart heb, en hij heeft bijvoorbeeld 10 employees gekopieerd naar de SQL server tabel, inclusief de ID! (terwijl dit dus een identity kolom is), dan kan ik direct daarna niet handmatig in deze gekoppelde tabel een employee meer toevoegen.
Dit kon direct voor het starten van de query wel gewoon. Hij autonummerde het veld dan gewoon vanzelf.
En inderdaad is dit ID veld gewoon de primary key, maar ook al zijn er verder geen relaties, de fout blijft wel verschijnen!

Ik krijg als foutmelding:

ODBC insert on a linked table failed
Explicit value must be specified for identity column in table tblEmployees when IDENTITY_INSERT is set to ON

Blijkbaar zet access deze eigenschap voor deze tabel vanzelf op ON bij het starten van een toevoegquery.
Maar hij vergeet hem dus weer op OFF te zetten!
Ik kan dit trouwens vanuit access zelf niet aan of uit zetten, omdat access alleen simpele INSERT en UPDATE enzo ondersteund.

Dit verklaard ook waarom ik maar 1 tabel steeds kan doen, omdat deze eigenschap maar voor 1 tabel aan kan staan

Als iemand dus nog een goeie tip heeft hoe ik het dan wel op kan lossen houd ik mij aanbevolen!

[ Voor 7% gewijzigd door Verwijderd op 30-08-2003 16:43 ]

[bigtree]

Verwijderd schreef op 30 August 2003 @ 16:41:
[...]
Als iemand dus nog een goeie tip heeft hoe ik het dan wel op kan lossen houd ik mij aanbevolen!

Er zijn vele wegen die naar Rome leiden:

- Tijdelijk opheffen van de restricites in het datamodel in SQLServer. Eventuele inconsistenties komen bij het opnieuw toepassen van de restricties wel weer naar voren.
- Import wizard van de enterprise manager gebruiken om data naar tijdelijke tabellen te kopieren en via query analyser naar de uiteindelijke doeltabellen te kopieren (vanuit de query analyser kan je wel de IDENTITY_INSERT controleren)
- Linked server maken naar je access database. Hiermee doe je in feite het omgekeerde van wat je nu doet. Gekoppelde tabellen, maar dan vanuit SQL server in plaats van andersom. Daarmee kan je wederom via de query analyser je data overpompen. Zoek hiervoor even in de manual op 'linked server' en 'OPENQUERY'.
- Google laten zoeken naar een stap-voor-stap migratie-handleiding.