Fehler bei Script mit DBF-UDF

Zitat von autobert

Ich hatte dieselben Probleme mit dem Skript:

Ein einfügen von:

Code

Code

#AutoIt3Wrapper_UseX64=n

im Kopf des Skriptes und Problem ist verschwunden. Mein Consolenoutput von Musashi 's Skript (mit obigem Zusatz):

Hi autoBert !

Laut AutoIt3Wrapper_Directives ist der Defaultwert für #AutoIt3Wrapper_UseX64 = N (No) !

Er muss daher eigentlich nicht extra mit #AutoIt3Wrapper_UseX64 = N angegeben werden.

#AutoIt3Wrapper_UseX64 = Y führt auch bei mir zu : "Fehler beim Öffnen der .dbf ..."

Ein Versuch kann aber nicht schaden .

EDIT oberh : Du kannst ja mal folgendes Skript ausprobieren :

#AutoIt3Wrapper_UseX64 = N

#include <Array.au3>
#include "DBF.au3"
#include <StringConstants.au3>
#include <String.au3>
#include "FileSelectFolder.au3"

; Zusammensetzen Ordner + Dateiname
Global $sFileName = @ScriptDir & "\BLP_FLAECHEN.dbf"

; Öffnen der DBF
Global $hDBF = _DBF_Open($sFileName, "rb+")
If $hDBF = 0 Then
    MsgBox(4096, "", "Fehler beim Öffnen der .dbf ..." & @CRLF)
    Exit
Else
    MsgBox(4096, "", "Öffnen der .dbf OK ..." & @CRLF)
    ConsoleWrite("Öffnen der .dbf OK ..." & @CRLF) ; *** nur für Testphase
EndIf

; Ermitteln der Datensatzanzahl
Global $iRecordCount = _DBF_GetRecordCount($hDBF)
If $iRecordCount = 0 Then
    MsgBox(4096, "", "Fehler bei der Ermittlung der Datensätze in der dbf ..." & @CRLF)
    Exit
Else
    MsgBox(4096, "", "Anzahl der DS = " & $iRecordCount & @CRLF)
    ConsoleWrite("Anzahl der Datensätze = " & $iRecordCount & @CRLF) ; *** nur für Testphase
EndIf

; Ermitteln des Indexes des Feldes "PLANZ"
Global $iField = _DBF_GetFieldIndex($hDBF, "PLANZ")
ConsoleWrite("_DBF_GetFieldIndex = " & $iField & @CRLF) ; *** nur für Testphase

Global $sPLANZ

For $i = 0 To $iRecordCount - 1
    ; Einlesen der Spalte PLANZ
    $sPLANZ = _DBF_ReadStringAttribute($hDBF, $i, $iField)
    ConsoleWrite($i & "  $sPLANZ = " & $sPLANZ & @CRLF) ; *** nur für Testphase

    If StringRight($sPLANZ, 3) <> ".FO" Then
        ConsoleWrite("==> Fehler in Datensatz " & $i & ", String endet nicht mit '.FO' ..." & @CRLF)
    Else
        $sPLANZ = StringMid($sPLANZ, 1, StringLen($sPLANZ) - 3)
        ConsoleWrite("==>  $sPLANZ = " & $sPLANZ & @CRLF) ; *** nur für Testphase
        _DBF_WriteStringAttribute($hDBF, $i, $iField, $sPLANZ)
    EndIf
Next

_DBF_Close($hDBF)

Gruß Musashi

Mal anders gesponnen, was den Hinweis von autoBert betrifft: Wenn der TE ein 64-Bit System hat, sollte er das Flag #AutoIt3Wrapper_UseX64 auf "Y" setzen und dann noch mal testen und schauen ob das Problem damit behoben ist.

Zitat von Moombas

Mal anders gesponnen, was den Hinweis von autoBert betrifft: Wenn der TE ein 64-Bit System hat, sollte er das Flag #AutoIt3Wrapper_UseX64 auf "Y" setzen und dann noch mal testen und schauen ob das Problem damit behoben ist.

Hi Moombas !

Ich habe ein 64-Bit System und das Flag testweise bereits auf Y gesetzt :

Zitat von Musashi

#AutoIt3Wrapper_UseX64 = Y führt bei mir zu : "Fehler beim Öffnen der .dbf ..."

