[mssql] dump een database naar insert statements via cli

[daft_dutch]

Ik ben opzoek naar een tool om een sql server (mssql) database te exporteren naar insert statements via de cli. zodat ik hier van delen kan gebruiken voor auto deployment ten behoeven van test automatisering

wat ik gevonden heb maar niet happy over ben:
http://vyaskn.tripod.com/code.htm#inserts
sql versie afhankelijk, draait niet onder 2012 en nog een paar issues..

toen kwam ik mssqldump tegen

http://www.ipserverone.in...-database-with-mssqldump/
dat lijkt erg op wat ik wil maar krijg een fout melding

code:

MsSqlDump.exe -S pe04-main -D BDBtest  -U mssqldump -P mssqldump  -insertdata 
Error(0x81005001):Can not create SQL Server COM object!

weet/kent iemand een mysqldump achtig tool voor windows/sql server. Of weet waarom het bovenstaande programma uit de COM vliegt?

[ Voor 5% gewijzigd door daft_dutch op 25-09-2015 12:20 ]

[CMD-Snake]

daft_dutch schreef op vrijdag 25 september 2015 @ 12:19:
Ik ben opzoek naar een tool om een sql server (mssql) database te exporteren naar insert statements via de cli. zodat ik hier van delen kan gebruiken voor auto deployment ten behoeven van test automatisering

wat ik gevonden heb maar niet happy over ben:
http://vyaskn.tripod.com/code.htm#inserts
sql versie afhankelijk, draait niet onder 2012 en nog een paar issues..

toen kwam ik mssqldump tegen

http://www.ipserverone.in...-database-with-mssqldump/
dat lijkt erg op wat ik wil maar krijg een fout melding

code:

MsSqlDump.exe -S pe04-main -D BDBtest  -U mssqldump -P mssqldump  -insertdata 
Error(0x81005001):Can not create SQL Server COM object!

weet/kent iemand een mysqldump achtig tool voor windows/sql server. Of weet waarom het bovenstaande programma uit de COM vliegt?

Welke versie van SQL Server draai je? Dat is wel handig om te weten. Vanaf 2005 hebben alle SQL Server versies SQLCMD als CLI tool, maar nieuwere versies kunnen ook met Powershell werken.

Voro wat betreft je wens, je kan via SSMS een INSERT INTO script maken, dat staat hier beschreven. Je kan via SQLCMD ook een dump maken, zoals hier beschreven. Je krijgt als output een CSV file die je met bcp weer in kan lezen dan.

Persoonlijk zou ik niet een database als insert statement willen hebben. Het is veel efficienter om een full back-up te maken en die te kopiëren en vervolgens te herstellen. Voor een testomgeving maakt het weinig uit als de database overschreven wordt.

Je kan in ieder geval SQLCMD.exe gebruiken om via commandline T-SQL query's te draaien. Dan zou je een back-up kunnen maken. Dat werkt al vanaf SQL Server 2005.

Je zou ook via PowerShell dit kunnen doen. Zie hier dit blog compleet met script.

Alternatief als je wil dat bijvoorbeeld je testomgeving elk weekend ververst moet worden met data uit productie dan kan je ook via de SQL Agent een job maken om de database over te zetten. Dan automatiseer je het proces ook.

Er is vreselijk veel mogelijk, maar wat de meest passende oplossing is ligt aan wat je precies wil doen en welke versie van SQL Server je draait.

[daft_dutch]

bedankt voor je andwoord

CMD-Snake schreef op vrijdag 25 september 2015 @ 13:07:
Welke versie van SQL Server draai je? Dat is wel handig om te weten. Vanaf 2005 hebben alle SQL Server versies SQLCMD als CLI tool, maar nieuwere versies kunnen ook met Powershell werken.

SQL Server <what ever> (van sql express 2005 tot 2014 enterprise)

Voro wat betreft je wens, je kan via SSMS een INSERT INTO script maken, dat staat hier beschreven. Je kan via SQLCMD ook een dump maken, zoals hier beschreven. Je krijgt als output een CSV file die je met bcp weer in kan lezen dan.

thanks hier zal ik naar kijken. of het inserts of CSV zijn moet niet zo veel uit maken.

Persoonlijk zou ik niet een database als insert statement willen hebben. Het is veel efficienter om een full back-up te maken en die te kopiëren en vervolgens te herstellen. Voor een testomgeving maakt het weinig uit als de database overschreven wordt.

