Inoffizielles deutsches Xbase-Forum

Halli Hallo,

der letzte Fehler noch nicht behoben, da rätsel ich schon beim nächsten Problem...

select MELLIS
dbgotop()  
copy to qqq.tmp sdf

Bei dem COPY TO bekommt sowohl der Kunde, als auch mein Kollege folgende Fehlermeldung:

Code: Alles auswählen

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: L VALUE: .T.
          -> VALTYPE: U VALUE: NIL
          -> VALTYPE: C VALUE: qqq.tmp
          -> VALTYPE: U VALUE: NIL
          -> VALTYPE: L VALUE: .F.
          -> VALTYPE: L VALUE: .F.
oError:canDefault   : J
oError:canRetry     : J
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Betriebsystemfehler
oError:filename     : 
oError:genCode      :         40
oError:operation    : DbUseArea
oError:osCode       :          1
oError:severity     :          2
oError:subCode      :          4
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von DBEXPORT(272)
Aufgerufen von _DBEXPORT(137)
Aufgerufen von MELLISDISKETTE(4556)
Aufgerufen von MELLISAUSG(4535)
Aufgerufen von BATCH32A(283)
Aufgerufen von BATCH32(261)
Aufgerufen von (B)MAINDLG:_ADDACTIONITEMS(0)
Aufgerufen von TACTION:EXECUTE(1620)
Aufgerufen von (B)TACTION:ADDMENU(1602)
Aufgerufen von APPLICATION:RUN(444)
Aufgerufen von MAIN(62)

Und 3mal dürft ihr raten: Bei mir läufts natürlich einwandfrei

. Auch mit den selben Daten, die mein Kollege nutzt.

Woran kann es liegen?

Die entsprechende Zeile in der Funktion DBEXPORT() (Standard XBase, nicht überschrieben. Quelltext aus dbbulk.prg im Source\Sys Ordner) ist

Code: Alles auswählen

USE (cFile) NEW EXCLUSIVE

Ich bin -mal wieder- ein wenig ratlos...

Was ich bei meinem letzten Eintrag dieser Art gelernt hatte:
Antiviren-Programm entweder gleich für das entsprechende Verzeichnis ausschalten oder zumindest die dbf und ntx oder cdx auch.

Hm, die Idee ist nicht schlecht, war mir grade auch fast sicher, dass es daran liegt...Haben den Virenscanner beim Kollegen deaktiviert, Fehler kommt trotzdem...

Moin,
bezogen auf SDF gibt es bei Alaska eine neuere (naja, mittlerweile auch nicht mehr) Version einer DLL-Datei! Vielleicht ist die auf Deinem PC ja drauf, auf den anderen ist sie noch älter?
Gibt es auch einen Eintrag in der Knowledgebase zu...

Viele Grüße,
Martin

Bitte schön: ftp://ftp.alaska-software.com/acsn/sdfdel.zip

Viele Grüße,
Martin

Hallo Martin,

vielen Dank für den Tipp! "Eigentlich" sollten die Versionen bei meinem Kollegen und mir identisch sein, aber prüfe ich mal nach. Weißt du, welche die entsprechende Datei ist?

Was kann ich mit dem ZIP-Archiv machen, d.h. wie binde ich das ins Programm ein? Da SDF / DBExport noch an vielen anderen Stellen im Programm genutzt wird, möchte ich ungern was zerschiessen...

Moin,
das waren die *DBE.DLL-Dateien (SDFDBE/DELDBE/...)
Schau Dir das Programm einfach mal an - da ist beschrieben, wie man die Probleme mit SDFDBE umgehen kann. Liegt in der ACSN.

Viele Grüße,
Martin

Also habe mal etwas rumgeforscht und schließe die DLL-Versionen aus folgendem Grund aus:

Auf einem unserer Entwicklungserver liegt eine Installation unserers Programm. Starte ich das Programm auf dem Server und versuche die Übertragung der Schnittstellendatei, bricht das Programm mit der oben stehenden Fehlermeldung ab.

Starte ich es von meinem PC (ich habe die Alaska Ordner vorher alle umbenannt und der Process Explorer + Dependency Walker zeigt keine Dateizugriffe auf meinem PC an [mal von den Windows eigenen DLLs abgesehen]) läuft alles eindwandfrei durch.

Die Virenscanner Idee scheint mir noch am plausibelsten. DBCreate() erzeugt die SDF Datei, Virenscanner bemerkt das und scannt sie und der USE EXCLUSIVE schlägt fehlt....Aber bei mir ist der Virenscanner nicht anders konfiguriert, als bei meinem Kollegen. Auch die komplette Deaktivierung bei Ihm führt nicht weiter....

Die SDFDBE und die DELDBE haben so ihre Besonderheiten, z.B. Steuerdateien und fixe Satzlängen.
Es gibt wohl eine flexiblere Version auf dem Alaska Server, aber ich ziehe es vor die SDF und DEL Dateien selbst zu erzeugen.
Entweder mit set alternate to ... und ? wie unter clipper, mit fopen(), fwrite() etc. oder aber mit einer Stringvariablen die die ganzen Daten sammelt und mit Memowrit() oder str2file() (Tools oder Wissensdatenbank) alles auf einmal schreibt. Bis zu 200 MB ist das letzte gar kein Problem und sehr schnell, der Rest kann Dateien bis 2 GB erzeugen ...

Die ganze Funktion sieht so aus:

Code: Alles auswählen

