Daten aus Excel in 2 SQL Server Tabellen importieren

[Tschuckerich 10]

Mache ich  Sorry, bin nicht so oft hier. 

 

Gruß

Oliver

[Tschuckerich 10]

Hallo Nils, 

 

ich spreche dich jetzt nochmals direkt zu dem Thema an. Dank eurer Hilfe habe ich erste Schritte mit dem SSIS gemacht. 

Ohne Probleme konnte ich Daten einer Exceldatei in meine SQL Tabelle importieren. 

 

2. Punkte bräuchte ich noch, dann gebe ich Ruhe

 

a) Daten beim Import prüfen, d.h. neue importieren, vorhandene bei Bedarf updaten

b) Daten die nicht mehr in der Excel Datei vorhanden sind, mit einem Löschmarker (Spalte) versehen. 

 

Was ich bisher herausgefunden habe, dass man eine "Suche" einbauen kann. 

 

Könnte ihr mir nochmal helfen? Vielleicht kann jemand ein Beispiel posten?

 

Oliver

 

[Sunny61 806]

MERGE lautet das Zauberwort für dich: https://docs.microsoft.com/de-de/sql/t-sql/statements/merge-transact-sql?view=sql-server-ver15

https://www.mssqltips.com/sqlservertip/1704/using-merge-in-sql-server-to-insert-update-and-delete-at-the-same-time/

 

Grundsätzlich importiere ich Daten zuerst immer in eine sog. Import-Tabelle, die wird nur für den reinen Import verwendet. Um die Daten in der eigentlichen Zieltabelle zu aktualisieren, hilft dir MERGE.

Natürlich musst Du VOR jedem neuen Import die sog. Import-Tabelle leeren oder per DROP TABLE löschen und mit CREATE TABLE wieder neu erstellen lassen. Details zur Syntax für DROP und CREATE Table findest Du bei MSFT in der KB. Ausführliches testen muss man natürlich auch. ;)

bearbeitet 20. Juli 2021 von Sunny61

[Tschuckerich 10]

Hi Sunny61,

danke für den die Hinweise. Hab´s natürlich gleich mit den Beispieldaten ausprobiert und was soll ich sagen...es funktioniert
Wie gestaltest / startest du dann den Prozess von vorne? Du machst es mit SSIS und baust dir ein Projekt?

 

Wenn man mal von vorne denkt. Die neue Artikeldatei kommt rein. Cool wäre, wein automatischer Prozess,

d. h. Datei kommt in ein definiertes Verzeichnis und diese wird dann automatisch eingelesen. 

 

VG

Oli

 

[NilsK 2.934]

Moin,

 

in dem Fall würde ich auch so vorgehen wie Sunny: Erst roh importieren in eine Interimstabelle. Von dort aus mit SQL-Kommandos die Daten in die Zieltabellen verteilen. (Schrieb ich auch oben schon mal.) Ob es dazu MERGE sein muss oder ein einfacherer Weg funktioniert, hängt von deiner Anwendungslogik ab.

 

Gruß, Nils

 

[Sunny61 806]

vor 13 Stunden schrieb Tschuckerich:

Wie gestaltest / startest du dann den Prozess von vorne? Du machst es mit SSIS und baust dir ein Projekt?

Vor vielen vielen Monden hatte so mehrere Projekte in Access abgefackelt. Am besten noch einen Zwischenschritt einbauen, nach der Import Tabelle noch eine Tabelle mit den exakt gleichen Feldern, Eigenschaften und Größen wie in der Original Tabelle. Die auch immer leeren bevor wieder neu importiert wird. Alles was hier drin ankommt, kommt auch in der Original Tabelle an. Das ist nicht ganz unwichtig.

 

Mit dem SQL Server habe ich noch kein solches Projekt erzeugt/bearbeitet, mit Access ging das damals viel einfacher und schneller. Und ja, man kann das im SQL Server sicherlich automatisieren, täglich, stündlich sieht ein Job nach ob es eine neue Datei gibt, wenn ja, importieren und im Dateisystem die Excel Tabelle in einen anderen Ordner wegsichern. Und natürlich immer jeden Schritt protokollieren. Dazu hatten wir eine eigene Protokolltabelle, dort einfach immer jeden Schritt dokumentieren, hilft bei der Suche nach einem Fehler ungemein.

vor 19 Stunden schrieb Tschuckerich:

Mache ich  Sorry, bin nicht so oft hier. 

Machen, nicht noch Tage warten, Danke.

[NilsK 2.934]

Moin,

 

vor 51 Minuten schrieb Sunny61:

mit Access ging das damals viel einfacher und schneller

Access ist ja auch eine Entwicklungsumgebung und RAD-Plattform, SQL Server ist eine Datenbank. Man kann immer noch mit Access die Anwendungslogik bauen und SQL Server als Backend einsetzen. Ist nur aus der Mode gekommen. Was der TO für die Applikationslogik verwendet, hat er ja noch nicht gesagt - anscheinend gibt es da auch noch keine Architektur.

 

Gruß, Nils

[Sunny61 806]

vor 18 Minuten schrieb NilsK:

Access ist ja auch eine Entwicklungsumgebung und RAD-Plattform, SQL Server ist eine Datenbank. Man kann immer noch mit Access die Anwendungslogik bauen und SQL Server als Backend einsetzen. Ist nur aus der Mode gekommen.

OT:

Bei mir war das Anfang des Jahrhunderts, damals gab es die MSDE (kostenlos) und das SQL Server Management Studio (AFAIR) nur für den 'großen' SQL Server, nicht für die MSDE. Es war kein Geld da für Lizenzen. Später habe ich so etwas ähnliches nochmal gebaut, dann mit dem SQL Server als Backend und in Access die Logik und das Frontend für die User. Hatte was. ;)