dat is zeker een no go. heb ik straks 160 database back-ups. Die bij een nieuwe versie X totaal waarde loos zijn daarbij wil ik de database stukje bij beetje uitbreiden.
installatie -> deployment -> minimate db inserts -> smoke test -> db inserts -> regressie testen / boundary testen -> db inserts -> enz enz enz

[...]
Alternatief als je wil dat bijvoorbeeld je testomgeving elk weekend ververst moet worden met data uit productie dan kan je ook via de SQL Agent een job maken om de database over te zetten. Dan automatiseer je het proces ook.

dat is zeker een doel voor de toekomst, zeker omdat productie een factor 200 heeft.
maar daarvoor weer graag inserts die je (automatisch) kan bewerken. met betrekking tot bescherming persoonsgegevens en zo.

[CMD-Snake]

daft_dutch schreef op vrijdag 25 september 2015 @ 13:47:
SQL Server <what ever> (van sql express 2005 tot 2014 enterprise)

SQL Server 2005 is end of life. Ik zou daar niet meer voor ontwikkelen eerlijk gezegd.

dat is zeker een no go. heb ik straks 160 database back-ups. Die bij een nieuwe versie X totaal waarde loos zijn daarbij wil ik de database stukje bij beetje uitbreiden.
installatie -> deployment -> minimate db inserts -> smoke test -> db inserts -> regressie testen / boundary testen -> db inserts -> enz enz enz

Ik zie niet direct hoe je bij 160 back-ups komt. Je maakt gewoon van een database een back-up en je zet die neer in je testomgeving. Dan kan je daarna meteen al je testjes doen. Gaan knippen en plakken in die CSV's of in zo'n insert script kan voor gekke effecten zorgen. De relaties tussen data in de tabellen kan dan kapot gaan.

dat is zeker een doel voor de toekomst, zeker omdat productie een factor 200 heeft.
maar daarvoor weer graag inserts die je (automatisch) kan bewerken. met betrekking tot bescherming persoonsgegevens en zo.

Na een volledige restore kan je ook scripts draaien meteen die de boel anonimiseren of zaken verwijderen. Dit is netter dan editen in bestandjes omdat je dan zeker weet dat je aan alle constraints blijft voldoen.

[daft_dutch]

CMD-Snake schreef op zaterdag 26 september 2015 @ 15:39:
[...]


SQL Server 2005 is end of life. Ik zou daar niet meer voor ontwikkelen eerlijk gezegd.


[...]


Ik zie niet direct hoe je bij 160 back-ups komt. Je maakt gewoon van een database een back-up en je zet die neer in je testomgeving. Dan kan je daarna meteen al je testjes doen. Gaan knippen en plakken in die CSV's of in zo'n insert script kan voor gekke effecten zorgen. De relaties tussen data in de tabellen kan dan kapot gaan.


[...]


Na een volledige restore kan je ook scripts draaien meteen die de boel anonimiseren of zaken verwijderen. Dit is netter dan editen in bestandjes omdat je dan zeker weet dat je aan alle constraints blijft voldoen.

zucht ik moet in detail treden.

Ik ben geen ontwikkelaar ik ben een tester. Ik test geen software ik test oplossingen voor de klant.
SQL Server 2005 draait bij klanten. Als ik dat nu buiten scoop trek levert dat later weer issues op bij bijvoorbeeld een upgrade testen.

200 is een heel klein getal, als je een klein dimensioneel object van 4^4 plat slaat heb je al 256.
Ik zet nu al databases terug waarna ik een hele tijd kwijt mijn test environment (lees hardware) aan te passen aan de klant omgeving.

Dit is niet de eerste keer dat ik test automatie ga doen. probleem hier is dat de configuratie zo divers is.
Mijn eerste keer was het een BPM oplossing die op heel veel verschillende OSen en Databases kon draaien maar daarna universeel was voor elke klant omgeving. omdat BPM universeel is voor elk bedrijf.
dat werd een
installeer "wat ever versie" op "wat ever" OS op wat "ever VM/Metal" met eventueel een "wat ever database" op een "wat ever" locatie.
maak een snapshot. (mits de applicatie server geen Windows OS is op een stuk metaal)
doe de smoke test.
installeer alle payloads
doorloop alle tests.
en maak waarom niet nog een snapshot.

Simpel, simpel omdat in stap 1 alle dimensies gecrushed zijn. Nu niet omdat de configuratie zo bepalend is.

ik ga wel de inserts die tijdens het configureren via de website tracen in na spelen. Daarna wel een scriptje maken om per configuratie 1 sql insert script te maken. als het met die csv's niet lukt.
Ja. selenium heb ik al geprobeerd, ja. ik heb ervaring met selenium, Nee. te complex en duurt te lang.