ErrorSys.Prg erweitern

Sonstiges (nicht kategorisierbar)

Moderator: Moderatoren

Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Danke, Jimmy!
AUGE_OHR hat geschrieben:nun deutet der "Fehler BASE/5" aber eher auf eine DBF Operation was in Zeile 358 das "CLOSE ALL" wäre ...
Das leuchtet ein, das andere halte ich auch für eher unwahrscheinlich.
Aber weshalb sollte CLOSE DATABASES zu einem Fehler führen?
Frage : arbeitest du mit RELATION ?
Nein.
statt "Close Database" kannst du auch deine eigene Function schreiben siehe c:\ALASKA\XPPW32\SOURCE\SYS\AppExit.prg ( wo allerdings die RELATION fehlen)
Ich dachte bisher nicht, dass es nötig wäre, aber danke.
siehst du in der original c:\ALASKA\XPPW32\SOURCE\SYS\ErrorSys.prg ein ALERT() ?
Ja, Zeile 129 im Original (der 1.9 SL1). Wird bei mir halt auf Zeile 158 geschoben, sonst aber ohne Veränderungen.
der rekursive Fehler liegt IMHO im ALERT()
yes, den suche ich ja noch.
ich sehe ein Problem, dass du es "erst" in der "1st" Errorsys abfängst.
wenn du bei USE / CLOSE etc. ein Problem hast würde ich die entsprechenden Befehle in eine Function schreiben und das mit einer "2nd" Errorsys und BEGIN / SEQUENZ ausstatten ... und einem Logfile.
Bisher hatte ich keine solchen Probleme (soweit ich weiss). Zum öffnen verwende ich eine 'Net_Use()'-UDF.
Ist mir schon klargeworden, dass solche Functions an kritischen Stellen besser wären, aber ich fand es halt einfacher, einzelne solche Fehlerquellen in einer älteren App zentral zu lösen (wenn es denn klappt).
Oder eben man geht es so an, wie Tom (in einem andern Thread) schrieb (über Präprozessor).
Zuletzt geändert von Daniel am Mo, 08. Dez 2014 11:40, insgesamt 1-mal geändert.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:
siehst du in der original c:\ALASKA\XPPW32\SOURCE\SYS\ErrorSys.prg ein ALERT() ?
Ja, Zeile 129 im Original (der 1.9 SL1). Wird bei mir halt auf Zeile 158 geschoben, sonst aber ohne Veränderungen.
ok ... aber da steht auch

Code: Alles auswählen

   IF AppType() <> APPTYPE_PM

      /* Anzeige mit Alert() Box m”glich ?*/
      IF SetAppWindow() != NIL
         i   := 0
         row := Row()
         col := Col()
         DO WHILE i == 0                     
            i := Alert( cMessage, aOptions )
und nun probiere mal das

Code: Alles auswählen

PROCEDURE Main
LOCAL nEvent, oXbp, mp1, mp2

   NewForm():New():Create()

ALERT("Hallo")

   nEvent := xbe_None
   WHILE nEvent != xbeP_Close
      nEvent := AppEvent ( @mp1, @mp2, @oXbp )
      oXbp:HandleEvent ( nEvent, mp1, mp2 ) 
      IF nEvent == xbeP_Quit
         QUIT   // AppQuit()
      ENDIF
   ENDDO

RETURN

PROCEDURE APPSYS
RETURN
das ist ja Code wie ihn der Formdesigner erzeugt wo ich eine ALERT() eingefügt habe.
die APPSYS ist ja für eine "Full-GUI" Standard (ich gehe mal davon aus das es "Full-GUI" ist)
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:ok ... aber da steht auch

Code: Alles auswählen

   IF AppType() <> APPTYPE_PM

      /* Anzeige mit Alert() Box m”glich ?*/
      IF SetAppWindow() != NIL
            ...
            i := Alert( cMessage, aOptions )
