synkronisere XML dokumenter med SQL-server engang om dagen

8000 poster er ikke særlig meget - men du bør nok i stedet lave en import-tabel (en indbakke) hvori du lægger de importerede data. Derefter kan du køre UPDATE statements på din rigtige tabel udfra data i indbakken.

Dermed har du heller ingen problemer med relationer til andre tabeller og evt. primærnøgler forbliver uændredede.

Dvs. at jeg skal lave en ny database med de samme tabeller, hvor jeg så impotere alle data til, og derefter synkronisere jeg data mellem de 2 database med det værktøj der hedder Replication?

Det er nok at lave et par nye tabeller i den eksisterende database.

Og det indbyggede replikationsværktøj er rimelig svært at benytte korrekt + det laver ændringer i tabellerne for at kunne køre. At benytte det er at skyde langt over målet. I stedet bør du blot skrive de få SQL Update statments som skal fyres af.

Undskyld jeg først vender tilbage nu men jeg har været lidt optaget af at lave front-end.

Jeg er ikke helt med på den løsning du forslår.

Jeg har ca. 8 tabeller i min database, så jeg forstår ikke helt hvorfor jeg kun skal oprette 2 midlertidige tabeller.

Jeg ved heller ikke rigtig noget om at synkronisere 2 tabeller med sql-sætninger.

Såfremt du kun laver ændringer i den ene tabel, så er det ikke svært at synkronisere.

Du kan lave 3 triggere på hver tabel du vil replikere, en for INSERT, en for DELETE og en for UPDATE. Disse triggere skriver de ændrede data ned i din udbakke, og så skal du blot transportere udbakken over til mål-databasen hvor du hælder data ind.

Hvis dine data egner sig til det, så kan du endda lade dine triggere skrive sql-statements direkte.

Ex

create trigger myinstrigger on mytable
for insert
as
  insert into udbakke
  select 'insert into mytable values('+col1+','+col2+')'
  from inserted
go

create trigger mydeltrigger on mytable
for delete
as
  insert into udbakke
  select 'delete from mytable where id='+id
  from deleted
go

create trigger myupdtrigger on mytable
for update
as
  insert into udbakke
  select 'update mytable set col1='+col1+', col2='+col2+' where id='+id
  from inserted
go

sådanne triggere lægger du på alle de tabeller du vil replikere, og vupti, din udbakke fyldes med sql statements som genskaber ændringerne. Minuset er, at der er et overhead, så med en svag server eller krav om ekstrem ydelse går det ikke.

Data smider du så i indbakken på målserveren, og her lægger du en trigger på der afvikler sql-udtrykkene og sletter dem efterfølgende.

Jeg ved ikke noget om trigger, så jeg bliver nødtil at spørge lidt mere (Håber det er iorden?)

Jeg er ikke helt med på det med at lave en "indbakke". Jeg har 8 tabeller med forskellige strukture der alle skal synkroniseres med xml filer. Skal jeg så tage en xml fil afgange og fylde ind i indbakke, men hvordan får jeg den til at passe ind med hensyn til datatyper?

Indbakken er blot en tabel.

Triggere er noget kode der afvikles af sql server når en transaktion slutter - dvs. efter et update, insert eller delete statement.

Og med ovenstående triggere vil skal indbakken bestå af et tekstfelt.

Er du tvunget til at benytte XML?

XML er ikke nødvendigvis den smarteste løsning og med stor sikkerhed den langsomste - men du kan kigge i Books Online (installeret sammen med dine sql server client tools - enterprise manager og query analyzer) for hvordan du benytter XML direkte i SQL.  Bemærk at du er begrænset i hvor store XML sider du kan indlæse - umiddelbart husker jeg det som 8 eller 64 KB.

Hvilket format vil du ellers anbefale impotere fra?

Der er masser af muligheder :

Det bedste er at pumpe data direkte mellem de to databaser - DTS er en letvægtsløsning som datapumpe, men rigeligt i dit tilfælde, og der findes adskillige professionelle løsninger (Powermart, Datastage mv) som man bør vælge ved større systemer.

XML er meget fint - men sql server har begrænsninger i hvor store xml dokumenter den kan fortolke. Der er dog visse datatyper som giver problemer i XML, og SQL Server har lidt problemer med memory leaks sammen med XML plus fortolkningen af dem er langsom.

CSV er de go'e gamle komma-separerede filer. Der er masser af mulige problemer i de format - bl.a. er tekststrenge der indeholder linjeskift et stort problem.

MDB - en Access database - kan man oprette direkte via DTS og bruge som mellemlagring når man flytter data mellem systemer. MDB filer har nogle svagheder - men de er rimeligt stabile til den her slags brug - og der er stort set ingen datatyper der giver problemer.

Min løsning med triggers skitseret ovenfor ville generere en tabel hvor du blot skulle dumpe inputtet ud til en script fil (et sql script) du blot kørte på mål-databasen.

trer: Du skal have tusind tak for hjælpen!!

Der går lige et par uger inden jeg beslutter mig endeligt for en løsning, også kan det være jeg vender tilbage.

Endnu engang mange tak for hjælpen!!