Kopiering/erstatning af data fejler i DTS

Har den bruger du benytter ret til at overskrive de eksisterende data - og til at afvikle en TRUNCATE TABLE ?

Prøv at erstatte de eksisterende objekter og se om det hjælper.

til trer: jeg burde have de rettigheder. logger på som sa. men det er interessant, at du siger det, for når jeg beder om at få detaljeret fejlen får jeg at vide, at TRUNCATE TABLE ikke kunne udføres på en tabel, fordi der er en foreign key. siger det dig noget?

til zedios: har jeg prøvet før. alt er oprettet via script. kørte script. prøvede igen. virker ikke. men tak.

tl trer: har prøvet igen. helt specifikt er ODBC-fejlen: Cannot truncate table [dbo.xxxxx] because it is being referenced by a FOREIGN KEY constraint.

Når du har fremmednøgler mellem 2 tabeller kan du ikke lave en trunkering i primærnøgletabellen hvis der er refererende data i fremmednøgle tabellen.

Eks: hvis du har en postnummer tabel kan du altså ikke lave en trunkering i den så længe der er en adresse hvori et postnummer indgår.

Løsningen er, at du sikrer rækkefølgen af tabeller manuelt fremfor at basere dig på wizardens rækkefølge (der faktisk kun laves udfra oprettelsestidspunktet).

En mulighed er naturligvis også at du forinden dropper alle fremmednøgler, flytter data og lægger fremmednøglerne på bagefter. Du risikerer så bare at du ikke kan lægge dem på - DTS giver nemlig ikke et tidstro billede af databasen, men tager hver tabel for sig, så ref. integritet er altså ikke garenteret.

Hvad sker der egentlig med den DTS? For jeg har oprettet samtlige tabeller. Data skal bare overskrives. Hvor kommer trunkeringen ind?
Dit eks. med postnummertabellen er meget relevant. Jeg har lige nu brug for en meget simpel operation. Jeg har en brugertabel. brugere kan have forskellige roller. så brugertabellen vil have et rolleid, som refererer til en rolletabel. når jeg vil opdatere navnene på rollerne (skal ændres), ændrer jeg først navnene på min udviklingsserver og vil derefter opdatere testserver. fejlen kommer der.
men for fremtiden vil jeg have brug for at overføre mange flere data. både den ene og den anden vej. jeg har brug for at opdatere mellem udv., test og produktion fremover. har før gjort det og løst det, men glemt hvad jeg gjorde. måske dumpede jeg fremmednøglerne, som du foreslår. har dem i et script, så problemet er til at overse, hvis det er det, der skal til. men vil gerne kende forklaringen. ved ikke nok om DTS til at vide det. så mange tak for hjælpen.

har lige et par supplerende spørgsmål.
1. når det er nye data, dvs. når jeg kopierer over i en tom tabel, får jeg samme fejl, men kan konstatere af data kommer over. hvorfor?
2. selvom jeg kun har markeret for overflytning af data, lyder meddelelser under overflytningen som om objekterne (tabellerne) også bliver flyttet over el. genskrevet? er egentlig bare en del af spørgsmålet om, hvad DTS laver.

Ikke at jeg kender vildt meget til DTS - generelt vil jeg anbefale at udgå at benytte det hvis man har et alternativ!

Det jeg har fundet ud af er, at DTS er ikke specielt smart; Når du vælger at overskrive eksisterende data bliver der udført en trunkering - åbenbart uanset om der er data i tabellen eller ej. Og TRUNCATE TABLE kan ikke udføres på tabeller der har constraints (fremmednøgler) - se Books Online. Fordelen ved slavisk at trunkere er, at alt kan foretages som INSERTs fremfor en blanding af INSERTs og UPDATEs.

DTS gør faktisk det, at den tager samtlige tabeller i oprettelses-rækkefølge, disabler constraints, trunkerer tabeller, flytter data for hver tabel enkeltvis (dvs at alle tabeller ikke læses og flyttes som en enkelt transaktion, men som en transaktion pr tabel) og lægger constraints på igen. 

Dvs den forsøger ikke at opløse et fremmednøgle-hierarki og efter flytning kan man komme ud for, at der ikke længere er referentiel integritet i databasen.  DTS har så også haft problemer med mange lange rækker - det skulle vist være løst nu efter SP2, men... jeg stoler personligt ikke helt på DTS...

Mere kan jeg nok ikke rigtig byde på med forklaring om DTS... Du vil kunne finde noget - whitepapers etc - på www.microsoft.com/sql

Tak for svaret og info om, hvordan jeg kommer videre. Jeg kan se, at det gør hvordan jeg kan løse det.

Hmm - tillader at smide et svar nu - og vil slutteligt foreslå at du laver en løsning hvor du selv styrer sletning og flytning af data via go' gammeldags SQL du afvikler i rækkefølge der tillader fremmednøglerne.

a la

begin transaction
delete from target.dbo.adresseliste
delete from target.dbo.postnummer
insert into target.dbo.postnummer
select * from source.dbo.postnummer
insert into target.dbo.adresseliste
select * from source.dbo.adresseliste
commit transaction

Hej

Jeg laver nok en blanding afhængig af situationen. Tak for hjælpen.