...
... die APPSYS ist ja für eine "Full-GUI" Standard (ich gehe mal davon aus das es "Full-GUI" ist)
Die Applikation ist relativ alt, sie ist im Hybrid-Modus, noch kein GUI. Somit sollte die erste Bedingung erfüllt sein. Doch wie steht es mit der zweiten, SetAppWindow()?

(Ich will die App neu schreiben, doch bis dahin muss ich ja die Fehler irgendwie abfangen)
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:sie ist im Hybrid-Modus, noch kein GUI.
Somit sollte die erste Bedingung erfüllt sein.
em ... äh ... Hybrid ... dann hast du doch /PM:PM verwendet und die Bedingung

Code: Alles auswählen

IF AppType() <> APPTYPE_PM
wäre NICHT erfüllt und du darfst KEIN ALERT() benutzen was IMHO zu deinem rekursiven Fehler in der Errorsys führt.
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:em ... äh ... Hybrid ... dann hast du doch /PM:PM verwendet und die Bedingung "IF AppType() <> APPTYPE_PM" wäre NICHT erfüllt ...
Äh ... nein, ich habe "GUI = NO" gesetzt (u.a. weil sonst das CRT-Fenster auf einem grossen Screen zu klein ausfällt).
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Äh ... nein, ich habe "GUI = NO" gesetzt
uuuuups ... dann "sollte" ein ALERT() ja funktionieren.
wie schon gesagt würde ich versuchen die "Netzwerk" Function selbst mit BEGIN / SEQUENCE abzusichern um schon dort ein "Fehler" abzufangen.

... besser wäre es natürlich man könnte die "Ursache" (Antivirus/SMBx) beseitigen.
Daniel hat geschrieben:(u.a. weil sonst das CRT-Fenster auf einem grossen Screen zu klein ausfällt).
das sollte doch wirklich kein Problem sein da du doch "nur" die APPSYS.PRG an den gewünschten Font anpassen musst ... aber das ist ein anderes Thema.
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Eben, das ist alles sehr seltsam, dieser Fehler ist nicht erklärbar.
Und so komme ich zum Schluss, dass man am ErrorSys.prg möglichst NICHTS ändern sollte.
Obwohl - ich habe auch sonst noch Errormeldungen, die fast nichts aussagen ... #-o

Klar, ich sehe schon, dass man alle möglichen Fehler möglichst schon vorher abfangen sollte. Aber da muss man das ganze Programm durchgehen und die Funktionen überall einbauen. Doch ich will eigentlich an diesem alten Programm nicht mehr gross herumflicken, sondern das im nächsten Jahr irgendwann neu zu machen beginnen.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: ErrorSys.Prg erweitern

Beitrag von Jan »

Hallo Daniel,

Deine Schlußfolgerung ist nachvollziehbar, aber falsch. Denn die errorsys ist eindeutig dazu da, erweitert zu werden. Ich selber mache das auch immer wieder, je nach Bedarf mit den unterschiedlichsten Erweiterungen (z. B. automatischer Mailversand der Fehlermeldung, Anmeldename, Rechnername, usw.). Sowohl in GUI-Oberflachen als auch OEM.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: ErrorSys.Prg erweitern

Beitrag von brandelh »

genau, die ErrorSys.PRG ist als Info warum und wo ein Programm abstürzt sehr wichtig, insbesondere wenn man die dauerhaft speichert (also nicht bei jedem Fehler neu anlegt).
Wie sonst sollte man Fehler finden, die nur ab und zu im Netz auftreten und der Anwender sehr gut beschreibt mit "do geht wos ned" ;-)

Natürlich muss man bei einem Fehler in der Fehlerbehandlung mit einer Fehlerlawine rechnen, daher habe ich einen Zähler (static) eingebaut (ich meine du hättest auch sowas) und nach 10 Meldungen ist Schluss ...
Die Standardfehlermeldung nach einem Error in der Fehlerbehandlung ist aber ein XppFATAL mit STACK-Fehler (nach 1000 oder 10000 Fehleraufrufen geht der stack aus ...)

