Hallo,
ich suche eine Möglichkeit, bei einem Update meiner CallCenter Software, die Tabellenstruktur auf dem Anwendungsserver zu prüfen.
Im Moment mache ich es so, das in einer ini Datei die Tabellen und die Spaltennamen stehen.
Ich gehe zuerst die Tabellen durch. Wenn eine Tabelle nicht existiert, rufe ich aus einer text Datei den entsprechenden SQL String auf und erzeuge die. Dann gehe ich durch alle Felder und wenn nicht da, dann füge ich die an.
Im Moment hat mein Prog 25 Tabellen. Da geht es noch mit der Geschwindigkeit. Aber wenn das Prog größer wird, glaube ich habe ich ein Problem.
Das zweite Problem dabei ist, das meine Kunden keinen Datenbankadmin haben - das Update also in der Mittagspause der Agents laufen lassen müßen.

Hat vielleicht einer eine Idee ? Kann der SQL Server das vielleicht nicht auch schon von sich aus ?

Gruß Winni

Also der SQL Server hat unter Garantie eine Tabelle, in der die Tabellenstruktur selber steht. Oracle hat sowas, ADS hat das, ich kann mir nicht vorstellen dass der SQL Server sowas nicht hat.

Normalerweise kannst Du auf diese Tabellen auch eine View legen um das direkt per SQL abfragen.

Hallo Phonix,

die Tabellen und Felder auszulesen ist ja auch kein Problem:

ADOConnection.GetTableNames( StringList);
ADOConnection.GetFieldNames(Table, Stringlist);

Gehe dann durch alle Tabellen und Felder durch, und wenn die nicht vorhanden sind, werden die erzeugt.

Ich hatte so in der Art gedacht, ob der SQL Server das anhand einer Deffinitionsdatei, eventuell allein machen könnte.

Selbstverständlich hat der SQL-Server das, schließlich ist es Bestandteil der SQL-Definition. Die Tabellen heißen sysobjects und syscolumns.

Allerdings verstehe ich nicht ganz, wieso Du prüfen musst, ob die Tabelle auch alle nötigen Spalten hat. Das würde mich interessieren.

Zitat von winnionkel:

Ich hatte so in der Art gedacht, ob der SQL Server das anhand einer Deffinitionsdatei, eventuell allein machen könnte.

Huh. Soweit ich weiss kann DAS kein DBMS.

Was die Performance angeht: Selbst mit Tabellen im GB-Bereich ist sowas kein Problem. Vor allem die Systemtabellen zum Abgleich sind, da IMMER gecached, superschnell abgefragt. Und es reicht ja, die einmal in eine Memtable zu laden und dort dann auf fehlende Fehler zu vergleichen.

Aber mal ne ganz andere Frage: Warum so kompliziert?

Vorschlag:
Wenn Du sowas wie eine Konfigurationstabelle hast hier einen Wert 'DBVersion' anlegen. Wenn Du keine Konfigtabelle hast, diese Anlegen und diesen Wert anlegen.

Eine Version des Datenbanklayouts bekommt ab dann immer eine definierte Version, die in dieser Konfig abgelegt wird.

Änderst Du Deine Tabellen, erhöhst Du die Datenbankversion. Die nötigen Scripte zum ändern (ALTER TABLE..., zur not mit Umweg über temp-tabelle wenns gröbere Änderungen sind etc.) lieferst Du immer alle mit dem Client aus - entsprechend der alten(!) Datenbankversion benamst. Letztes Statement ist freilich das updaten des DBVersion-Wertes auf die neue DB-Version.

Jeder Client benötigt dann einfach eine bestimmte Datenbankversion, die einfach aus dem DBVersion ausgelesen werden kann.

Zum Start des Client überprüft dieser die Version. Ist diese gleich der benötigten ist alles okay. Ist diese kleiner, wird das vorliegende Script zur aktuell eingetragenen DBVersion ausgeführt und danach der Wert nochmal abgefragt. Ist er immer noch kleiner wird das nächste Skript ausgeführt... bis die DBVersion am schluss mit der richtigen vom Client verlangten Version übereinstimmt.

Somit hast Du die Datenbank inkrementell immer auf dem aktuellsten Stand (selbst wenn ein Kunde mal 2 Versionen aussetzt bekommt er alle updates) und das läuft mit der Auslieferung einer neuen Clientversion auch vollautomatisch ab.

