Hallo zusammen,

in meiner täglichen Arbeit kommt es oft vor das ich ein Wert in allen Tabellen einer Datenbank suchen muss. Dazu verwende ich ein SQL-Script direkt in der SQL-Konsole (SSMS) welches mir dann alle Tabellen, Felder und den Inhalt des Feld ausgibt in dem der Suchbegriff auftritt.

Das Script ist soweit ok, nur muss ich das Script jeweils als stored Procedure anlegen, ausführen und nicht vergessen diese dann wieder zu entfernen.

Nun möchte ich das jedoch über mein Tool durchführen um z.Bsp. bekannte Fehler gleich zu beheben.

Allerdings komme ich nicht weiter. Alle Datenbanken auszulesen ist ok, die Tabellen auszulesen dürfte auch noch gehen, aber wie gehe ich insgesamt dir kompletten Felder aller Tabellen durch? Um den Inhalt zu bewerten, müsste ich auch auslesen ob das Feld ein numerisches, alphanumerisches, ein Datum oder anderes ist.

Könnte mir jemand helfen?

Viele Grüsse,
Dani

DniBo schrieb:

Hallo zusammen,

in meiner täglichen Arbeit kommt es oft vor das ich ein Wert in allen Tabellen einer Datenbank suchen muss.

Öhem ... WHAT? o_O

Dann solltest Du Dir lieber Gedanken machen was da so völlig schief läuft.

Da kann irgendwas nicht stimmen, da es völlig unmöglich ist das in einer Datenbank das Attribute einer Entität in mehr als in einem Table steht. Wenn dem so wäre passt das komplette Datenmodell hinten und vorne nicht, einfach weil es keine redunante Datenhaltung in einer DB gibt ... ein Wert steht nur einmal an einer einzigen Stelle in einer DB egal wie groß das Teil ist und damit hat es sich.

Gruß

Rainer

Hallo Rainer,

es ist nicht so das die Tabellen falsche Werte besitzen, eher das Programm was die Tabellen befüllt und ändert, arbeitet nicht so korrekt

Somit suchen wir nicht nach falschen Daten sondern eher nach Daten, die durch das Programm eigentlich entfernt werden sollten. Man darf das nicht als Adress-Datenbank sehen, soweit klappt das schon.

Vielmehr geht es auch darum nach Werte zu suchen um den Datensatz zu finden, in dem bzw in welcher Tabelle er dann steht.

Bei 50 Tabellen muss ich eben nach einem angemeckerten Wert suchen der in einer der Tabellen sein kann.

Nicht weiter darüber nachdenken, ich kann es nicht beeinflussen (Programm kommt aus USA und wird in Indien geschrieben), daher suche ich nach dem Wert und korrigiere das dann falls Daten enthalten sind die durch Änderung im Programm eben nicht entfernt wurden.

Ist auch nicht so schlimm wie es sich anhört

Viele Grüsse,
Dani

Was für ein Schwachsinn. o_O

Klar Du kannst nichts dafür, aber wie kann ein Programm beim löschen von Daten failen? Das geht gar nicht, bzw. so dämlich kann sich doch nun wirklich kein Programmierer anstellen. *kopfschüttel*

Aber gut, würde mal sagen das wäre dann als externes Tool ein Fall für Linq ... anderseits ... ist das Script was Du hast zeilenorientiert?

Dann könntest Du Zeile für Zeile einlesen und jede eingelesene Zeile direkt als SQL-Statement ausführen lassen über ein Command-Object. Denke das würde am sinnvollsten sein.

Gruß

Rainer

DniBo schrieb:

Ist auch nicht so schlimm wie es sich anhört

Hört sich aber wirklich schlimm an.

Also es muß doch einen Verantwortlichen geben, der die Einführung dieses Progs zu verantworten hat. Ist der damit konfrontiert, dass das Prog - naja Schrott ist (kann man glaub schon sagen), und dass deswegen jetzt ein irrsinniger Workaround implementiert werden wird, der im Grunde das Chaos nur noch schlimmer macht?

Ich find, zunächst mal darf man sowas nicht einkaufen, und wenns passiert ist, muß mans reklamieren.

ErfinderDesRades schrieb:

Ich find, zunächst mal darf man sowas nicht einkaufen, und wenns passiert ist, muß mans reklamieren.

Schon mal real life Software für "richtige" Kunden geschrieben, die 10-15 Jahre im Einsatz war/ist? Selbst wenn man zu Anfang ein perfektes Werk abliefert, tritt häufig das Problem auf, dass im Laufe der Zeit Anforderungen geändert werden bzw hinzukommen und die immer wieder "nachgefrickelt" werden (weils schneller und billiger ist als jedesmal neu anzufangen). Irgendwann hast du dann ein unperformantes und fehleranfälliges Codemonster, das nur noch in Ehren ergraute Eingeweihte ansatzweise verstehen. Aber es läuft - manchmal mehr, manchmal weniger. Klar könnte man jetzt sagen: Machen wir jetzt mal "schön". Aber "schön machen" heißt normalerweise fast komplett neu schreiben. Inklusive Einführungsphase wo jede Menge Fehler auftreten (können). Und das alte funktioniert doch ... eigentlich.
Gibt halt Theorie und Praxis

Ja, du hast wohl recht. Ich hab einfach ein großes Maul
Najaa - aber ein nicht (oder nicht mehr) passendes Datenmodell...

@ picoflop

Du hast natürlich schon Recht, dass Apps die länger laufen und fortlaufend erweitert werden irgendwann zu einer Code-Frickelei verkommen können.

Aber trotzdem ... wenn man neue Funktionen implementiert dann kann man trotzdem sicher stellen das die auch einwandfrei arbeiten und wenn nicht muss man eben halt nochmal Hand anlegen bis es zuverlässig funzt, man bekommt ja schließlich auch Geld dafür und Bugfixing gehört halt mal klassisch zum Job dazu.