Richtig ist die Schlußfolgerung, dass man wissen muss was man tut und notfalls die eigene abschaltet um zu sehen ob der Fehler in der eigenen ErrorSys.PRG liegt oder nicht. Aber nicht dauerhaft ;-)
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Und so komme ich zum Schluss, dass man am ErrorSys.prg möglichst NICHTS ändern sollte.
Obwohl - ich habe auch sonst noch Errormeldungen, die fast nichts aussagen ... #-o
wenn man in der "1st" Errorsys landet ist es eigentlich schon "zu spät" um ein "retry" zu versuchen.
auch kann man ja nicht alle Fehler (z.b. Typo) abfangen sondern sollte je nach

Code: Alles auswählen

oError:osCode
schon vorher erfolgen "wenn" ein "retry" möglich ist.
Daniel hat geschrieben:Klar, ich sehe schon, dass man alle möglichen Fehler möglichst schon vorher abfangen sollte.
Aber da muss man das ganze Programm durchgehen und die Funktionen überall einbauen.
ich habe meine Netzwerk Functionen alle in einem PRG was für solche Aktionen hilfreich ist ;)
Daniel hat geschrieben:Doch ich will eigentlich an diesem alten Programm nicht mehr gross herumflicken, sondern das im nächsten Jahr irgendwann neu zu machen beginnen.
klar kann man bei einem neuen Projekt solche Überlegungen gleich einplanen aber auch eine "Full-GUI" Anwendung wird dir bei "dem" Problem nicht helfen.
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:ich habe meine Netzwerk Functionen alle in einem PRG was für solche Aktionen hilfreich ist ;)
Ja, hab' ich eigentlich auch.
klar kann man bei einem neuen Projekt solche Überlegungen gleich einplanen aber auch eine "Full-GUI" Anwendung wird dir bei "dem" Problem nicht helfen.
Ja, es gibt immer mal Fälle, die unklar sind, z.B. auch der folgende.
Allerdings bei diesem Errorlog frage ich mich, wie ich das erweitern kann, damit es Genaueres aussagt:

Code: Alles auswählen

    XBase Ver. 1.90.331 ,   Windows XP SP3
    oError: args        :         // - leer ! 
    oError: canDefault  : N
    oError: canRetry    : N
    oError: canSubstitute: N
    oError: cargo       :  NIL
    oError: description : Fehler beim Lesen
    oError: filename    :  
    oError: gencode     :  73
    oError: operation   :         // - leer !
    oError: subcode     : 8999
    oError: subsystem   : BASE
    oError: thread      : 1
    oError: tries       : 0 
Anhand des Callstack kann ich zwar in etwa feststellen, wo der Fehler auftritt, doch finde ich es seltsam, dass weder 'args' noch 'operation' einen Inhalt haben. Auch 'filename' ist in fast allen Fällen leer, auch wenn es - wie hier - um DB-Operationen geht. - wieso eigentlich?
- Ermittelt werden die Angaben ja aus dem Error-Object, in diesem Fall 'oError:fileName'.

Die Beschreibung 'Fehler beim Lesen' führt ja sofort zur Frage lesen wovon?.
Vielleicht kriege ich das so raus?

Code: Alles auswählen

if ValType( ALIAS() ) <> "U"
    cErrLog += "aktuelle Datei : " +ALIAS()
endif
Dann ev. noch die RECNO() ermitteln.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Allerdings bei diesem Errorlog frage ich mich, wie ich das erweitern kann, damit es Genaueres aussagt:

Code: Alles auswählen

    XBase Ver. 1.90.331 ,   Windows XP SP3
    oError: args        :         // - leer ! 
    oError: canDefault  : N
    oError: canRetry    : N
    oError: canSubstitute: N
    oError: cargo       :  NIL
    oError: description : Fehler beim Lesen
    oError: filename    :  
    oError: gencode     :  73
    oError: operation   :         // - leer !
    oError: subcode     : 8999
    oError: subsystem   : BASE
    oError: thread      : 1
    oError: tries       : 0 