Wichtig ist nur, dass dann nicht zwei Clients gleichzeitig versuchen, upzudaten. Also müsstest Du den DBversion-Eintrag halt explizit vom ersten Client aus locken. Wenn schon gelockt ist kann der nächste Client keinen Lock bekommen und mnacht kein update sondern wartet bis der Lock wieder weg ist.

Vielleicht habe ich mich falsch ausgedrückt. Der Kunde will vielleicht zwischendurch mal einige Änderungen am Prog. Ich muß dafür in einer Tabelle zwei Felder anlegen.
Ich schicke dem Kunden die neue exe. Beim Start muß diese dann sehen, ob diese Felder da sind, eventuell anlegen. Der nächste Kunde möchte aber noch gaaaanz lange mit dem alten Prog arbeiten. Eines Tages hat er Geld und will dann die ganz neue Version. Dann müßen alle Felder, die ich in der Zwischenzeit eingebaut habe, erzeugt werden.

Du kannst doch trotzdem jede Änderung an der Datenbankstruktur durch Erhöhung der Datenbankversion protokollieren. Dann brauchst du beim Update nicht die Struktur der Datenbank auslesen sondern kannst anhand der Version feststellen, welche Änderungen notwendig sind.

@willionkel: Dein Datenbankdesign ist falsch. Wenn Du Änderungen bzw. Erweiterungen an deiner Datenstruktur als individuelle Anpassung an einzelne Kundenimplementierungen vorsiehst, solltest Du diese Datenstruktur als Bestandteil deines DB-Schemas implementieren ('Metadaten').

Anstatt z.B. eine Tabelle 'Daten' immer individuell zu erweitern, kannst du auch zwei Tabellen definieren, die "Daten"-Tabelle enthält nur die Daten-ID, sowie eventuell irgendwelche Werte, die imanent für diese Tabelle sind (Schlüsselnummer, Name etc.). In einer zweiten Tabelle definierst Du für jeden Datenwert (mit einer bestimmten Daten-ID) weitere Werte. So kannst Du dann für jede Implementierung individuell den Inhalt der zweiten Tabelle "Datenwerte" erweitern, ohne die eigentliche Struktur zu verändern.

Beispiel:
Klassisches Design: Eine Tabelle 'Daten' mit 3 Spalten: ID, Name, Anschrift
Metadaten Design: Zwei Tabellen:
1. 'Daten' mit einer Spalte 'Daten-ID'
2. 'Datenwerte' mit drei Spalten: 'Daten-ID','Wert-ID','Wert'

Über eine für jede Implementierung individuelle View hat hast Du dann die lokale Sicht auf die 'Datentabelle', die es in der Form ja gar nicht gibt. Als I-Tüpfelchen kannst Du im MS-SQL-Server dieser View auch noch beibringen, auf Änderungen (Insert, Update, Delete) so zu reagieren, das die Manipulationen am Datenbestand in den eigentlichen Tabellen 'Daten' und 'Datenwerte' vorgenommen wird. Das Zauberwort hier heisst "Updateable View" und "Instead Of Trigger" (oh, sind ja zwei Zauberwörter).

@mkinzler

Die Datenbankversion kann ich nicht einfach so ändern, da einige Kunden auch mit anderen Programmen auf meine DB zugreifen. Oder aber ich greife auf eine vorhandene DB des Kunden zu.

@alzaimar
Ich denke nicht, das mein Datenbankdesign falsch ist. Ich habe jahrelang nichts anderes gemacht, als DBDesign.

Ich weiß auch nicht, aber irgendwie möchtet ihr das alle so kompliziert.
Wenn man im Managment Studio einer Tabelle neue Felder einfügt, dann macht der genau das selbe, wie wir das vor zehn Jahren gemacht haben.

Alte Tabelle umbennen. Neue Tabelle erstellen. Daten von alter Tabelle nach neuer kopieren. Alte Tabelle löschen. Das ist jetzt kein Witz.


Ich hoffe mir ist keiner böse.

Zitat:

@mkinzler

Die Datenbankversion kann ich nicht einfach so ändern, da einige Kunden auch mit anderen Programmen auf meine DB zugreifen. Oder aber ich greife auf eine vorhandene DB des Kunden zu.

Warum nicht? Diese Versionsnummer ist ja nur eine Eintrag in eine Tabelle.