Es geht eher darum, #AutoIt3Wrapper_UseX64 = N explizit anzugeben, obwohl es eigentlich der Defaultwert ist (sein sollte).

Letztlich ist ein Versuch mit Y bzw. N aber schnell gemacht, von daher kann oberh beide Varianten einfach ausprobieren. Wir haben ja schon ganz andere 'Besonderheiten' erlebt .

Gruß Musashi

Testumgebung :

• Ich verwende das in meinem Beitrag #24 gepostete Skript
• die Dateien BLP_FLAECHEN.dbf , FileSelectFolder.au3, DBF.au3 und DBF.dll befinden sich im selben Verzeichnis wie das Testskript (DBFTestV1.au3).

Ich habe Dir eine .Zip angehängt, die Du bitte in einem Verzeichnis Deiner Wahl entpackst, z.B.

C:\AutoItTest

Starte SciTE (hast Du ja jetzt installiert ) und öffne DBFTestV1.au3 . Anschließend lasse das Skript innerhalb von SciTE mit F5 laufen. Was passiert ?

Gruß Musashi

Zitat von oberh

Hi Musashi !

Habe es gerade auf meinem privaten Rechner laufen lassen - es funktioniert. Im Laufe des Tages werde ich Dein Script Schritt für Schritt umbauen und sehen, wo es letztlich hakt.
Super! Danke vielmals!

Zitat von oberh

Es reicht schon, wenn ich aus dem Testordner die dbf.au3 und dbf.dll herausnehme und somit auf den Include-Ordner zugreifen lasse, damit es nicht mehr funktioniert.

1.

Diese Dateien im jeweiligen Skriptordner (und nicht im Standard-Include-Ordner) abzulegen, halte ich eh für die bessere Wahl.

2.

Obwohl es jetzt läuft würde ich Dir dennoch empfehlen, auch die von BugFix angekündigte Lösung in Betracht zu ziehen. ( funkey ist ein durchaus renommiertes Mitglied, aber die UDF+DLL haben schon einige Tage auf dem Buckel )

Ich selbst habe seit Ewigkeiten nichts mehr mit DBase gemacht, wohl aber mit PostgreSQL. Auch ich verwende dabei vorzugsweise die allgemeingültigere Treiberlösung (ADO-ODBC).

Gruß Musashi

Das das Skript nicht mehr funktioniert, wenn die .dll fehlt ist (aus meiner Sicht) doch logisch.

Ich würde dir empfehlen:

Kompiliere dein Skript (mit F7) als *.exe

Dann besteht dein Programm nur noch aus der *.exe und der *.dll (und erfordert kein autoit bzw. Scite zur Ausführung auf den jeweiligen Rechnern)

Die *.dbl-Datei lässt du ja jedesmal manuell angeben und gehört ja nicht zum eigentlichen Programm.

Ggf. solltest du dafür dann jedoch evtl. eine kleine GUI bauen (es reicht ja eine Edit in das du rein schreibst) anstatt der Konsolenausgabe (denn diese passiert dann natürlich nicht) um eine Rückmeldung für den Benutzer zu haben oder halt eine MSG-Box-Ausgabe wegen evtl. Fehler oder Gesamt-Erfolg machen.

Zitat von Moombas

Dass das Skript nicht mehr funktioniert, wenn die .dll fehlt ist (aus meiner Sicht) doch logisch.

Nicht nur aus Deiner Sicht, sondern generell .

Ich hatte die .Dll testweise mal umbenannt und erhielt - erwartungsgemäß- sofort "Fehler beim Öffnen der .dbf ...". Daher auch meine definierte Testumgebung, damit man sicher sein kann, dass alles vorhanden ist.

Zitat von Moombas

Kompiliere dein Skript (mit F7) als *.exe [...] erfordert kein AutoIt bzw. Scite zur Ausführung auf den jeweiligen Rechnern)

Das ist natürlich das Ziel - SciTE dient nur zum Testen und Entwickeln.

Deine Idee mit der Eingabemöglichkeit für den Dateinamen der .dbf ist sinnvoll .

Gruß Musashi

Zitat von Musashi

Deine Idee mit der Eingabemöglichkeit für den Dateinamen der .dbf ist sinnvoll .

Die hatte er ja im Ursprung schon drin, hast du doch selber raus genommen zu Testzwecken^^ War also nicht meine Idee