Anhand des Callstack kann ich zwar in etwa feststellen, wo der Fehler auftritt, doch finde ich es seltsam, dass weder 'args' noch 'operation' einen Inhalt haben. Auch 'filename' ist in fast allen Fällen leer, auch wenn es - wie hier - um DB-Operationen geht. - wieso eigentlich?
- Ermittelt werden die Angaben ja aus dem Error-Object, in diesem Fall 'oError:fileName'.

Die Beschreibung 'Fehler beim Lesen' führt ja sofort zur Frage lesen wovon?.
du solltest den Callstack mitliefern ... und ein wenig Code ist immer nützlich.

das oError:args und oError:filename "leer" sind ist nicht unbedingt ungewöhnlich.
der oError:subcode 8999 mit dem oError:gencode 73
Associated with: "73:Error while reading a file"
Caused by: "DbUseArea()", "OrdListAdd()", "DbSkip()", "DbSeek()"
Frage : was für ein OS() hat der "Server" ?

ist in dem XP PC eine "on-Board" Lösung ? wenn als Steckplatz dann mal prüfen ob die noch richtig drin sitzt.

ansonsten wohl ein Netzwerk Problem von XP Sp3 Redirector wenn der "Server" ein Windows 7 PC ist ... er hat die Connection "verloren"

p.s. wenn ich mich recht erinnere sind in der v1.90.331 sind die Netzwerk "Timeout" Werte "anders" als in der 1.9.355. überprüfe doch mal die Werte

Code: Alles auswählen

// ohne 3rd Parameter
? DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY)
? DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY)
nachdem du eine DBF / NTX geöffnet hast
Daniel hat geschrieben:Vielleicht kriege ich das so raus?

Code: Alles auswählen

if ValType( ALIAS() ) <> "U"
    cErrLog += "aktuelle Datei : " +ALIAS()
endif
Dann ev. noch die RECNO() ermitteln.
ich habe in meiner ErrorSys das "vor" dem oError Object noch stehen

Code: Alles auswählen

   ? "Alias()             :", IF( USED(), ALIAS(), "leer" )
   ? "Select()            :", LTRIM( STR( SELECT() ) )
   ? "Recno()             :", IF( USED(), LTRIM( STR( RECNO() ) ), "leer" )
   ? "Found()             :", IF( FOUND(), "YES", "NO" )
   ? "NetError()          :", IF( NETERR(), "YES !!!", "NO" )
   ? "IndexOrd()          :", LTRIM( STR( ORDNUMBER() ) )
   IF ORDNUMBER() > 0
      ? "Indexfocus()        :", ORDSETFOCUS()
      ? "Indexname()         :", ORDNAME()
      ? "Indexkey()          :", ORDKEY()
   ENDIF
   IF USED()
      ? "DBO_ALIAS           :", DbInfo( DBO_ALIAS )
      ? "DBO_FILENAME        :", DbInfo( DBO_FILENAME )
      ? "DBO_ORDERS          :", LTRIM( STR( DbInfo( DBO_ORDERS ) ) )
      ? "DBO_RELATIONS       :", LTRIM( STR( DbInfo( DBO_RELATIONS ) ) )
      ? "DBO_SHARED          :", IF( DbInfo( DBO_SHARED ), "YES", "NO" )
      ? "DBO_REMOTE          :", IF( DbInfo( DBO_REMOTE ), "YES", "NO" )
      ? "DBO_SERVER          :", IF( DbInfo( DBO_SERVER ), "YES", "NO" )
      ? "DBO_DBENAME         :", DbInfo( DBO_DBENAME )
      ? "BOF()               :", IF( BOF(), "YES", "NO" )
      ? "EOF()               :", IF( EOF(), "YES", "NO" )
   ENDIF

   aWSL := WorkSpaceList()
   nWSL := LEN( aWSL )
   ? "WorkSpaceList       :", ""
   FOR j = 1 TO nWSL
      ? aWSL[ j ]
      aLock := ( aWSL[ j ] )->( DBRLOCKLIST() )
      nLock := LEN( aLock )
      IF nLock > 0
         FOR k = 1 TO nLock
            IF k = 1
               ?? " : Record No. " + LTRIM( STR( aLock[ k ] ) )
            ELSE
               ?? "," + LTRIM( STR( aLock[ k ] ) )
            ENDIF
         NEXT
         ?? " locked"
      ELSE
         ?? " : NO Record locked"
      ENDIF
   NEXT

   ? REPLICATE( "-", 78 )
   ? ""
   // welche DLL Version von wo geladen
   DLLLIST()

   ? ""
   ? REPLICATE( "-", 78 )
   ? "oError:args         :"
   // hier geht es weiter mit den original oError
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:du solltest den Callstack mitliefern ... und ein wenig Code ist immer nützlich.
Klar, mir ging es zuerst mal darum, wie man das ErrorSys so erweitern kann, dass es mehr aussagt.
Hier also der im Callstack "(2732)" angesprochene Code und die Zeilen davor:

Code: Alles auswählen

     Select 4
     IF Net_Use("Liefer", .F. , 30 )
        Set Index to LiefNr
        nLief := -1
(2730)  DO WHILE ! EOF()
(2731)  *--- doppelte ? ---
(2732)    if lieferNr ==nLief .and. nLief >0 
dass oError:args und oError:filename "leer" sind ist nicht unbedingt ungewöhnlich.
der oError:subcode 8999 mit dem oError:gencode 73
Associated with: "73: Error while reading a file"
Caused by: "DbUseArea()", "OrdListAdd()", "DbSkip()", "DbSeek()"
Eben, da geht es ja um eine DB ("LIEFER.DBF"), warum also ist 'filename' leer? - Besser, wie kann ich die betreffende DB anzeigen? - Gut - dazu gibst du ja (weiter unten in deiner Antwort) ein Beispiel, danke -
[ ---> Ich nehme den Teil zum NETZWERK / SERVER hier raus nach unten (extra) <--- ]
Zuletzt geändert von Daniel am So, 14. Dez 2014 11:51, insgesamt 1-mal geändert.
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Anmerkung:

Ich musste meinen Beitrag vom 11. Nov. (oben, Seite 1) korrigieren,
denn es war ein Fehler drin bezüglich des Return-Codes.
( - dies auch für den Fall, dass das jemand anwendet)
Zuletzt geändert von Daniel am So, 14. Dez 2014 11:53, insgesamt 1-mal geändert.
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

= = => Ich nehme den Teil zum NETZWERK / SERVER hier extra <===
Frage : was für ein OS() hat der "Server" ?
Win Server2008
ist in dem XP PC eine "on-Board" Lösung ? wenn als Steckplatz dann mal prüfen ob die noch richtig drin sitzt.
was meinst du genau, dass der Netzwerkadapter "on-Board" eingebaut ist - oder als Steckkarte? - Das müsste ich den Kunden fragen.
ansonsten wohl ein Netzwerk Problem von XP Sp3 Redirector wenn der "Server" ein Windows 7 PC ist ... er hat die Connection "verloren"
- P.S.: wenn ich mich recht erinnere sind in der v1.90.331 sind die Netzwerk "Timeout" Werte "anders" als in der 1.9.355. überprüfe doch mal die Werte

Code: Alles auswählen

// ohne 3rd Parameter
? DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY)
? DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY)
nachdem du eine DBF / NTX geöffnet hast
kann ich auch erst machen, wenn ich mal wieder dorthin gehe (nicht gerade in der Nähe).

- Vielen Dank für das Sample, Jimmy!
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Hier also der im Callstack "(2732)" angesprochene Code und die Zeilen davor:

Code: Alles auswählen

     Select 4
     IF Net_Use("Liefer", .F. , 30 )
