Excel via Import in SQL Datenbank

Piktogramm schrieb:

Generation von (einzelnen ?) INSERT - Statements über Excel? Ich dachte, das wären nur Horrorgeschichten vom Adminstammtisch -.-

Zum Vergrößern anklicken....

Leider nicht - wenn noch Uralt-Systeme im Einsatz sind, die keine Massendatenpflege erlauben, hast Du kaum eine andere Möglichkeit es den Usern ein bisschen einfacher zu machen.

Piktogramm schrieb:

Ganz ehrlich, wieso zieht man sich den Spaß nicht einfach als csv in die Datenbank anstatt händische Copy & Paste Orgien zu fahren?

Zum Vergrößern anklicken....

Das Uralt-System läuft auch auf einer Uralt-Datenbank, wo das auch nicht so einfach ist.

Piktogramm schrieb:

Mal ganz abgesehen davon, wenn Daten in Excel bearbeitet werden und dann in die Datenbank geschoben werden. Wie fangt ihr da das Potential für Integritätsverletzungen, Redundanzen etc ab?

Zum Vergrößern anklicken....

Zum einen sind es nicht immer Inserts sondern meistens Updates. Zum zweiten kann man das durch geschickte SQL-Statements durchaus abfangen - Kontrolle, ob ein Datensatz vorhanden ist, wenn nicht Insert und dann Updaten.
Ja ich gebe es zu, es ist nicht sehr elegant und z.T. durchaus Fehleranfällig. Aber mit ein wenig Vorsicht und Wissen was man tut und geschickten Skripten klappt es gut.
Ausserdem wird dieses Jahr das Alt-System abgelöst, und damit gehören für mich solche Probleme der Vergangenheit an.

Wobei ich sagen muss, für kleinere Aufgaben ist es wesentlich einfacher, mir kurz über 'ne Excel-Funktion ein Update/Insert Skript zu bauen als es in eine Temp-Tabelle einzuspielen und dann mit SQL einzufügen.

Piktogramm schrieb:

Das nichts, aber wieso sollte man sich Excelmonster bauen die, die SQL Statements bauen die man dann händisch ausführen lässt, wenn man einen csv Import nutzen kann?

Oder man nutzt den Excelimport vom SQL Studio (müsste auch in den Expressvarianten gehen).

https://docs.microsoft.com/de-de/sq...el-to-sql#sql-server-import-and-export-wizard

Das Handbuch vieler Microsoftprodukte ist echt gut und bietet so viele Möglichkeiten. "Pfusch mit Excel und händisches Copy&Paste" habe ich da noch nicht gefunden..

Zum Vergrößern anklicken....

Dir ist aber gerade schon klar, dass du 1:1 den Link von mir weiter oben zitiert hast und SSIS "nur" die automatische Verarbeitung von den händischen Excel Importen ist? Man muss doch AFAIK sogar immer erst den händischen Excel import aufbauen um ihn danach per Paket ins SSIS einzuspielen.

Siehe seinem ersten Post:

"Diese Tabelle soll automatisch durch ein Programm in eine SQL Datenbank geschrieben werden."

Piktogramm schrieb:

Das nichts, aber wieso sollte man sich Excelmonster bauen die, die SQL Statements bauen die man dann händisch ausführen lässt, wenn man einen csv Import nutzen kann?
[...]"Pfusch mit Excel und händisches Copy&Paste" habe ich da noch nicht gefunden..

Zum Vergrößern anklicken....

Wenn du für bestimmte Anforderungen die fertige Formel hast, die Du nur noch ins Excel kopierst, das SQL kopierst und ausführst - in der Zeit hast Du noch nicht mal den Excel-Importer gestartet.
Manchmal musst Du einfach die Effizienz abwägen.

@AgiOli:
Es geht um MS SQL-Server da lass ich "wir haben unsere Infrastruktur vergammeln lassen und haben jetzt keine Wahl mehr" nicht gelten

Wenn man fertige Formeln hat, kann man die auch ins DBS übertragen und dort anwenden anstatt den Benutzern die Möglichkeiten zu geben mit Excel Mist zu bauen.
Genauso wie ein Batch Import über ein CSV genauso fix und fertig daliegen und genutzt werden kann.

Die "Effizienz" der Excellösungen ergibt sich in der Regel nur bei sehr sehr seltenen Prozessen oder aber weil in der Firma ein derartiger Prozess- und Datenwildwuchs herrscht, dass man mit automatisierbaren Scripten nicht weit kommt. Wobei in der Realität dann auch sehr oft Inkonsistenzen im DBS auftauchen weil dieser Wildwuchs derart "dynamisch" ist, dass die Fehlerbehandlung kaum alles abfangen kann.

Das skizzierte Szenario halte ich in "freier Wildbahn" für die Regel, nicht für die Ausnahme. Also die Existenz von Office-basierenden Datengräbern neben einem DBS. Nach meiner langen Erfahrung rührt es daher, dass Mitarbeiter primäre Office-Kenntnisse haben und ein Prozessdesign, was für eine saubere Abbildung im DBS sorgt und für Otto-Normal-User benutzbar ist, fällt nicht vom Himmel. Ein Excel-Sheet schon.
Ob es eine glückliche Wahl ist, im Datenbank-Umfeld programmieren lernen zu wollen sei dahin gestellt.
Totales Horror-Modell zum Datenimport, live gesehen: Als DataPumpe Access benutzen. In Access das Excel-Sheet linken und die Zieltabelle aus dem DBS per ODBC andocken. In Access eine.... wie heißt das? Anfüge(!)Abfrage basteln und die Daten von A nach B.

