Create TABLE - als "Rückgabewert"

Question

Ich habe ja die Möglichkeit ein Script Create Table in der MSSQL Managament STudio zu erstellen

kann  ich dieses auch irgendwie als Rückgabewert eines SQL strings oder Funktion generieren?

Hintergrund ist das ich 2 MSSQL Datenbanken via VBA vergleiche und wenn die Tabelle x in y nicht vorhanden ist möchte ich diese mit Create Table erstellen - oder denke ich da falsch

Answer 1

...

kann  ich dieses auch irgendwie als Rückgabewert eines SQL strings oder Funktion generieren?

Hintergrund ist das ich 2 MSSQL Datenbanken via VBA vergleiche und wenn die Tabelle x in y nicht vorhanden ist möchte ich diese mit Create Table erstellen - oder denke ich da falsch

Den ersten Teil verstehe ich nicht. Inwiefern "als Rückgabewert definieren"?

Der 2. Teil ist schon klarer.

Wenn Tabelle X in "Detanbank Y" (denke ich ist gemeint) nicht vorhanden ist (warum auch immer), dann lege sie erst an.-> Ja, man kann innerhalb einer Prozedur ein Create Table ausführen. Um unnötige Recompilation zu vermeiden, würde ich das in eine 2. Prozedur auslagern. Aber so oder so geht es.

---

Andreas Wolter | Microsoft Certified Master SQL Server

Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 2

Ok wohl schlecht beschrieben.

Ich habe zwei Datenbanken mit Tabellen

die eine Datenbank ist die "Masterdatenbank" die zweite Datenbank liegt irgendwo beim Kunden

wenn ich beim Kunden bin vergleiche ich via VBA meine Masterdatenbank Struktur mit der Kundendatenbank

das Ergibniss sind dann neue Felder und Tabellen und Indizes... dann möchte ich über VBA einen Create Table String absetzen (was auch geht) aber diesen nicht selber zusammenstellen sondern am liebsten aus der Masterdatenbank einen Create Table String generieren können - aber eben auf Fuktionsebene oder Procedurebene...

Eben so als wenn ich im MSSQL Managmanet Studio auf Tabelle Rechtsklick mache und einen Create Table Script generiere

Answer 3

...

Ich habe zwei Datenbanken mit Tabellen

die eine Datenbank ist die "Masterdatenbank" die zweite Datenbank liegt irgendwo beim Kunden

wenn ich beim Kunden bin vergleiche ich via VBA meine Masterdatenbank Struktur mit der Kundendatenbank

das Ergibniss sind dann neue Felder und Tabellen und Indizes... dann möchte ich über VBA einen Create Table String absetzen (was auch geht) aber diesen nicht selber zusammenstellen sondern am liebsten aus der Masterdatenbank einen Create Table String generieren können - aber eben auf Fuktionsebene oder Procedurebene...

Eben so als wenn ich im MSSQL Managmanet Studio auf Tabelle Rechtsklick mache und einen Create Table Script generiere

Pardon, hatte mich eben verklickt..

Also für mich klingt das irgendwie "seltsam".

Mal abgesehen von der reinen Technik, auf die ich gleich komme, frage ich mich: wie sehen hier die Prozesse aus?

Wenn die Master-DB bei Dir ist, und der Kunde sozusagen eine "Alte Version", sagen wir beispielsweise V1.2 hat, dann würde man alles, was seit "Version V 1.2" an Änderungen gekommen ist, doch gleich bei sich in Form von ALTER und CREATE Scripten aufbewahren (können), und bräuchte nur die Versionsnummer zu vergleichen.

Bei dem Vorgehen hier oben, sehe ich ein Risiko, das der Kunde eigene Änderungen durchführt, und man diese dann vielleicht übersieht oder fälschlich als seine eigenen identifiziert. Da müsste man schon bis herunter auf die letzte Property (also Spalte - Datentyp - extended Properties) vergleichen, um wirklich einigermaßen sicherzugehen - mal abgesehen davon, das dann auch noch Daten in diesen Tabellen sein können.

