oError:genCode : 8999

[Tom]

Nein, das geht:

Code: Alles auswählen

test->name = 'Test' 
? test->name // 'Test'

Sollte man nicht machen, funktioniert aber.

[brandelh]

= und := sind bei der Zuweisung identisch, allerdings ist := eindeutig eine Zuweisung und = kann auch ein Vergleich sein, ein kleiner Syntaxfehler und man wundert sich
PS: ich nutze normalerweise immer REPLACE und nur in codeblocks dann := aber einen Kommentar // replace.
So kann ich leicht suchen wo überall Felder überschrieben werden ...

[Tom]

FieldPut() nicht zu vergessen. Das benutze ich häufig in Codeblöcken. ":=" wird bei mir (fast) nur verwendet, wenn es um Variablenzuweisung geht.

[Scarmo]

Und schon wieder etwas gelernt! =D>

Marco

[Jan]

Ich benutze fast ausschließlich ":=", egal ob Variablenzuweisung oder Feld füllen. REPLACE ... WITH ... macht mir persönlich den Code durch den langen Text zu unübersichtlich, lenkt von den Feld- oder Variablennamen ab. Ist natürlich meine ganz persönliche Meinung. FieldPut() benutze ich eher selten, z. B. wenn ich Inhalte aus einer Datenbank in eine andere Übertragen will, ohne die Feldnamen vorher zu kennen.

Jan

[AUGE_OHR]

Meine Frage war retorisch

mein Antwort auch

aber deine dauernde Erwähnung, dass alles mit SMB2 / Win7/8 im NETZWERK zusammenhängt, erweckt bei Neueinsteigern den Eindruck,

scheinbar habe ich es nicht verständlich genug dargestellt wenn bei dir oder Jan der Eindruck entsteht.

selbstverständlich weise ich beim aktuellen OS(), also Win7 / 8.x auf SMB2 hin ... SMB1 ist ja auch noch vorhanden und neuerdings auch SMB3 (v2.3).
und NEIN ich will das ganze Thema nicht noch mal tippen, dazu kann man sich ja die vorhandenen Threads ansehen.

die Sache mit dem 8999 ist doch das er nicht immer und nicht in jeder Konfiguration auftritt.
mit XP SP3 / Srv2003 hatte man das SMB1 Problem mit 8999 "im Griff" und dann kam mit Win 7 ( Vista hatte kaum jemand ) und SMB2 erneut 8999

warum läuft der Dual-fähige Source mit Cl*pper und den selben Bedingungen ?
wäre es im Netzwerk noch verständlich aber wieso gibt es auch Lokal diese 8999 ?

wenn du eine besser verständliche Erklärung für die "möglichen" Auswirkungen auf eine Cl*pper vs. Xbase++ Applikation hast ... her damit.

dass ein LOCK erst beim zweiten Benutzer im Netzwerk nötig wird.

ich habe von einem expliziten DbRlock(nRec) gesprochen und dargestellt das Xbase++ DbAppEnd() / NetErr() / Rlock() nicht verlässlich ist !

Ich will nur darauf hinweisen, dass jede Datei die NICHT exclusive geöffnet wird, bei jedem Schreibzugriff immer gesperrt werden muss, entweder mit RLock()/FLock() oder automatisch bei dbAppend() / APPEND BLANK oder geänderter Locking Einstellung der DBE. Auch auf einem Rechner ohne Netzwerkkarte.

so langsam kommst du wieder zum Punkt : automatisch -> "eigentlich" kein zusätzliches DbRlock(nRec) notwendig !

Jimmy sagt : unter Xbase++ sollte man nach dem NetErr() noch "explizit" ein DbRLock(nRec) ausführen.

Code: Alles auswählen

      TESTOPS->( DbAppend() )
      IF NetErr()
         TONE(1234)
         nError++
         BREAK
      ELSE
         nRec := TESTOPS->(RECNO())
         IF TESTOPS->(DbRLock(nRec))
            REPLACE ...
            TESTOPS->(DbRUnlock(nRec))
            //
            // need for Win7 "original" if other have SP1 RC
            //
            TESTOPS->(DbSkip(0))
         ELSE
         ENDIF
      ENDIF

[ramses]

Hi

der Fehler 8999 hat mich lange auch durch solch sporadische Dinge geärgert. Nach langem Abwägen habe dann meine Fehlerroutine geändert, so dass diese bei einem 8999 Fehler zuerst nach einem kurzen Sleep von einigen 1/100 Sek. 5 Mal ein retry Versucht bevor ein Fehler ausgegeben wird. Seit dieser Anpassung meiner errorsys() habe ich nie mehr von einem Kunden einen 8999 Fehler gemeldet bekommen......

Cu Carlo