Zitat von Musashi

...und den Pfad direkt gesetzt (damit man nicht immer durch den FileSelectFolder-Dialog durch muss ).

Zitat von Moombas

Die hatte er ja im Ursprung schon drin, hast du doch selber raus genommen zu Testzwecken^^ War also nicht meine Idee

EDIT oberh (nur zur Sicherheit) :

Wie Moombas bereits beschrieben hat, musst Du neben der .exe auch die DBF.dll beifügen. Diese Datei wird standardmäßig nicht eingebunden. Um diese Datei trotzdem mit der .exe 'auszuliefern' kannst Du sie aber mit :

FileInstall ("DBF.dll", @ScriptDir & "\DBF.dll") ; Einbinden der DLL

(zu Beginn des Skriptes) inkludieren.

Gruß Musashi

Musashi: Hab ich auch nochmal was gelernt^^

Zu deinem letzten Post oberh:

Selbst bei anderen Programmiersprachen musst du entweder den Pfad der zu verwendenden dll(s) angeben und/oder diese direkt einbinden (was bisher NICHT der Fall war, Musashi aber ja gezeigt hat wie es geht, was ich in deinem Fall auch machen würde, da dann wirklich nur die Exe benötigt wird).

Ich selber packe mir auch include-files (da gehören keine dll's dazu), die Sinn ergeben, weil sie auch auf andere Programme angewendet werden könnten (hier wäre es ja die DBF.au3), in den Standard-Include Ordner.

ABER: Bedenke das die Art und Weise wie diese angesprochen wird sich dann ändert: #include "DBF.au3" --> #include <DBF.au3>

Und das, wenn andere deine Programme mal überarbeiten müssen, sie diese "besonderen" Include-Dateien zur Verfügung haben (ich lege alle meine Includefiles in einem Verzeichnis ab, wo auch andere in der Firma drauf zugreifen können).

Verwende für eine allgemeine "Verteilung" immer nur Programme die komplett Kompiliert sind, nicht die au3 (Sourcecode). Wenn andere in der Firma die gleichen Ambitionen hat wie du, ändert er evtl. was an deinem Tool und dann knallt es ggf.

Das mit dem FileSelectFolder-Dialog haben wir ja als "erforderlich" bzw. "sinnvoll" gesehen also ist das ja durchaus richtig wie du es am Anfang hattest was diesen Teil angeht.^^

Zitat von Musashi

... damit man nicht immer durch den FileSelectFolder-Dialog durch muss ).

Zitat von oberh

Das muss leider sein, da sich dieser Pfad immer wieder ändern kann.

Ich habe den FileSelectFolder-Dialog nur für die Testphase herausgenommen, um die Analyse auf ein Minimalskript zu begrenzen. Für die Suche nach dem Problem ist dieser Teil ja nicht relevant. Das war natürlich nicht als dauerhafte Lösung gedacht, sondern kann jetzt wieder eingebaut werden .

oberh : ein kleiner Tipp am Rande bezüglich des Zitierens von Texten aus Beiträgen

Du verwendest offenbar das 'Zitat-ICON' (die Sprechblase) aus dem ICON-Header und kopierst dann den Text hinein. Das kann man machen, aber es führt dazu, dass der Name des Zitierten nicht automatisch beigefügt wird.

In diesen Fällen ist es einfacher, den Text im jeweligen Beitrag mit der Maus zu markieren :

Er erscheint dann die Box Zitat speichern / Zitat einfügen

Hier kannst Du nun das Zitat speichern (auch mehrere). Im Editor gibt es danach die Anzeige :

Aus dieser Liste kannst Du Zitate auswählen und in Deinen Beitrag einfügen.

Da bei Dir vermutlich noch weitere Fragen aufkommen werden, mag dies nützlich sein .

Moombas (nur um etwaigen Missverständnissen vorzubeugen) :

FileInstall bindet Dateien wie Grafiken oder hier eine .dll in das Skript ein, und extrahiert sie beim Programmstart in das angegebene Verzeichnis. Sie ist danach also als eigenständige Datei vorhanden, so, als ob Du sie 'normal' beigelegt hättest.

Dies unterscheidet sich von einem #include, bei dem die inkludierte UDF ein Teil des Hauptskriptes wird !

Gruß Musashi