Das würde ich wirklich noch mal Überdenken.

Also in meinen Augen wäre das viel zu riskant. Aber vielleicht ist es auch gar nicht so, und ich missverstehe es nur.

Ansonsten gibt es in Visual Studio for Database-Professionals auch eine "Schema-Compare"-Funktionalität, die dafür schon eher empfehlenswert ist. (aber auch nicht immer)

Prinzipiell: Man kann so ein "Change Schema-Script" aus .Net generieren, allerdings ist das eine Methode (?) der Funktion, wenn man alle Attribute beisammen hat. Alsop genau das, was SSMS eben auch tut. Den Namen der Methode kenne ich nciht, sollte aber leicht zu finden sein, wenn man die Funktionen vor sich hat.

---

Andreas Wolter | Microsoft Certified Master SQL Server

Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 4

Also, ich finde Deine Vorgehensweise auch nicht gerade optional. Das hört sich etwas danach an, als würdest Du Dir über SSMS alle möglichen Änderungen zusammenklicken, weißt aber am Ende dann selbst nicht mehr, was Du geändert hast.

Besser ist es alle Änderungen per ALTER Scripte vorzunehmen, dann weiß man zumindest, was man tut. SSMS kann Dir diese Änderungsscript übrigens auch generieren, der Button dazu ist in jedem der Designer vorhanden.

Eine Option ist auch SSDT = SQL Server Data Tools zu verwenden, das Tool ist von MS frei verfügbar. Das generiert Dir auch bei jeder Änderung ein Update Script.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 5

Eigentlich wollte ich nur eine Tabellenstrucktur (ohne Daten) von einer in die andere Datenbank kopieren.

da ich über eine ADODB.Connection Verbindung zu beiden Datenbanken aufnehmen kann hatte ich gedacht das das am einfachsten ist.

Kundenspezifische Daten liegen in einer gesonderten Datenbank - also kein thema

Answer 6

Hallo Michael,

wie bei der früheren Frage geschrieben - und aus den anderen Antworten ebenso klar werden dürfte, ist das nicht so trivial zu realisieren.

Wenn Du eine Tabelle verändern willst, so geht das auf zwei Wegen:

1. Eine neue Tabelle via CREATE TABLE erzeugen und die Daten der alten übernehmen.
2. Änderungen via ALTER TABLE vornehmen - wobei das nicht in allen Fällen möglich ist (und 1.) dann greift.

In beiden Fällen sind Beziehungen zu anderen Tabellen wie Fremdschlüssel zu berücksichtigen. Auch Dinge wie Trigger könenn einen Einfluss haben (und müssen ggf. deaktiviert / geändert werden).

Zum zweiten: Wenn Du eine Software hast, die sich etwas schneller ändert als alle Kunden (vorausgesetzt es gibt mehr als einen) mitmachen, kommt man zu dem Punkt, dass Änderungen je Version verwaltet werden müssen. Auch kundenspezifische Anpassungen können das Ganze deutlich verkomplizieren.

Nur via Code kommt man generell sehr schnell an einen Punkt, wo es einfach nicht mehr geht bzw. ein großes Unterfangen ist, dass mehrere Monate kostet (und ich glaube kaum, dass Du soviel Zeit ein "Tool" stecken willst).

SSMS kann zwar Änderungsskripte generieren, wenn man seine Änderungen darüber erstellt. Es wird bei mehreren / überschneidenden Änderungen aber schnell unhandlich und erfordert viele manuelle Abgleiche und gute Kenntnisse in SQL über ein bloßes CREATE TABLE hinaus.

Die hier bereits genannten SQL Server Data Tools können das zum Teil besser automatisieren. Oder aber käufliche Produkte wie im vorherigen Thread angedeutet (und testen geht dort auch). Beides kostet Einarbeitung, kommt aber i. a. deutlich billiger => fehlerhafte Migrationen machen Kunden  "unglücklich" und können "teuer zu stehen" kommen.

Gruß Elmar