Beiträge von alpines

BugFix ich glaube du hast was auf den Augen. Am besten du lädst die Seite nochmal

Bei mir wird bei SMBIOSBIOSVersion "To Be Filled By O.E.M." angezeigt, sollte ich mir darum Sorgen machen?

Also aufpassen wenn man nach Punkten splittet.

Zitat von Code4Fun

bin jetzt ehrlich gesagt etwas erschlagen.

Viele Wege führen nach Rom. Schau dir das Skript einfach mal an und versuchs nachzuvollziehen.

Du kannst ja immer noch selber entscheiden wie du was wo haben möchtest, deine bisherigen Skripte laufen ja immer noch und du stehst unter keinem Zeitdruck.

So halb, das Skript wird crashen wenn du als Bios "ABC123" nimmst, weil du ohne Abfrage immernoch auf das Array zugreifst.

Zitat von Sumale.my

Wie kann ich denn überprüfen, ob "$splitBios" den Zeichensatz "X751SA.705" enhält um zu splitten und wenn nicht, dass dann Platzhalter für "getBios..." und/oder "getModel.." eingesetzt werden?

Wenn du nur prüfen willst ob ein Punkt vorhanden ist, dann nimm einfach StringInStr.

Wenn du allerdings das Format also ZeichenketteNummerZeichenKettePunktNummer erkennen möchtest, dann solltest du StringRegExp verwenden.

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.

Local $aCustomersInfo[1][5] = [["KundenDB1", "https://fqdn/Kunde1/", "123.123.123.69", "Username", "Password", "database1"]]
Local $iCustomerIndex = 0

For $i = 0 To UBound($aCustomersInfo) - 1
    $oDB = _Database_Connect($aCustomersInfo, $iCustomerIndex)
    
    $oQueryResult = _Database_PerformQuery($oDB, $aCustomersInfo, $iCustomerIndex)
    _SaveQueryToFile($oQueryResult, $aCustomersInfo[$iCustomerIndex][0] & "_log.txt")
    
    _MSSQL_Close($oDB)
Next

; Alles unter diesem Kommentar kannst du in eine separate Datei packen

Func _Database_Connect($aCustomersInfo, $iIndex)
    Return _MSSQL_Con($aCustomersInfo[$iIndex][2], _    ;IP
                      $aCustomersInfo[$iIndex][3], _    ;User
                      $aCustomersInfo[$iIndex][4], _    ;Passwort
                      $aCustomersInfo[$iIndex][5])        ;Datenbank
EndFunc

Func _Database_PerformQuery($oDB, $aCustomersInfo, $iCustomerIndex)
    ; Hier Query ausführen und Ergebnis zurückgeben
    ; aber nur verwenden wenn die Queries wirklich im Grunde die selben sind (dein Snippet hat zumindest danach ausgesehen)
    Return _MSSQL_Query($oDB, "SELECT .....")
EndFunc

Func _SaveQueryToFile($oQuery, $sFilePath)
    ; blubb
EndFunc

Du kannst es ja in eine Datei speichern und sie dann immer wieder neu beschreiben.

Das Problem ist, dass das Downloaden der Websiten selbst immer Zeit in Anspruch nimmt. Du könntest die Seite mit TCP herunterladen (nur bei http möglich) oder mit WinHttp.

Allerdings ist das ganze mit WinHttp ein bisschen komplizierter, aber auch da ist ein "Parallelbetrieb" nicht möglich.

Intern bietet AutoIt wirklich nur _InetGetSource, InetRead und InetGet wobei nur InetGet ein Download in einem anderen Thread erlaubt.

Die einfachste Variante wäre wirklich InetGet meines Erachtens nach, alles andere würde entweder mehrere Skripte oder instabiles Multithreading mit DllCalls erfordern.

Zitat von Code4Fun

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.

Das herunterladen des Quellcodes dauert nun mal seine Zeit. Schau dir mal InetGet an.

Damit kannst du Daten herunterladen ohne das Skript zu pausieren, mit InetGetInfo kannst du dir dann den aktuellen Stand des Downloads angucken.

Natürlich sind Quellcodes klein und du wirst InetGetInfo vermutlich nicht brauchen (nur der Vollständigkeit halber erwähnt) aber du kannst folgendes machen.

Starte den Download mit InetGet und sleepe solange (am besten in kleinen 10ms Intervallen) bis der Download abgeschlossen ist, anschließend kannst du den

nächsten Download starten.

So solltest du nicht den GUI-Thread blockieren und die Progressbar sollte einigermaßen flüssig laufen.

Zitat von DerSchatten

Mit dem Suchergebniss befüllen, wie mach ich das?

Zitat von alpines

DerSchatten bei deinem Beispiel sollte das Problem relativ eindeutig sein, du versuchst (auch wenn du es jetzt auskommentiert hast) die ListView zu löschen bevor du mit der Suche anfängst.

