[MSSQL] Updates doorvoeren naar productie omgeving

[jelmervos]

Ik ben samen met een aantal collega's bezig met een Delphi applicatie. Hierbij zit tevens een MSSQL database voor de opslag van gegevens. Om de zoveel dagen doen wij een update naar de klanten. Nu is het zo dat de structuur van de database vaak wordt veranderd. Deze moeten wij nu handmatig aanpassen in de productie omgeving wat teveel tijd kost en te fout gevoelig is. Er komt bij dat er steeds meer klanten bij komen en dat het allemaal teveel tijd gaat kosten.

Nou was mijn vraag of het updaten van de structuur van een MSSQL database te automatiseren is via een SQL script oid. Zodat de klant het pakket zelf kan updaten.

[EfBe]

Kijk naar SQL-DMO. Dit is een COM library die je volledig in staat stelt alles met een sqlserver te doen. COM componenten kun je gebruiken in Delphi. Wat je dan kunt doen is een sqlscript genereren op jouw bak, dat script dan in een eigen geschreven, SQL-DMO gebruikend programma inlezen en de wijzigingen doorvoeren op de machine waarmee het programma dan verbonden is (bij jouw klant bv).

Je kunt ook een sqlscript naar je klant sturen en die voert het dan uit op de commandline oid via osql.exe, maar dat is weer wat spartaans

[ATS]

Als je zo'n sqlscript kan maken, dan kan je het ook zelf vanuit je programma via osql.exe. Gewoon starten als proces...

[jelmervos]

Het uitvoeren van SQL scripts is geen probleem, dat wordt toch al gedaan voor andere taken. Het gaat meer om het maken van het SQL script met de wijzigingen. Moet dit gewoon met de hand worden gedaan of is hier een betere (snellere) oplossing voor.

[EfBe]

Delphi schreef op 14 August 2003 @ 09:34:
Het uitvoeren van SQL scripts is geen probleem, dat wordt toch al gedaan voor andere taken. Het gaat meer om het maken van het SQL script met de wijzigingen. Moet dit gewoon met de hand worden gedaan of is hier een betere (snellere) oplossing voor.

Dat moet met de hand. Sqlserver houdt niet bij wanneer welke wijzigingen (bv welke columns zijn toegevoegd aan welke tables) hebben plaatsgevonden.

[zneek]

Ik denk dat je je af moet vragen of je wel goed bezig bent als je in een productie omgeving regelmatig het db ontwerp moet aanpassen. Dat er af en toe eens een veldje bijkomt, of een veld van type wijzigt kan ik inkomen, dat doen we hier ook. Maar als je database serieus wijzigt(relaties, gehele tabellen) is er wat mis denk ik. Maken jullie niet van te voren een ontwerp van de functies in de applicatie en de daarbij behorende database?

Daarnaast: is het niet een idee om 1 iemand verantwoordelijk te maken voor de database? Alle wijzigingen via die persoon te laten lopen, en die persoon alle wijzigingen middels DDL SQL Scripts te laten doen? Je krijgt dan namelijk een lijst van DDL commando's die je eigen ontwikkelomgeving wijzigt, en die je zo voor de productieomgeving kunt gebruiken.

[ Voor 29% gewijzigd door zneek op 14-08-2003 10:03 ]

[Verwijderd]

Ik denk niet dat het perse gaat om het geheel wijzigen van de database. Ik denk dat het sowieso goed is om al je wijzigingen, zowel klein als groot, te scripten. Op deze manier heb je altijd een history bij de hand en weet je zeker dat je productieomgeving een mirror van je ontwikkelingomgeving is.

En ja, het kost wat meer tijd maar dan heb je wel een solide onderhoudsmethode waar je mee aan kan komen bij je klanten.

[P_de_B]

Er is een tooltje 'SQLcompare' en er zullen ook nog wel andere zijn. Deze tooltjes kunnen precies wat je wilt. Ik zou even googlen als ik jou was.

[beetje offtopic]
Het is een goed idee alle wijzigingen in de db met scripts te doen, en deze scripts in Sourcesafe oid op te slaan. Zo heb je relatief eenvoudig sourcecontrol op je database.
[/beetje offtopic]

[jelmervos]

De database wordt nog wel es aangepast omdat wij volgens de eXtreme Programming methode werken. Dit blijft dus ook wel zo.