Ich habe auch so ein Teil laufen ... eigentlich als kleine Anwendung gedacht, ist das durch Kundenwünsche mittlerweilen zu einem richtigen Monster geworden. Ja klar, stolpert man dann irgendwann darüber ... verdammt, da hatte ich damals gar nicht dran gedacht das das überhaupt mal gefordert werden könnte. Okay, shit happens ... dann wird der Bereich halt komplett redesigned und dann funzt es dann auch zuverlässig. Ja klar kommen dabei dann manchmal Sachen raus die man so definitiv niemals freiwillig planen würde, aber gut man will ja auch nicht unbedingt dann die komplette Anwendung redesignen.

Wenn das Programm einigermaßen sauber aufgebaut ist (Stichwort OOP und Kapselung) und die einzelnen Bereich mehr über Schnittstellen miteinander zusammen arbeiten dann ist man aber eh eigentlich gut vorbereitet in der Zukunft eine Anwendung zu pimpen ohne großartig überdimensionierten Aufwand betreiben zu müssen.

Gruß

Rainer

Hallo zusammen,

lieber "ErfinderDesRades", Du sprichts so ziemlich das an was passiert ist. Die Applikation war soweit schon mal redesigned worden, lieg dann auch ganz gut (aus meiner technischen Sicht), aber unser Business brauchte immer weitere Erweiterungen uns so kam es wie es kommen musste, das Teil wird zwar nicht unstabil, berücksichtigt jedoch nicht mehr alles je höher die Version wird.

Klar wurde das App mal schön geplant und entwickelt, aber meines erachtens haben wir zwei Probleme:

-das Business fordert eine Erweiterung/neue Funktion
-das zuständige Team in USA entwickelt das Kochbuch dazu
-der Auftrag geht nach Indien, die schreiben/ändern was
-der neue Bereich geht zurück an USA und wird von Leuten geprüft die eben nicht technisch sondern kaufmännisch sind
-die neue Version wird ausgerollt
-wir leiden dann unter vielen Support-Anfragen
-Fehler werden gemeldet und ein Hotfix erstellt
-Problem behoben, dabei entsteht ein neues
-und und und ...

Ich glaube dazu muss ich nichts mehr sagen, die höchste Schnittstelle (Business-USA-Indien) arbeitet schon mal nicht, warum soll dann das Programm alles richtig machen

Da ich hier nichts ändern kann, kümmere ich mich mit meinem Team und die Analyse und anpassung der Daten, denn das ist eigentlich das grösste Problem (etwa 80%). Wenn mal Daten falsch abgelegt wurden, z.Bsp. wurde das Datum nicht richtig konvertiert (warum auch, gibt ja nur USA auf der Welt), nicht gelöscht wurden bei Umstellung von Aufträgen in der Applikation etc, suchen wir die entsprechenden Tabelle/Feld, prüfen den Zusammenhang und passen die Daten an.

Mit dieser Arbeitsweise schaffe ich es ein Problem am gleichen oder darauf folgenden Tag für unser Business zu lösen, andere Kollegen in anderen Ländern brauchen dafür schon mal ein Monat in Abhängigkeit das ein Inder auch gerade zur Verfügung steht.

Aus diesem Grund habe ich mir verschiedene Tools geschrieben, nur eines fehlt mir noch, das Durchsuchen aller Felder in allen Tabellen um den Wert per Tool zu finden.

Über das SQL-Script direkt im SSMS (SQL-Konsole) klappt es einwandfrei, nur hier muss ich die stored Procedure hinzufügen und danach wieder löschen, ich ändere also eine Datenbank, was ich so nicht will. Selber weiss ich dass das Teil wieder gelöscht werden muss, meine Kollegen "übersehen" es leider ab und an

Werde wohl nicht darum herum kommen und das SQL-Script stück für stück nach VB.net umzusetzen. Bin zwar kein Anfänger, aber es gehört schon was dazu, denke ich.

So, nach dem langen Text setze ich mich mal wieder an mein Tool und schaue was ich machen kann. Vieleicht aber ist sowas ja schon in Stücken fertig? Würde mich freuen.

Viele Grüsse,
Dani

DniBo schrieb:

Werde wohl nicht darum herum kommen und das SQL-Script stück für stück nach VB.net umzusetzen. Bin zwar kein Anfänger, aber es gehört schon was dazu, denke ich.

Wie schon mal gesagt, ich würde dann lieber ein VB.NET-Tool bauen das die SQL-Scripts ausliest und umsetzt.

Du brauchst halt hinter jedem SQL-Statement einen eindeutigen Delimiter (dafür sollte sich eigentlich das Semikolon eignen). Dann kannst Du sie Scripte einlesen in NET, anhand des Delimiters in ein Array splitten und dann Statement für Statement automatisiert abarbeiten lassen.

Z.B. per OCDB-Connection und Rückgaben in einem ADODB-Recordset entgegen nehmen ... Rückgabe-Statements kannst Du ja problemlos daran festmachen ob das erste Wort des Statements ein SELECT ist.

Vorteil an dem Tool wäre das es jedes SQL-Script verarbeiten könnte und damit universell auch für zukünftige Aufgaben einsetzbar wäre und Du sparst Dir jetzt die Arbeit das bereits bestehende und funktionierende SQL-Script großartig erstmal nach NET übersetzen zu müssen. Du müsstest es zwar ein wenig abändern (rein nur auf die SQL-Statements runterbrechen), aber das wäre wesentlich weniger Aufwand als jedes Statement in .NET neu zu erfassen und eine Abarbeitung dafür zu erstellen.

Gruß

Rainer