Natürlich wird es in vielen Firmen so gemacht und es funktioniert irgendwie auch sehr lang*. Es ist nur annähernd die schlechteste Lösung mit dem Potential, dass es einem richtig übel auf die Füße fällt. Vor allem wird das Datenbanksystem ja nicht vorhanden sein weil die Firma beschlossen hat "Excel driven Management" um ein Datenbankbackend zu erweitern. Es wird vielmehr eine (ERP) Software geben, die die Datenbestände primär erstellt, verwaltet und nutzt. Es sollte doch eigentlich einleuchten, dass man dieser Software nicht in ihrem Datenbestand von Hand mit fremden Werkzeugen herumpfuscht sondern wenn diese Software nutzt und gegebenenfalls erweitert / erweitern lässt.

* Gelegenheiten wo es nicht mehr funktioniert:

• Mitarbeiter mit Übersicht / Plan verlässt Firma
• Mitarbeiter mit "kann ich alles Besser" kommt in die Firma
• Steuerprüfung
• Veränderte Marktsituation
• Größere Änderung der ERP-Software
• Ein Mitarbeiter baut Mist, keiner merkt es, Datenbestände sind ab da an falsch
• U name it

Auch gibt es div. sinnvolle Möglichkeiten SQL Datenbank und Excel zu verknüpfen, zum Beispiel das Datewarehousinggeraffel vom MS SQL Server. Das läuft aber über definierte Schnittstellen, ist gescheit abgesichert. Damit ist es Meilenweit von "SQL-Statemants mit Excel basteln und ins MS SQL Studio kippen" entfernt.

Die Frage ist immer noch einfach zu beantworten in Ermangelung nicht vorhandener Transferleistung erweitere ich meine Antwort gerne noch einmal:

* SSIS wird von den nicht für den umfangreichen Produktionsbetrieb gedachten Express-Versionen vom SQL-Server nicht unterstützt.
* Der SQL-Server Standard + die paar CAL dafür kostet kein Vermögen.
* SSIS (als Nachfolger der glorreichen Data Transformation Services) ist das absolut richtige Tool dafür - alles andere ist unprofessionelle Flickschusterei - fefe hatte letztens dazu die Admin Anti Pattern "erfunden" und er hat verdammt Recht.
* SSIS lässt sich mit dem SQL Server zusammen sehr wohl ordentlich automatisieren - oder ich träume nur, was unser Server da immer mal wieder veranstaltet.
* Regelt euren Scheiß einfach, damit ihr professionelle Arbeit abliefert. Es kann ja nicht der Anspruch an euch selber sein immer nur Durchschnitt bis Unterdurchschnittlich zu sein. Abgesehen davon erwartet man von euch als Profis auch einen professionellen Lösungskomplex. Manuell SQL Statements hin und her zu kopieren ist maximal für einen Prototypen zu gebrauchen - in der Produktion (lies: Operations) ist das unprofessionell.

Leute, kommt mal klar... Es handelt sich hier erstmal um ein kleines Projekt für ihn selbst von jemandem der mit der Thematik anfängt.... es ist absolut unklar was genau der Hintergrund ist und für was es eingesetzt wird. Er wird eh noch soviele Fehler machen können dass er eh alles x mal überarbeiten muss wie z.B. falsche Technologie, falsches DB Design usw usw so dass die halb automatisierte Einspielung in die DB sein kleinstes Problem am Anfang ist. Die Probleme mit CSV Importen / BCP und wie sie alle heißen sind hinreichend bekannt und können natürlich auch gegoogelt werden.

Da der TE sich mit Informationen ja sehr zurückhält sollten wir es dabei belassen.

Die (Produktiv-)Datenbank bei der ich das mit den Exel-Insert/Updates machen muss ist KEINE MS-SQL-DB - also keine Möglichkeit mit SSIS oder ähnlich tollen Techniken zu arbeiten.
Entweder mache ich das über diese unperfekte, aber bewährte Technik - oder ich sage dem User, er solle doch bitte seine 1000 Änderungen über die Oberfläche machen, womit er den ganzen Tag beschäftigt wäre. Am nächsten Tag stehe ich dann beim Arbeitsamt zum stempeln....
Willkommen in der Realität, wo Du mit schlechtem Gefühl Dinge machen musst, weil es keine anderen Möglichkeiten gibt.

Die Lösung ist jedoch bereits in Sicht - das 30 Jahre alte System wird dieses Jahr abgelöst werden.

Auf dem SQL-Server arbeiten wir sehr wohl mit SSIS in Verbindung mit SQL-Agent-Jobs.
Wobei ich sagen muss, SSIS ist auch nicht das alleinig seelig machende und hat auch seine Grenzen und Unzulänglichkeiten, die einem das Arbeiten damit manches Mal nicht gerade einfach machen.

... weswegen ich dazu übergegangen bin Datenaustausch per definierter (Webservices) APIs via SOAP und REST zu verwenden und selber anzubieten, da hat man diese unsäglichen Probleme nämlich nicht (mehr - dafür neue, die sind aber wenigstens spannend) und steht auch nicht hinderlich der allgemeinen Digitalisierungsstrategie im Wege.

Generell hält sich meine Gute Laune bei einem definierten Datenaustausch via Excel-Tapeten echt in Grenzen, weil das immer schon die hässliche Ausgeburt von will mal und kann nicht war und ist und es auch keine "beste Lösung" dafür gibt. Die erträglichste Lösung dafür ist dabei nun mal SSIS, da man es wenigstens einigermaßen in Prozesse eingliedern kann. Besser vom Architekturdesign her ist so etwas aber per Microservices direkt aber der Informationsquelle.

Und mir ist auch klar, dass man die Realität dabei nicht ausblenden kann. Technisch ist ein "die anderen, ich nicht deswegen machen wir das seit 30 Jahren so" aber kein Fortschritt. Zur Not muss man mal das unsägliche Gebiet der "Kommunikation" betreten.

Grüße