(2728)  Set Index to LiefNr
(2729)  nLief := -1
(2730)  DO WHILE ! EOF()
(2731)  *--- doppelte ? ---
(2732)    if lieferNr ==nLief .and. nLief >0 
Eben, da geht es ja um eine DB ("LIEFER.DBF"), warum also ist 'filename' leer?
ich nehme mal an das lieferNr ein Feld ist ?

Code: Alles auswählen

if Liefer->lieferNr = nLief
   IF nLief >0 
wenn man ein Fehler in einer Zeile hat die mehrere Anweisungen enthält dann würde ich die zum testen "zerlegen"

ein FELD sollte man mit ALIAS-> angeben ( compiliere mit /W )
mit dem "=" gegenüber "==" könnten sich andere "Ergebnisse" ergeben. bei einer INT Nummer reicht ein "="

den (gesamten***) Index in Zeile 2728 würde ich in der Net_Use() integrieren

Code: Alles auswählen

   USE (file_dbf) VIA "DBFNTX"
   IF .NOT. NETERR()
      DO CASE
         CASE "LIEFER" $ UPPER( file_dbf )
            SET INDEX TO &ZLIEFNR, &ZLIEFDRU, &ZLIEFDT, &ZLFARTNR, &ZLFKD, &ZLKDART, &ZLKDRECH, &ZLLLTEMP, &ZLIEFUNI
      ...
und in Zeile 2728 steht dann

Code: Alles auswählen

SET ORDER TO 1   // erster Index aktive
***alle zu einer DBF gehörenden Index immer gemeinsam öffnen.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: ErrorSys.Prg erweitern

Beitrag von AUGE_OHR »

Daniel hat geschrieben:
ist in dem XP PC eine "on-Board" Lösung ? wenn als Steckplatz dann mal prüfen ob die noch richtig drin sitzt.
was meinst du genau, dass der Netzwerkadapter "on-Board" eingebaut ist - oder als Steckkarte? - Das müsste ich den Kunden fragen.
der XP PC ist sicherlich schon paar Jahre alt ...

die "on-Board" 100mBit Lösungen zu der Zeit waren recht stabil, aber die mit den 1Gbit kamen erst auf ...
ich habe schon Steckkarten gesehen die von dem Netzwerk Kabel "ausgehebelt" wurden und nur 1/2 drin stecken.
Daniel hat geschrieben:
Frage : was für ein OS() hat der "Server" ?
Win Server2008
also dann ist es das XP Sp3 Redirector Problem.

ich einfachste Lösung : weg-schmeissen und einen Win7 PC kaufen ;)
gruss by OHR
Jimmy
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:ich nehme mal an das lieferNr ein Feld ist ?
ja.

Code: Alles auswählen

if Liefer->lieferNr = nLief
   IF nLief >0 
wenn man ein Fehler in einer Zeile hat, die mehrere Anweisungen enthält dann würde ich die zum testen "zerlegen"
- mit dem "=" gegenüber "==" könnten sich andere "Ergebnisse" ergeben. bei einer INT Nummer reicht ein "="
- ein FELD sollte man mit ALIAS-> angeben ( compiliere mit /W )
ja, klar, heute würde ich das so machen.
Allerdings noch eine Frage:
Ist "Liefer->lieferNr" sicher, oder wäre es besser, SELECT-> anzugeben: "4->lieferNr" ?
- Weil XBase ja intern, wenn die DBF mehrmals geöffnet wird, für ALIAS() die SELECT an den Filenamen anhängt.
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

AUGE_OHR hat geschrieben:
Daniel hat geschrieben: Win Server2008
also dann ist es das XP Sp3 Redirector Problem.
Also nicht nur, wenn Win7, sondern auch immer mit Win Server2008?
- Damit muss ich mich wohl auch noch befassen #-o - möglichst bald :roll:
- wo sollte ich da schauen? Hier im Forum suchen?
ich einfachste Lösung : weg-schmeissen und einen Win7 PC kaufen ;)
hab ich ihm schon gesagt, aber jetzt will er die noch länger behalten ( - "sie laufen ja noch gut" :!: ) und dazu neue Win10 :!: PCs kaufen ... #-o :roll: :confused1: :doubt: :confused2:
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: ErrorSys.Prg erweitern

