De situatie
Ik heb een Access-database die gedeeltelijk geconverteerd moet worden naar een bestaande SQL Server 2000-database. De data zou in eerste instantie naar een bestaande Access-database gaan, waarvoor de conversie al was geschreven in een mdb-file waarin zowel de oude als de nieuwe tabellen werden gekoppeld. De conversie wordt voor een groot deel uitgevoerd door queries.
Nu is de situatie echter gewijzigd, en is de doel-database geen Access maar SQL Server 2000. De brondatabase blijft wel Access.
De conversie / techniek
De conversie wordt gerund vanuit VBA, waarin achtereenvolgens een aantal queries worden uitgevoerd, bijvoorbeeld:
Standaard-gedrag van een Access-insertquery is dat je de Identity in een Access-tabel kunt overrulen. Van die 'feature' wordt in deze conversie gebruik gemaakt.
Na de migratie naar SQL Server heb ik de tabellen van SQL Server via ODBC in de conversie-database gelinkt. Dit werkt op zich prima, alleen bovengenoemde feature niet.
Het probleem
Ik kan nu dus geen gebruik meer maken van de 'feature' voor het overrulen van de identity.
Dit dacht ik op te lossen door te werken met de IDENTITY_INSERT, op de volgende manier:
sqlConnection werkt niet in een transaction, dus de SET wordt direct uitgevoerd.
Echter, bovenstaande methode werkt niet. Ik krijg een foutmelding op de query, ivm de Identity (duplicate keys)
Het vreemde is echter, als ik in de queryanalyzer de identity_insert uitschakel, met exact hetzelde SQL-statement, en dan de DoCmd.OpenQuery uitvoer, werkt het wel!
In alle gevallen (gekoppelde tabellen in Access, ADO connection, Query Analyzer) wordt gebruik gemaakt van een TrustedConnection, dus alles dezelfde user.
Samenvatting probleem
Een SET IDENTITY_INSERT via de QueryAnalyzer werkt wel, maar niet als deze wordt uitgevoerd door een ADODB-connection object.
Reeds gevonden mbt dit probleem:
http://support.microsoft.com/default.aspx/kb/253157 - Heeft betrekking op SQL Server 7. 2000 wordt hier niet genoemd, dus ik ga ervanuit dat het voor 2000 niet geldt (gezien de datum van het artikel)
Ik kom soms suggesties tegen dat de SET maar voor één thread werkt, maar dat blijkt dus niet zo te zijn. De SET via QA, gecombineerd met de query vanuit Access werkt immers wel, terwijl dat verschillende connections zijn (de query gaat zelfs via ODBC).
Hopelijk is er hier iemand die ervaring heeft met dit probleem of een zinnige suggestie heeft?
Ik heb een Access-database die gedeeltelijk geconverteerd moet worden naar een bestaande SQL Server 2000-database. De data zou in eerste instantie naar een bestaande Access-database gaan, waarvoor de conversie al was geschreven in een mdb-file waarin zowel de oude als de nieuwe tabellen werden gekoppeld. De conversie wordt voor een groot deel uitgevoerd door queries.
Nu is de situatie echter gewijzigd, en is de doel-database geen Access maar SQL Server 2000. De brondatabase blijft wel Access.
De conversie / techniek
De conversie wordt gerund vanuit VBA, waarin achtereenvolgens een aantal queries worden uitgevoerd, bijvoorbeeld:
Visual Basic:
1
2
3
| DoCmd.OpenQuery "01 VOrder" DoCmd.OpenQuery "02 VOrderRegel" 'etc. |
Standaard-gedrag van een Access-insertquery is dat je de Identity in een Access-tabel kunt overrulen. Van die 'feature' wordt in deze conversie gebruik gemaakt.
Na de migratie naar SQL Server heb ik de tabellen van SQL Server via ODBC in de conversie-database gelinkt. Dit werkt op zich prima, alleen bovengenoemde feature niet.
Het probleem
Ik kan nu dus geen gebruik meer maken van de 'feature' voor het overrulen van de identity.
Dit dacht ik op te lossen door te werken met de IDENTITY_INSERT, op de volgende manier:
Visual Basic:
1
2
3
| sqlConnection.Execute "SET IDENTITY_INSERT dbo.[VOrder] ON" DoCmd.OpenQuery "01 VOrder" sqlConnection.Execute "SET IDENTITY_INSERT dbo.[VOrder] OFF" |
sqlConnection werkt niet in een transaction, dus de SET wordt direct uitgevoerd.
Echter, bovenstaande methode werkt niet. Ik krijg een foutmelding op de query, ivm de Identity (duplicate keys)
Het vreemde is echter, als ik in de queryanalyzer de identity_insert uitschakel, met exact hetzelde SQL-statement, en dan de DoCmd.OpenQuery uitvoer, werkt het wel!
In alle gevallen (gekoppelde tabellen in Access, ADO connection, Query Analyzer) wordt gebruik gemaakt van een TrustedConnection, dus alles dezelfde user.
Samenvatting probleem
Een SET IDENTITY_INSERT via de QueryAnalyzer werkt wel, maar niet als deze wordt uitgevoerd door een ADODB-connection object.
Reeds gevonden mbt dit probleem:
http://support.microsoft.com/default.aspx/kb/253157 - Heeft betrekking op SQL Server 7. 2000 wordt hier niet genoemd, dus ik ga ervanuit dat het voor 2000 niet geldt (gezien de datum van het artikel)
Ik kom soms suggesties tegen dat de SET maar voor één thread werkt, maar dat blijkt dus niet zo te zijn. De SET via QA, gecombineerd met de query vanuit Access werkt immers wel, terwijl dat verschillende connections zijn (de query gaat zelfs via ODBC).
Hopelijk is er hier iemand die ervaring heeft met dit probleem of een zinnige suggestie heeft?
[ Voor 4% gewijzigd door BertS op 13-01-2006 10:05 ]
:strip_exif()/u/26499/avatarRHCP6060.gif?f=community){kind=avatar}