Het is idd slim om de wijzigingen apart te scripten en deze in de CVS te stoppen.

[zneek]

Wij zitten trouwens verder met hetzelfde probleem (ongeveer). Prog. code wordt netjes in CVS bijgehouden, alleen de wijzigingen in de database zijn lastig bij te houden. Hoe doe je dat netjes? Bij elke major version van de code in CVS een sql dump van je database maken en die ook in CVS pleuren? Of zijn er nettere (en beter te automatiseren) oplossingen voor?

[EfBe]

Delphi schreef op 14 August 2003 @ 10:39:
De database wordt nog wel es aangepast omdat wij volgens de eXtreme Programming methode werken. Dit blijft dus ook wel zo.

ARGh! .

Ik zal wel weer arrogant, betweterig of flamerig overkomen, maar wat is er gebeurd met gedegen datamodellen ontwerpen aan de hand van abstracte datamodellering? Sinds wanneer is dat 'minder' dan het ad-hoc aanpassen van datamodellen op tabel niveau?

Soms begrijp ik de mensheid niet.

[jelmervos]

EfBe schreef op 14 augustus 2003 @ 11:53:
[...]

ARGh! .

Ik zal wel weer arrogant, betweterig of flamerig overkomen, maar wat is er gebeurd met gedegen datamodellen ontwerpen aan de hand van abstracte datamodellering? Sinds wanneer is dat 'minder' dan het ad-hoc aanpassen van datamodellen op tabel niveau?

Soms begrijp ik de mensheid niet.

Een database is bij ons niet meer dan alleen de opslag voor de objecten. Als wij een stukje functionaliteit tevoegen maken we eerst de classes aan en vervolgens de UI en de opslag naar de database. Zo zit al onze logica in de classes en is de database + UI snel te vervangen. Het is ook moeilijk in te schatten hoe groot een project word (en dus de database), verder kan m'n baas te allen tijde functionaliteit toevoegen en kan hij het project bestempelen als "af".

Maar ik denk niet dat dit het juiste topic is om over XP te discusseren. Het probleem zoals wij het nu hebben heeft er verder ook weinig mee te maken. En het gaat me ook alleen om een degelijke oplossing. Ik denk ook dat we niet de enige zijn met dit probleem.

[ Voor 3% gewijzigd door jelmervos op 14-08-2003 13:52 ]

[Annie]

Het uitvoeren van de wijzigingen op de productie omgeving is normaalgesproken niet het probleem. Sla gewoon alle wijzigingen die je in de QA uitvoert ook op in een sql bestandje en als je via de EM werkt dan heb je de "Save change script" button in de design mode.
Verzamel alle sql bestandjes en voer ze uit op de database. Met een batch bestandje wordt dat helemaal simpel: (vergeef me de kleine foutjes, is uit de losse pols)

code:

for %%f in (*.sql) do osql -E -S servertje -i %%f

Het grote probleem is echter hoe je dit goed en gecontroleerd gaat uitvoeren. En hiervoor kan je zoals al eerder is gezegd beter 1 persoon verantwoordelijk maken.

Ik heb overigens SQLCompare wel eens geprobeerd, maar was niet zo te spreken over de kwaliteit/bruikbaarheid. Er wordt wel veel werk uit handen genomen, maar vertrouw a.u.b. niet blindelings op de gegenereerde scripts (tenzij je goede backups hebt en restoren je hobby is ).

[jelmervos]

Ah, Save Change Script, dat ziet er goed uit. En hoe zit het met Views? Of moet ik die gewoon in z'n geheel updaten.

[ Voor 26% gewijzigd door jelmervos op 14-08-2003 15:12 ]

[Annie]

Delphi schreef op 14 August 2003 @ 15:08:
En hoe zit het met Views? Of moet ik die gewoon in z'n geheel updaten.

De view openen, copy&paste in een sql bestand en CREATE vervangen door ALTER?

Voor views en sprocs werk ik zelf altijd in de QA, werkt imho net even wat fijner dan de EM en dan kan je gewoon je source opslaan als sql.

Voor views enzo kan je inderdaad ook gewoon bij een update van je productieserver de scripts laten genereren (inclusief drop object en object permissions) vanuit de EM. Dan heb je ze in een keer allemaal.

[jelmervos]

Bedankt, dit gaat wel lukken! Weer wat geleerd.