Function Uebergabe()
**Aenderungen zwecks Performance
    private buffer, ibytes

    select MELLIS  
      
    copy to qqq.tmp sdf
                          
    
    buffer = space(67)
    ibytes = 0
    din = fopen("qqq.tmp",0)
    dout = fcreate(cdatei,0)
    do while .T.
        ibytes = fread(din, @buffer,66)
        if ibytes # 66
            * bei Null Dateiende
            fclose(din)
            fclose(dout)
            erase qqq.tmp
            *Löschen der erstellten Sätze
            select MELLIS
            go top
            copy to sichmell.dbf
        
            zap
            return .t.

            exit
        endif
        fwrite(dout, buffer, 64)
    enddo

    fclose(din)
    fclose(dout)

    erase qqq.tmp
    *Löschen der erstellten Sätze
    select MELLIS
    go top
    copy to sichmell.dbf

    zap

return  .T.

Dann bleibt mir wohl nichts anderes übrig, als es umzuschreiben...Habe auch keine Ahnung, warum es damals so gemacht wurde...

Manchmal nützt es nichts, nur den Virenscnanner für das Verzeichnis auszuschalten.
Gerade bei Kaspersky gibt es Besonderheiten, mal im Forum hier suchen.
Die Probleme treten auch immer nur dann auf, wenn eine Datei
neu erstellt werden soll (z.B. wie bei Dir die SDF, oder Index)

Hm, bei uns im Unternehmen läuft McAfee, den Scanner haben wir auch komplett deaktiviert...Außerdem wunderts mich, dass es bei mir geht...

hi mirco

schreibrechte vielleicht ??

Hab ich auch als Idee gehabt, aber das Programm schreibt ja noch an vielen anderen Stellen...Außerdem passiert der Fehler ja in der internen XBase Funktion, DBCreate() klappt, datei wird auch angelegt, allerdings schlegt der USE NEW EXCLUSIVE fehl...Bin wirklich ratlos.

Ich meine klar, könnte es umschreiben...aber das kann ja nicht Sinn der Sache sein, oder?

Hi,

in deinem Beispiel finde ich keinen USE NEW EXCLUSIVE

Ansonsten muss man bei USE etc. immer mit einem Problem rechnen und danach auf NETERR() abfragen

In der Doku steht dazu

Zitat aus Hilfe hat geschrieben: USE...EXCLUSIVE Datei ist von einem anderen Nutzer bereits exklusiv geöffnet.

Die Erklärung stimmt zwar nicht ganz, es müsste heißen:

Zitat aus Hilfe hat geschrieben: USE...EXCLUSIVE Datei ist von einem anderen Nutzer bereits geöffnet.

Wenn auch nur irgendein Programm die Datei gerade geöffnet hat (Virenscanner, Indexer, anderer Thread, ...) wird neterr() True zurückliefern.
DAS ist aber noch kein Beinbruch, du könntest dann eine kleine Schleife nachschalten, die bei jedem Neterr() ein Sleep(5) oder Sleep(10) einbaut und diese auf 5 Versuche beschränken.
Danach eine Fehlermeldung ausgeben und du vermeidest die XppError.log und den Programmabbruch.

Hey,

nur kurz zur "Klarstellung": Der Fehler tritt ja in der internen Funktion von XBase auf. Ich rufe den Befehl COPY TO auf. Dieser interne Befehl von XBase ruft ja DBExport auf. In den XBase Sourcen konnte ich diese Funktion finden und dort wird die Datei mittels DBCreate() erstellt und mit USE NEW EXCLUSIVE geöffnet. Ich kann ja gar nichts machen, da ich nur COPY TO aufrufe....

Ansonsten muss man bei USE etc. immer mit einem Problem rechnen und danach auf NETERR() abfragen

Sag das mal Alaska

Um irgendwie mit Sleep() was machen zu können, müsste ich die Funktion DBExport() ja selbst in das Projekt kompilieren.

Achso ... jetzt verstehe ich das

Natürlich kann man selbst DBExport() nutzen oder die Funktion als solche anpassen.
Nochmals die Frage nach dem Betriebssystem dieses Rechners und ob die neue Datei LOKAL oder im Netz liegt ?

Jap, klar könnte ich die einbinden. Mir gings ja so ein bisschen ums Prinzip

.

Sry, hatte die Frage überlesen.

Also mein Kollege und ich haben Windows XP SP3, der Kunde hat sowohl Win 7, als auch Win XP (auf allen getestet, immer Absturz). Einer unserer Entwicklungsserver hat Windows Server 2003, auch Absturz.

In der Regel liegt die Datei im Netz (neben allen anderen Dateien), z.B. bei dem Kunden. Mein Kollege bekommt den Absturz und die Dateien liegen lokal. Bei mir klappts immer, egal ob Datei lokal oder im Netz.

So, ich habe jetzt die entsprechende COPY TO SDF Funktion aus Martin's Post genommen (danke nochmal) und in NEWCOPY TO umbenannt. So werkelt die Funktion jetzt erstmal nur an der Stelle, auf unserem Entwicklungsserver läuft die Übergabe nun...

Danke für die Hilfe!

Ich hatte auch in einem Programm Abstürze mit COPY TO seitdem der Kaspersky Virenscanner eingeführt wurde.
Aber nur an einem Rechner im Netzwerk. Eine Ausnahme des Programm für Kaspersky führte nicht zum Erfolg.
Erfolgreich war aber zu meiner Überraschung das Ausführen des Programms TCPOptimizer.exe an dem betroffenen Rechner.

Der Fehler durch Copy to war nur kurzfristig scheinbar behoben, dann zeigte er sich wieder.
Ich habe auch die Funktion von Martin genommen, vielen Dank!!!
Nun läuft alles wieder super.

Nur der Vollständigkeit halber:
Es ist nicht (!) meine Funktion - ich habe nur darauf hingewiesen, wo Alaska den "Patch" bereitgestellt hat.

Viele Grüße,
Martin

Inoffizielles deutsches Xbase-Forum

Fehler bei COPY TO

Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO

Re: Fehler bei COPY TO