Opdatere produktionsmiljø

Replikering? Hvis den altså kan sættes op til kun at køre fra Udvikling til Produktionsmiljø. Og den skal sættes i gang manuelt.

Er der forskellige typer, ulemper, andre ting? - som er specifikt for min opgave?

Jeg ved det ikke. Jeg har ikke arbejdet med replikering selv, men for mig lyder det som noget, hvor det var en mulighed at se på replikering.

Udvikling skulle i givet fald sættes op som master, da det er masteren, som bestemmer datastruktur.

Men jeg kom lige i tanker om, om det kan lade sig gøre kun at replikere strukturen... Replikering er jo data...

Hej

Jeg er bange for at det nok er den rigtige måde at gøre det på. Jeg bruger selv denne metode men har samtidig integreret mine scripts med SourceSafe hvilket gør at jeg har noget mere styr på havd der er ændret og hvornår. Det er muligt at få SourceSafe til at integrer sig ind i Visual Interdev og på den måde også holde styr på ens Stored Proceduer

thefish: Dvs. du kopiere dine scripts og gemmer dem i SourceSafe?

Ja på en måde, jeg arbejder med udviklingen af databasen inde fra Interdev og bruger den til at chekke ændringer ind i SourceSafe

Det sker naturligvis ved at der gemmes en fil som herefter indlæses i VSS

Ja - men vil det sige, at du laver ændringer i databasen via InterDev. Og at du så kan bruge InderDev til at synkronisere med?

Yeps

Se også her:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql7/html/sql7storprocvers.asp

Replikering er IKKE måden at opdatere strukturen i et produktionsmiljø på. Uanset om du anvender snapshot, transactional eller merge replikering, er formålet rettet mod at distribuere og synkronisere DATA mellem flere servere og klienter.

Problemet er derfor først og fremmest, at der er en meget stor sandsynlighed for, at du kommer til at overskrive DATA i dit produktionsmiljø, hvilket er kritisk og i mange tilfælde direkte ulovligt (eks. økonomiske data). Derudover er replikering forholdsvis simpelt at konfigurere, men stort set umuligt at fejlsøge på, for slet ikke at tale om at fjerne igen.

Når - ikke hvis - du løber ind i problemer med replikering, ender du i stortset alle tilfælde med, at skulle rode med system parameterne, hvilket oftest kræver at du smider serveren i single user mode. Dette betyder så igen, at et replikeringsproblem i normal arbejdstid vil påvirke alle brugere af systemet.

Jeg anvénder selv alle typer replikering på både 7.0 og 2000 servere i flere lande. Og tro mig, der er ikke sket de store forbedringer i 2000 i.f.t. fejlsøgning, men det er dog blevet noget mere stabilt.

Den mest sikre metode er at scripte dig ud af problemerne og om muligt anvende VID som thefish foreslår. Jeg kombinerer disse og mener at det er den sikreste metode af alle.

Vær dog opmærksom på DROP i.f.m. scripting af dine ændringer. Hvis du er uheldig med dannelsen af dine scripts, vil du droppe objekterne på produktionsmiljøet, d.v.s. incl. data.

Dont intend looking at the current answer/comments so I may be repeating something here!
Your method of using the scripts generated by SQL Sever when you make your alterations in development IS in my opinion the CORRECET method and then you save these scripts in Source Safe so you have DOCUMENTATION as to what has been altered!

Du er vel nødt til at patche dig ud af problemet: Lave en (Midlertidig) tabel til produktionsdataene, læg produktionsdata herover, lav tabel om, + procedurer, inserts updates etc der bruger tabel, og så flytte produktionsdata tilbage. Kræver self at db er offline for en kort periode

roadrunr hows it going here?

When you make modifications SQL Sever quite often makes a newe table, copies the data from the original to the new, dletes the original and then finally ren-names the new, so WHY DO ALL THIS WORK YOURSELF?

Tak for jeres svar!