MSSQL Abfrage über "Vermittlungsscript"

  • Hallo zusammen,

    ich suche nach einer Optimierungsmöglichkeit für MSSQL Datenbankzugriffe. Aktuell habe ich verschiedene (vermutlich mehr schlecht als recht geschriebene) Autoit Script geschrieben, welche als #include

    Code
    #include <MSSQL.au3>

    beinhalten. Leider ist es zur Zeit so, das ich so um die 40 verschiedene MSSQL Datenbanken der Reihe nach damit abfrage. Das geht soweit auch sehr gut, jedoch habe ich pro Datenbank die Information über die IP Adresse, den Datenbanknamen, den Datenbankbenutzer und das Passwort zu pflegen. Aktuell habe ich - wie oben schon geschrieben, dadurch viele Zeilen generiert, welche vielleicht gar nicht notwendig sind.

    Mein eigentliche Problem ist hierbei jedoch folgendes. Wenn ich nur ein Autoit Script geschrieben hätte, dann würde ich ja auch nur in diesem die ganzen Datenbankverbindungen pflegen müssen. Da ich aber mehrere geschrieben habe, geht diese Pflege ins unermüdliche.

    Jetzt habe ich folgende Idee, welche Ihr bestimmt als total einfach anseht, jedoch habe ich keine Ahnung oder geistigen Ansatz, wie ich das verwirklichen soll.

    Ich würde jetzt ein eigenes, nennen wir es mal "DatenbankVerbindungsScript.au3" schreiben, in welchem die

    Code
    #include <MSSQL.au3>

    integriert ist.

    In diesem Script allein pflege ich ALLE Datenbankverbindungen, d.h. wenn sich an einer DB irgendwas ändert, muss ich nur noch hier was anpassen!

    Jetzt möchte ich dann z.B. ein neues weiteres Script schreiben, welches eine bestimmte Datenbankabfrage durchführt. Wie gelingt es mir, aus diesem Script das DatenbankVerbindungsScript.au3 zu integrieren, sodaß die Abfrage auf die zuvor geöffnete Datenbanken zugreifen kann.

    Vielleicht kann mir jemand einen klitzekleinen Code Ausschnitt mit anheften, damit ich das besser verstehe, das wäre echt Klasse

    Hier auch nochmals zur beispielhaften Verdeutlichung. Wir haben z.B. 40 verschiedene Kundendatenbanken, in welche immer als Benutzername eine E-Mailadresse hinterlegt ist.

    Jetzt schreibe ich (bisher) ein Script - mit alles Datenbankinformation in diesem Script - und arbeite mit mit einem Array der Reihe nach durch die einzelnen Datenbanke, d.h. DB öffnen, DB Abfrage, DB schließen, ab zur nächsten DB usw.

    Vielen Dank für eure Hilfe

  • Du könntest aber auch die variablen Informationen (IP Adresse, den Datenbanknamen, den Datenbankbenutzer und das Passwort) in eine Datei auslagern (INI-File, Textdatei, weitere Datenbank ...).
    Wobei ich die Speicherung des Passwortes schon wieder als sicherheitskritisch ansehen würde.
    Damit kannst Du dann die Datenbankkonfigurationen in einer Schleife abarbeiten. Kommt eine neue hinzu oder ändert sich was, dann änderst Du nur mehr die Datei.

  • Hallo water,

    Danke für die Idee. Ich vermute hier mich jetzt doch nicht klar genug ausgedrückt zu haben. Ob ich die variable Informationen nur im Script halte oder extern ist ja erst mal egal, hauptsache nur einmal vorhalten. Was mir Kopfzerbrechen macht, ist das ich aktuell pro Script IMMER die DB aufrufe, dort mich authentifiziere, dort meine DB Abfragen durchführe. Ich würde jetzt gerne eine Technik (die ich noch nicht kenne) verwenden, um ein Script "DB" zu schreiben, welches nur die DB Verbindung und Authentifizierung durchführt. In meinen weiteren Scripten "A", "B" usw. möchte ich dann das Script "DB" irgendwie aufrufen, damit im Script "A", "B" usw. die Datenbankverbindung schon "online" ist und ich dort dann direkt mit den unterschiedlichen DB Abfragen anfangen kann. Hoffe es jetzt verständlicher ausgedrückt zu haben. Sorry!

  • Dann schreib dir doch ein paar Funktionen in denen du als Parameter diese Werte akzeptierst: bspw: _Connect($sServer, $sPasswort, $sUser) und returne anschließend das Handle zur MySQL Verbindung um damit weiterzuarbeiten. Dann hast du die Zeilen zum Verbinden nur einmal in einer Funktion und nicht für jedes Script einzeln.

  • returne anschließend das Handle zur MySQL Verbindung um damit weiterzuarbeiten.

    Hallo, abgesehen davon das es sich um eine MSSQL handelt (was der übigen Aussage aber keinen Abbruch tut), wäre ich um ein kleines Syntax Beispiel sehr dankbar. Ich raffe es gerade nicht, wie ich die unterschiedlichen Scripte ineinander verbinden, bzw. miteinander compilieren muss. Vermutlich stehe ich blos auf einer sehr dicken Leitung

  • Hallo Alpine,

    danke für die Hilfe. Es wäre hier zuviel unzähliger unsauberer Code. Es geht mir hier ja auch nur um eine prinzipielle Gedankenstützte.

    Bisher verwende ich ja in meinem Code den #include <MSSQL.au3>

    Wenn ich Dich richtig verstanden habe, dann würde ich jetzt eine z.B. MSSQLConnect.au3 schreiben, welche den #include <MSSQL.au3> beinhaltet.

    In meinem "abfragenden Script" würde ich dann als #include <MSSQLConnect.au3>. Ist das soweit richtig, oder denke ich hier schon falsch?

    Wenn das abfragende Script compiliet wird, enthält es dann die gesamte Logik von MSSQL.au3 und von MSSQLConnect.au3?

    Und wie "returne anschließend das Handle zur MySQL Verbindung um damit weiterzuarbeiten" ich das Handle von MSSQLConnect.au3 in mein "abfragendes Script"?

    Ich will hier von Grund auf meine Scripte neu (und hoffentlich besser) bauen.

    Danke für Deine Gedult.

  • Wenn das abfragende Script compiliet wird, enthält es dann die gesamte Logik von MSSQL.au3 und von MSSQLConnect.au3?

    Ja, der Compiler setzt an die Stelle wo das #include enthalten ist einfach die komplette Datei ein.

    Das Problem ist, dass ich nicht weiß was du alles machst und welcher Teil davon bei jedem Script gleich ist.

    Poste uns doch mal den Teil von den Scripten der bei allen identisch ist und streich die Login-Daten raus.

    Normalerweise braucht man für eine SQL Verbindung wirklich nur eine Zeile also frage ich mich warum du das überhaupt alles auslagern möchtest.

    Vielleicht ist deine Authentifizierung ja anders, wenn du uns kein Beispiel gibst können wir da nicht viel machen.

    Prinzipiell solltest du eine eigene Funktion schreiben die mit variablen Daten einloggt und am Ende das Handle returnt welches du dann von der Funktion abspeicherst und dann selber Queries ausführen kannst.

  • OK, Du hast es so gewollt :)

    Ich hoffe niemanden ganz schlecht. Habe es jetzt kurz quick and dirty neutralisiert, vielleicht passt jetzt auch was nicht mehr, aber es geht ja um das Prinzip

    Ziel sollte sein, dass Func _DBConnect($Case) und Func _DatabaseSelection($SelectedDatabase) in einer zentralen *.au3 laufen, welche dann in die indiviuellen Scripte includet werden.

    Die individuellen Scripte haben dann z.B. eine Func _SQLAbfrage($SelectedDatabase, $URL) , kann aber auch anderst sein.

    Bisher habe ich ja (vielleicht nicht in diesem Beispiel) der Reihe nach eine DB geöffnet, mein SQL Statement abgefeuert, meinen Output generiert, die DB geschlossen und dann via Array weiter zur nächsten DB usw. Wie mache ich dass den in einem abfragenden Script. Ich habe da echt Kopfweh, wenn ich mir überlege, von wo nach wo ich da mit Parametern hin und herspringen muss.

    Es wäre schön, wenn mir jemand ein Gerüst baut, damit ich weiß, welche Funktion - mit entsprechenden Parameterübergaben - ich wo genau einbauen muss und wie ich das alles "returne", damit ich die notwendigen Informationen im abfragenden Script übermittelt bekomme.

    Danke!

    Beispiel Code
  • So, damit können wir arbeiten.

    Wie du die Daten speicherst ist erstmal irrelevant, ob du immer das gesamte Kundenarray mit Index übergibst oder die einzelnen Parameter, das ist geschmackssache.


    Das ist alles ziemlich theoretisch gehalten, du kannst da noch an allen Ecken und Kanten schrauben und es dir nach belieben anpassen.

    Führst du eigentlich auf jeder Datenbank die selbe Query aus? Wenn ja, dann kannst du das in etwa so abspecken.

    Ich bin mit deinem Script nicht komplett schlau geworden also kann es sein, dass ich vielleicht einige Sachen falsch interpretiert habe, aber gucks dir mal an und sag was du davon in etwa hältst.

  • Hi alpines,

    bin jetzt ehrlich gesagt etwas erschlagen. Habe das Programmieren ja nie wirklich gelernt, sodass ich mich da erst mal in Ruhe einlesen muss. Ich werde mich dann wieder melden. Vielen Dank