Da ich es schon damals echt bescheuert fand, die SQLite.dll nicht mehr in der UDF mit zu liefern, hatte ich mir ein eigenes Include mit den Binärdaten der SQLite.dll erstellt [version 3.7.14.1 für 32-bit x86]. Das Include prüft auf Existenz der "sqlite3.dll" im Skript- und Systemverzeichnis. Ist die Datei nicht enthalten, wird sie im Skriptverzeichnis erstellt.
Natürlich kannst du auch die sqlite3.dll herunterladen und per Fileinstall an dein Skript binden. Mir gefällt die Include-Variante besser.
Beiträge von BugFix
-
-
Für deine Form der Multiusernutzung kannst du problemlos auch SQLite nutzen. Die DB wird während eines Zugriffs (der in der Regel nur einige ms dauert) gesperrt. Hier kann mann durch das Absetzen der Queries über einen Puffer dafür sorgen, dass diese nicht ins Leere laufen. Wenn Query mit Fehler endet: 10 ms warten (oder auch 100, für den User unerheblich) und erneut durchführen, dann sollte die DB wieder frei sein. Wenn wieder Fehler nochmal das ganze bis zu einer $MAX -Zahl an Zugriffen, nach der du davon ausgehen musst, dass ein generelles Zugriffsproblem besteht.
-
Grundsätzlich stellt es kein Problem dar SQLite zu verwenden. Wobei man aus Komfortgründen auch eine Datenbank verwenden könnte, die den Datentyp "DATUM" verwendet. In SQLite musst du das über eigene Konvertierungsfunktionen managen (sei es Datum als Integer oder String).
Ansonsten wird SQLite den Anforderungen voll gerecht (Trigger, Generatoren - alles vorhanden). -
Wenn du mit ADODB arbeitest, musst du auch die richtigen Methoden wählen. Es erstaunt mich, dass du jetzt schon der 2.te User bist, der ein Query mit .Open ausführen will, statt mit .Execute.
Schau dir mal die Verwendung von ADODB hier an.
Und bist du dir sicher beim Verbindungsstring? Ich habe in einem alten Bsp. für mdb-Verbindung stehen "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=DB_PATH;") -
Wenn du eh Access verwendest, warum jetzt noch AutoIt dazu mixen? Access bietet dir eine programmierbare Datenbankoberfläche mit Userinterface, kannst du doch dann auch nutzen (wobei ich mit Access nie richtig warm geworden bin).
Und was bitte ist eine "SQL-Datenbank in Access"? Das ist eine Access Datenbank (mdb). Kannst du natürlich auch mit AutoIt ansprechen. Ich glaube ich habe auch dazu mal eine (ansatzweise) UDF gesehen. Aber nicht immer ist alles auch gut, was möglich ist. -
$RecSet.open("BACKUP DATABASE [" & $sql_db & "] TO DISK = N'" & $BAKDir & "\Sicherung\Kplus_Daten-Sicherung_" & $date & ".bak' WITH NOFORMAT, NOINIT, NAME = N'Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 ", $adCN)
Wieso $RecSet.open? Hier willst du doch mit der DB arbeiten - also brauchst du ein .Execute.
Schau dir mal ein Bsp. für ADODB an. Vor allem gehört bei Arbeit mit Objekten auch zwingend ein Error-Handling dazu. -
In Spalte A stehen alle Postleitzahlen
Wenn das PLZ für DE sein sollen, solltest du dringend das Zellformat ändern. Excel kann keine PLZ, also verwende Text oder Benutzerdefiniert: 5 Ziffern mit Vornull
in Spalte D die Namen und in Spalte F die Telefonnummern.
Mit _ArraySearch in Spalte 0 den PLZ-Wert deiner Vorgabe suchen - Rückgabe ist der Zeilen-Index im Array.
Name ist dann Array[Index][4] und Telefon ist Array[Index][5]. -
dass die Fehlermeldungen von Firebird verursacht werden?
Ich denke, dass kann ich ausschließen. Die PC kommunizieren nur über den Server mit FB. FB selbst hat gar keine Kenntnis von den PCs. Die WaWi-Software ist die Schnittstelle zu FB. Und die Nutzernamen in der WaWi wurden nicht verändert.
-
Ich hatte vor einigen Jahren dazu mal was geschrieben: https://autoit.de/index.php/Thre…7347#post217347
-
dass der Server versucht einen Share zu einem PC/Nas herzustellen
Auf zwei PC hatte ich eine *.bat mit "net use...". Das hatte ich aber entfernt, als ich jetzt alle User neu angelegt hatte. Aber ich werde mir sicherheitshalber mal ein Skript schreiben, das auch noch mal die Registry durchforstet, ob dort eine alte Verbindung schlummert. Bin aber erst im Oktober wieder vor Ort. Solange muss es so gehen.
-
dass es einen IP-Adress Konflikt gibt.
Alle IP sind von Hand gesetzt und unterschiedlich. Sowohl bei PC, als auch bei NAS und Druckern.
-
Das NAS ist ohne Gruppen/Benutzer eingerichtet. Ausschliesslich Freigabe für jedermann.
Ich finde dieses Hochschaukeln des Fehlerintervalls sehr seltsam. -
Also folgender Status:
Gestern war ich um 19:30 fertig und habe vor dem Gehen das Protokoll gelöscht.
Als ich heute morgen kam, waren wieder die Einträge vorhanden. Der erste 20:30, dann 21:30, dann 21:58, noch ein paar mal im halb-Stundenintervall. Plötzlich alle 15 min bis hin jetzt im 2 sec !! Intervall.
Wobei zwischen 19:30 und 08:00 ausschließlich eine Verbindung zum NAS bestand. Von diesem gehen aber keinerlei Aktivitäten aus, da werden dann nachts nur die Sicherungen aufgespielt.
Ich habe zwar keine Verbindungsabbrüche bis jetzt, aber das hat ja sonst auch oft etliche Tage gedauert. Allerdings ist das Ereignisprotokoll bei diesen Intervallen ruck-zuck voll.
(Ich knalle hier bald auf alle Rechner wieder Windows 95 drauf, da gab es wenigstens null Netzwerkprobleme
) -
So, nun habe ich mal versucht anhand von Zeitabläufen zu rekonstruieren, welche Ereignisse den Störungen vorausgegangen sind.
Der einzige etwa passende Vorgang war die Anbindung unseres ELO-Systems (papierlose Datenablage).
In dem Zusammenhang hatte ich Änderungen an einigen PC vorgenommen. Vorher waren da Fantasie-Usernamen angelegt, da die User sich am WaWi-System separat anmelden. Für das ELO ist es aber erforderlich, dass Username und WaWi-Name identisch sind, da Einträge im ELO mit dem PC-Anmeldenamen signiert werden. Deshalb habe ich die Anmeldenamen an den PC geändert (und im Server angelegt).
Was ich erst jetzt bemerkt habe: Obwohl Windows das Ändern des Namens als Option anbietet, passiert das nicht wirklich! Es wird auf Dateiebene nicht der neue Name erzeugt sondern unterhalb des alten Namens ein neuer Ordner angelegt. In der Aussendarstellung blieb es der alte Name.
Mir ist das nicht aufgefallen, da ich mit einem automatischen Anmeldetool mich mit dem neuen Usernamen eingeloggt habe. Somit habe ich mich defacto von einem User ohne Serverzugang mit den Rechten eines Users mit Serverzugang auf den Server verbunden. - Wenn ich Server wär, würde ich da auch am Rad drehen.
Ich habe nun heute auf allen PC die neuen Namen auch als neue User angelegt und bestehende Synchronistaionen der alten Namen gelöscht. Ich hoffe, dass das die Ursache war und mich morgen nur noch ein (fast) leeres Systemprotokoll erwartet.
-
Hat das WaWi oder die Datenbank Zugriffs-Logs
Da gibt es leider keine Logs, zumindest ist mir nichts bekannt und im Programmordner tauchen keine entsprechenden Dateien auf.
-
Was macht ihr denn mit dem Server?
Auf dem Server läuft ein Firebird-SQL. Genutzt über eine Warenwirtschaftssoftware. WaWi ist auf dem Server installiert und von den Arbeitsstationen loggen sich die User dort zum Arbeiten ein.
-
Starte mal den Dienst "Kerberos-Schlüsselverteilungscenter"
Dieser Dienst läßt sich nur starten, wenn der Server mit AD läuft. Das ist bei mir aber nicht der Fall.
Leider sind die Fehler-Logs alles andere als aussagekräftig. Nützlich wäre etwas in der Art: "PC-X mit User Max hat versucht die Freigabe DATEN auf PC-Y anzusprechen. Das wurde wegen fehlender Rechte verweigert"
Aber eine derartige Info an den User wäre wohl viel zu nützlich.
Möglich wäre sowas auch nach dem updaten von diverser Software
An dem Server wurde schon seit Jahren nichts upgedatet. Weder für System noch für die dort laufende Anwendung gibt es irgendwelche Updates. Unabhängig davon würde ich auch niemals im Intranet etwas updaten, solange völlige Funktion gewährleistet ist.
Ich habe auch nicht die Möglichkeit explizit einzelne Komponenten zu trennen, um diese als Verursacher auszuschliessen.
Gibt es denn irgendein Logging, das ich zusätzlich aktivieren kann, das mir Netzwerkaktionen und daraus resultierende Fehler aufzeigt?
-
Hallo,
in unserem kleinen Netzwerk (Workgroup mit Windows 2000 Server) habe ich seit kurzem ständig das Systemprotokoll voll mit:
Ereignistyp:Warnung
Ereignisquelle: MRxSmb
Ereigniskennung: 3034
Beschreibung: Der Redirectordienst konnte den Sicherheitskontext oder die Abfragekontextattribute nicht initialisieren.
Aus den Daten ergab sich der Fehlercode: c000005f
Das ist der Wert für STATUS_NO_SUCH_LOGON_SESSIONAls negativer Effekt brechen dann teilweise Netzwerkverbindungen ab. Nach Neustart des Servers läuft es wieder für (unterschiedlich) Tage oder Wochen.
Das Systemprotokoll ist aber schon innerhalb weniger Stunden voll. Ereignis taucht ca. alle 2 min auf.Nun habe ich mich durch Google gequält und diverse Foren durchgelesen, aber eine für mich passende Lösung konnte ich nicht finden.
Als Ursachen wurden u.a. benannt:
- Kerberos-Dienst (läuft bei mir nicht, da kein AD)
- DNS (soweit ich das sehe, bei mir auch nicht aktiv? Alle Auflösungen laufen über direkte IP-Adressen, kein DHCP-Server im System)
Ich arbeite nur gelegentlich an der Netzwerkstruktur und habe da auch keinen erweiterten Durchblick. Mit der vorhandenen Struktur lief es aber bis jetzt 15 Jahre.Das übersteigt meine Kenntnisse in diesem Bereich.
Hat jemand mit nötigem Hintergrundwissen eine Empfehlung, wie ich das Problem lösen kann?
Aber bitte nur ernstgemeinte Ratschläge, "Umstellen auf AD" oder Softwareänderungen stehen nicht zur Diskussion.Danke
-
gibt es eine Möglichkeit die erstellten Groupboxen von BugFixer zu hiden?
Geht alles
AutoIt
Alles anzeigen$tGroup = _GuiCtrlGroup_Create(....) ; Hide: _GuiCtrlGroup_SetState($tGroup, $GUI_HIDE) Func _GuiCtrlGroup_SetState($_tGroup, $_iState) ;~ $GUI_SHOW, $GUI_HIDE, $GUI_ENABLE, $GUI_DISABLE For $i = 1 To 7 GUICtrlSetState(DllStructGetData($_tGroup, $i), $_iState) Next EndFunc -
man müsste über einen Hook die Windows Messages an PlaySound() abfangen
Das dürfte mehr als aufwändig werden, da es an die zig Notifications gibt, die bei einem Fehler eine Soundausgabe generieren.
Weiterhin ist damit nicht gewährleistet, dass auch alle Sounds erfasst werden, neben PlaySound werden für Fehlermeldungen auch Toast notifications verwendet.
Somit ist vermutlich das direkte Prüfen der Hardware auf Aktivität erfolgversprechender (auch wenn ich adhoc keinen Lösungsansatz dafür habe).