Durchsuche lieber die ListView und speichere die Funde in einem temporären Array ab, dann leerst du die ListView und befüllst sie wieder.

Wie man Items erzeugt müsstest du ja wissen, weil du das offenbar schon hinkriegst.

Wie sieht denn dein Code bisher aus und was willst du denn einsparen?

Normalerweise ist der Teil für eine SQL Verbindung nur eine Zeile zum verbinden und eine zum trennen.

Oscar ab 200, 300 aufwärst? Wo kriegst du die Werte denn her?

Klar, ich hab einen leistungsstarken i7 aber wenn ich 10.000 Elemente erzeuge und die Items 52 - 56 Zeichen lang sind, dann dauert die Arraysuche 65ms und die ListView-Suche 363ms.

Dabei wird das gesamte Array und die gesamte ListView (nur das erste Subitem, mehr braucht man ja nicht zum identifizieren) durchlaufen.

Also einen signifikanten Unterschied kann ich das nicht nennen, wer verwendet schon eine ListView (besonders in diesem Beispiel des Threads) mit 10.000 Elementen?

Ich würde lieber die ListView durchlaufen und direkt anklicken statt mich noch nebenbei um die Verwaltung eines Arrays zu kümmern, falls sich während der Programmlaufzeit in der ListView noch was tut.

DerSchatten bei deinem Beispiel sollte das Problem relativ eindeutig sein, du versuchst (auch wenn du es jetzt auskommentiert hast) die ListView zu löschen bevor du mit der Suche anfängst.

Durchsuche lieber die ListView und speichere die Funde in einem temporären Array ab, dann leerst du die ListView und befüllst sie wieder.

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.

Das kommt ganz darauf an was du alles anzeigen lässt. Es wäre wohl effizienter wenn du in einem Array die Textdatei zeilenweise speicherst und diese dann durchgehst,

statt immer die Texte des ListViews abzufragen. Natürlich befindet sich die "Effizienz" hier innerhalb von wenigen Millisekunden also solltest du lieber den Weg nehmen,

der dir einfacher erscheint.

Wenn du die Datei nicht bereits in einem Array gespeichert hast, dann geh lieber die ListView-Elemente durch.

Hast du dir überhaupt die Dokumentation zu _GUICtrlListView_ClickItem angesehen?

Der Parameter den du als Suchtext übergibst ist eigentlich der der angibt welche Maustaste verwendet werden soll.

Du solltest lieber die Einträge durchgehen und mit _GUICtrlListView_GetItemText oder _GUICtrlListView_GetItemTextArray schauen ob der String derjenige ist den du haben möchtest.

Anschließend markierst (klicken nicht empfohlen, außer du willst ein Event auslösen) du die Zeile mit _GUICtrlListView_SetItemSelected.

Man könnte folgendes versuchen:

Das Script wird gestartet und es wird geprüft ob es mit Adminrechten gestartet wurde, wenn nicht, dann soll eine neue Instanz des Skriptes gestartet werden mit RunAs und den jeweiligen Daten.

Das ursprüngliche Script wird beendet und die neue Instanz, mit erhöhten Rechten, startet dann den Installer und klickt sich dort durch.

Wenn es keinen /silent Switch gibt, dann ist das wohl der einzige Weg der noch übrig bleibt.

@Musashi , #RequireAdmin würde aber voraussetzen, dass man beim Start des Scriptes die Daten einträgt und das möchte er ja nicht.

Er will ein Script haben welches ohne Adminrechte einen Installer mit Adminrechten startet, das Problem hierbei ist aber, dass man das gestartete Programm nicht kontrollieren kann, da es mit höheren Rechten gestartet wurde als das ursprüngliche Programm.

Wenn der Installer keinen /silent Switch hat, dann wird man ohne #RequireAdmin im AutoIt-Script (und folglich der benötigten Eingabe des Users+Pw) nicht weit kommen.

Ist ja auch klar, du startest dein Script als Administrator und trägst dort die Daten ein und kannst dann zukünftige Exen starten ohne das nochmal einzutippen.

Wenn du RunAs verwenden willst, dann streiche das #RequireAdmin aus deinem Script und verwende als Benutzer und Kennwort deine Daten und bei Domain

trägst du dann @ComputerName ein, so wie es die Hilfe vorschlägt: https://www.autoitscript.com/autoit3/docs/functions/RunAs.htm

Startet die Exe überhaupt? Was passiert denn wenn du im AutoIt-Script nur folgendes stehen hast:

#RequireAdmin
ShellExecute("PlantronicsHubInstaller.exe")

Ich bin mir ziemlich sicher, dass deine Anmeldedaten innerhalb der Domain nicht Benutzer:Passwort@Domain lauten.

Normalerweise sollte #RequireAdmin mit einem Run oder ShellExecute automatisch den Kindprozess mit erhöhten Rechten starten.

Die Passworteingabe wäre nur beim AutoIt-Script fällig, aber nicht bei weiteren Exen.