Beitrag von Jan »

AUGE_OHR hat geschrieben:also dann ist es das XP Sp3 Redirector Problem.
Hallo Jimmy,

klär mich bitte mal auf: Was ist denn das jetzt schon wieder?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Jimmy, meinst Du das hier, im Thread "Netzwerkgeschwindigkeit" ?

http://xbaseforum.de/viewtopic.php?f=24 ... =50#p75539

Ist das noch aktuell?
Wurden diese Einstellungen nicht alle sowieso mit dem XP SP3 automatisch vorgenommen?
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Habe das 'UTILITY', das die 'Responder'-Version vom Windows abfragen sollte, getestet.
- Doch ich konnte es nicht zum Laufen bringen, denn es benötigt externe FUNCtions "OnOSVersion()" und "GetShortFilename()"

Allgemein habe ich ein Problem mit solchen OS- und Netzwerk-Einstellungen,
denn erstens ist der Kunde ziemlich weit entfernt (französische Schweiz, ich fahre vielleicht 3-5mal jährl. hin), und zweitens hat er einen externen Netzwerk-Spezialisten, der für alle diese Dinge zuständig ist. (Und drittens hat er noch 2 Filialen)
Somit muss ich erstens dem Kunden, zweitens diesem "Certified Network Professional" klarmachen, was er warum wie ändern oder anpassen muss. (Und da kann ich nicht argumentieren, dass ich es in einem XBase++-Forum gelesen habe).
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: ErrorSys.Prg erweitern

Beitrag von brandelh »

Wenn die so "professionell" sind, sollte es ein leichtes sein, denen zu erklären, dass Windows XP nicht mehr unterstützt wird, insbesondere wenn eine Anbindung ans Internet besteht. :D
Gruß
Hubert
Daniel

Re: ErrorSys.Prg erweitern

Beitrag von Daniel »

Ja, stimmt, - sollte es eigentlich. Allerdings ist ja der Kunde immer König. Und da gibt er eher ihm recht als einem, der Programme immer noch mit einem unbekannten Entwicklerwerkzeug erstellt ... Und die "Zertifikate" sind ja meist von M$, da spielen Datenbank-Apps kaum eine Rolle.
Aber das LAN hängt nicht direkt am Internet, es gibt dort einen Stand-alone-PC für eMail.
Wieweit Internet für welche PCs / User zugänglich ist, weiss ich nicht genau.
Na, ich hoffe, ich kann ihn doch noch dazu bringen, die XP's zu verschrotten ...
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: ErrorSys.Prg erweitern

Beitrag von brandelh »

Wobei ... mit Windows NT / Windows 2000 und einem XP Rechner (als "Dateiserver") hatte ich nie Probleme mit Dateien solange man der Netzwerkkarte den "Schlafmodus" (Energieeinstellung) verboten hatte.
Meine Netzwerkprobleme kamen, als wir auf Server 2008 umgestellt haben. Solange die Rechner nur lokal genutzt werden, sollte XP kein Thema sein.
Eventuell noch die Dateien direkt mit UNC Name öffnen: \\SERVER\FREIGABE\Pfad\Datei ...

Natürlich geht bei alten Rechnern (aber nicht nur dort) auch mal was kaputt.
Ich hatte unerklärliche Abstürze bei der Datenübertragung obwohl alle Lichter auf "OK" standen.
Nachdem ich den alten Switch getauscht hatte waren sie weg, und am Wochenende habe ich merkt, dass mein langes LAN Kabel nur noch "Orange" statt "Grün" vom Switch zugeordnet bekommen hat (10/100 statt 1000) da scheint auch ein Knick zuviel im Spiel gewesen zu sein.
Gruß
Hubert
Antworten