4
Tabelleninhalte Export als SQL-Skript
Hallo,
ich arbeite zur Zeit mit verschiedenen Datenbanken (z.B. Oracle 9i) und stehe gerade vor einer recht kniffligen Aufgabe im Zusammenhang mit Excel.
Ich wusste leider nicht, ob meine Frage besser in den Bereich "Datenbanken" oder "Excel" passt!?
Und zwar möchte ich eine Tabelle in ein fertiges SQL-Skript exportieren.
Sprich z.B. ein Makro schreiben, welches mir auf Knopfdruck alle Spalteninhalte mit den zugehörigen SQL-Befehlen ("INSERT") in eine .sql-Datei schreibt, sodass man bei Anpassungen der Datei nur auf einen Button drückt und sofort ein Skript hat, welches man dann später beim Kunden auf der Datenbank ausführen kann, um sie mit den Inhalten aus der Tabelle abzugleichen.
Ich dachte zunächst an eine Lösung im Zusammenhang mit ODBC, wobei mir dabei einfiel, dass das Problem an der ganzen Sache ist, dass derjenige, der die Tabelle bearbeitet, nicht zwangsläufig eine direkte Verbindung zur Datenbank hat.
Leider muss ich zugeben, dass ich mich mit Makros/VBA nicht sehr gut auskenne und hoffe deshalb, dass mir hier jemand helfen kann.
Grüße,
Thomas
ich arbeite zur Zeit mit verschiedenen Datenbanken (z.B. Oracle 9i) und stehe gerade vor einer recht kniffligen Aufgabe im Zusammenhang mit Excel.
Ich wusste leider nicht, ob meine Frage besser in den Bereich "Datenbanken" oder "Excel" passt!?
Und zwar möchte ich eine Tabelle in ein fertiges SQL-Skript exportieren.
Sprich z.B. ein Makro schreiben, welches mir auf Knopfdruck alle Spalteninhalte mit den zugehörigen SQL-Befehlen ("INSERT") in eine .sql-Datei schreibt, sodass man bei Anpassungen der Datei nur auf einen Button drückt und sofort ein Skript hat, welches man dann später beim Kunden auf der Datenbank ausführen kann, um sie mit den Inhalten aus der Tabelle abzugleichen.
Ich dachte zunächst an eine Lösung im Zusammenhang mit ODBC, wobei mir dabei einfiel, dass das Problem an der ganzen Sache ist, dass derjenige, der die Tabelle bearbeitet, nicht zwangsläufig eine direkte Verbindung zur Datenbank hat.
Leider muss ich zugeben, dass ich mich mit Makros/VBA nicht sehr gut auskenne und hoffe deshalb, dass mir hier jemand helfen kann.
Grüße,
Thomas
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 131723
Url: https://administrator.de/forum/tabelleninhalte-export-als-sql-skript-131723.html
Ausgedruckt am: 23.04.2025 um 07:04 Uhr
4 Kommentare
Neuester Kommentar
Moin n0ss0r,
willkommen im Forum.
Aber dann ist doch erst recht erstrebenswert, wenn keine sofort aufzuführenden INSERT-Statements gegen die DB abgefeuert werden, sondern nur eine (versand-)fertige .sql-Datei erzeugt wird.
Wo liegt denn jetzt das Problem?
Ist eine asynchrone Verarbietung hinnehmbar oder braucht die Excel-tabelle Informationen darüber, welche Datensätze in die Oracle-Tabellen übernommen werden konnten?
Wenn ja - was müsste in der Excel-Klamotte gespeichert werden, welche Fehlerbehandlung ist erforderlich.
Wenn nein - dann würde ich die Automatisierung (wenn es keine regelmäßige Aktion ist) sogar ganz zurückstellen und die SQL-Generierung direkt in einer freien Spalte der Exceltabelle mit banalen Excelformeln+Copy&Paste abfackeln.
Grüße
Biber
willkommen im Forum.
Zitat von @n0ss0r:
Ich dachte zunächst an eine Lösung im Zusammenhang mit ODBC, wobei mir dabei einfiel,
dass das Problem an der ganzen Sache ist, dass derjenige, der die Tabelle bearbeitet,
nicht zwangsläufig eine direkte Verbindung zur Datenbank hat.
Ich dachte zunächst an eine Lösung im Zusammenhang mit ODBC, wobei mir dabei einfiel,
dass das Problem an der ganzen Sache ist, dass derjenige, der die Tabelle bearbeitet,
nicht zwangsläufig eine direkte Verbindung zur Datenbank hat.
Aber dann ist doch erst recht erstrebenswert, wenn keine sofort aufzuführenden INSERT-Statements gegen die DB abgefeuert werden, sondern nur eine (versand-)fertige .sql-Datei erzeugt wird.
Wo liegt denn jetzt das Problem?
Ist eine asynchrone Verarbietung hinnehmbar oder braucht die Excel-tabelle Informationen darüber, welche Datensätze in die Oracle-Tabellen übernommen werden konnten?
Wenn ja - was müsste in der Excel-Klamotte gespeichert werden, welche Fehlerbehandlung ist erforderlich.
Wenn nein - dann würde ich die Automatisierung (wenn es keine regelmäßige Aktion ist) sogar ganz zurückstellen und die SQL-Generierung direkt in einer freien Spalte der Exceltabelle mit banalen Excelformeln+Copy&Paste abfackeln.
Grüße
Biber
Hi Biber,
zunächst mal ein einfaches Beispiel, wie die Tabelle aussehen kann:
Attribut Bezeichnung Use?
Test1 Bez1 X
Test2 Bez2
Test3 Bez3 X
Die Spalten "Attribut" und "Bezeichnung" sollen in korrespondierende Spalten in der Datenbank übernommen werden, während die Spalte "Use?" zur Selektion dient, sprich nur die mit einem "X" markierten Zeilen sollen in die Datenbank, bzw. das SQL-Skript übernommen werden.
So in etwa könnten die zu generierenden SQL-Statements aussehen:
Für 'Attribut' und 'Bezeichnung' hätte ich jetzt nur gerne die Inhalte der Spalten aus der Tabelle, das Ganze in dieser Form in einer .sql-Datei.
Deine Idee die SQL-Generierung in einer freien Spalte mit einfachen Formeln zu realisieren finde ich gar nicht mal so schlecht.
Man könnte überlegen die SQL-Statements in einer freien Spalte vorzubereiten, die Inhalte aus den Spalten hinzuzufügen und anschließend den Inhalt dieser Spalte irgendwie abzuspeichern.
Das Ganze schön in einem Makro verpackt.
Wie sähe da eine ungefähre Realisierung aus? Bessere Möglichkeiten?
Jedenfalls schon mal Danke für den Input!
Grüße,
Thomas
zunächst mal ein einfaches Beispiel, wie die Tabelle aussehen kann:
Attribut Bezeichnung Use?
Test1 Bez1 X
Test2 Bez2
Test3 Bez3 X
Die Spalten "Attribut" und "Bezeichnung" sollen in korrespondierende Spalten in der Datenbank übernommen werden, während die Spalte "Use?" zur Selektion dient, sprich nur die mit einem "X" markierten Zeilen sollen in die Datenbank, bzw. das SQL-Skript übernommen werden.
So in etwa könnten die zu generierenden SQL-Statements aussehen:
-- insert wanted attribute
INSERT INTO RM_ATTRIBUTE
( IDSEQ, RESOURCETYPE, INTERNALNAME, NAME, MODUSER, MODTIME, CREATETIME)
VALUES
( IDSEQ_SEQUENCE.NEXTVAL, 'Ressourcentyp', 'Attribut', 'Bezeichnung', 'initial', SYSDATE, SYSDATE)
/Für 'Attribut' und 'Bezeichnung' hätte ich jetzt nur gerne die Inhalte der Spalten aus der Tabelle, das Ganze in dieser Form in einer .sql-Datei.
Deine Idee die SQL-Generierung in einer freien Spalte mit einfachen Formeln zu realisieren finde ich gar nicht mal so schlecht.
Man könnte überlegen die SQL-Statements in einer freien Spalte vorzubereiten, die Inhalte aus den Spalten hinzuzufügen und anschließend den Inhalt dieser Spalte irgendwie abzuspeichern.
Das Ganze schön in einem Makro verpackt.
Wie sähe da eine ungefähre Realisierung aus? Bessere Möglichkeiten?
Jedenfalls schon mal Danke für den Input!
Grüße,
Thomas
Moin n0ss0r,
nochmal die Rückfrage, bevor wir unnötig irgendwohin loslaufen...
?? Ist es denn eine regelmäßig wiederkehrende Aktion größeren Ausmaßes OHNE (nach menschlichem Ermessen) manuell erforderliche Eingriffe ??
Wenn ja --> dann isses automatisierbar --> meinetwegen einen Makro.
Wenn eher nein --> for what? "Halb automatisiert" lohnt sich sehr sehr selten.
Entweder die Klamotte kann (als Beispiel) unbeaufsichtigt jeden Mittwoch um 03:30 per Taskplaner gestartet werden,
oder aber es muss ein Mensch davor/dabeisitzen--> dann soll der auch alles auf dem Bildschirm sehen können.
Grüße
Biber
nochmal die Rückfrage, bevor wir unnötig irgendwohin loslaufen...
Man könnte überlegen die SQL-Statements in einer freien Spalte vorzubereiten, die Inhalte aus den Spalten hinzuzufügen
und anschließend den Inhalt dieser Spalte irgendwie abzuspeichern.
Das Ganze schön in einem Makro verpackt
Genau der letzte Satz ist die Frage...und anschließend den Inhalt dieser Spalte irgendwie abzuspeichern.
Das Ganze schön in einem Makro verpackt
?? Ist es denn eine regelmäßig wiederkehrende Aktion größeren Ausmaßes OHNE (nach menschlichem Ermessen) manuell erforderliche Eingriffe ??
Wenn ja --> dann isses automatisierbar --> meinetwegen einen Makro.
Wenn eher nein --> for what? "Halb automatisiert" lohnt sich sehr sehr selten.
Entweder die Klamotte kann (als Beispiel) unbeaufsichtigt jeden Mittwoch um 03:30 per Taskplaner gestartet werden,
oder aber es muss ein Mensch davor/dabeisitzen--> dann soll der auch alles auf dem Bildschirm sehen können.
Grüße
Biber
Hi Biber,
es ist als regelmäßige, im Zusammenhang mit Aktualisierungen und Veränderungen der gegebenen Tabellen, und wiederkehrende Aktion gedacht. Also, ja.
Es dient hauptsächlich zur Automatisierung und Vereinfachung des Ablaufs der Aktualiserung der Datenbank.
Wenn das System beim Kunden in Betrieb ist und wir Veränderungen vornehmen an unseren lokal vorhandenen Basis-Tabellen, soll die Möglichkeit bestehen die .sql-Datei daraus zu generieren und den Administratoren beim Kunden zur Einspielung in die Datenbank zu senden.
Meinetwegen einer unserer Mitarbeiter verändert die Tabelle, drückt auf einen Knopf --> Zack .sql-Datei da --> ab zum Kunden. Fertig.
So ist es gedacht.
Grüße
es ist als regelmäßige, im Zusammenhang mit Aktualisierungen und Veränderungen der gegebenen Tabellen, und wiederkehrende Aktion gedacht. Also, ja.
Es dient hauptsächlich zur Automatisierung und Vereinfachung des Ablaufs der Aktualiserung der Datenbank.
Wenn das System beim Kunden in Betrieb ist und wir Veränderungen vornehmen an unseren lokal vorhandenen Basis-Tabellen, soll die Möglichkeit bestehen die .sql-Datei daraus zu generieren und den Administratoren beim Kunden zur Einspielung in die Datenbank zu senden.
Meinetwegen einer unserer Mitarbeiter verändert die Tabelle, drückt auf einen Knopf --> Zack .sql-Datei da --> ab zum Kunden. Fertig.
So ist es gedacht.
Grüße
