ALIAS_SELECT

[AUGE_OHR]

hi,

Xbase++ version : Xbase++ (R) Version 1.90.331
Operating system : Windows 98 SE 04.10 Build 02222 A
Memory (RAM_AVAIL) : 13.31 of 131.07 MB
DiskSpace C: : 449.81 KB
Alias() : LIEFER_8
Recno() : 3495
Found() : NO
Select() : 8
IndexOrd() : 1
Indexfocus() : LIEF_NR
Indexname() : LIEF_NR
Indexkey() : FFJAHR+LIEFNR
DBO_ALIAS : LIEFER_8
DBO_FILENAME : K:\YIUIMEX\LIEFER.DBF
DBO_ORDERS : 8
DBO_RELATIONS : 0
DBO_SHARED : YES
DBO_REMOTE : YES
DBO_SERVER : NO
DBO_DBENAME : DBFNTX
WorkSpaceList : ARTIKEL, LIEFER, SOKUN, LIEFTEMP, LIEFER_8,
BESTAND_9,ABZU, CHINABMP, LOGBUCH

seit kurzem hab ich mit Win98 "komische" ALIAS() Problem s.o.
Der ALIAS Name taucht 2x in der WorkSpaceList auf und hat ein "_" mit
der Select() Area "hinten dran".
Eigendlich kann das nicht sein, den bei mir bekommt jedes ALIAS() eine
"definierte" SELECT() Area und da "LIEFER" in der WSL erscheint KANN
"eigendlich" keine "LIEFER_8" GLEICHZEITIG auf der SELECT() Area sein.

hat jemand schon mal mt Xbase++ solche "ALIAS_SELECT" gesehen ?

gruss by OHR
Jimmy

[Manfred]

Hi,

für gewöhnlich ist das von Xbase++, weil die DB ein zweites Mal geöffnet wurde, unter gleichem Namen. Aber wenn Du sagst, Du vergibst immer einen festen Alias Namen....

Hast Du schon mal im Einzelschrittmodus nachgesehen, wann die DB geöffnet wird und ob sie wirklich einen Alias von Dir bekommt?

Das wäre der erste Schritt, den ich gehen würde.

[AUGE_OHR]

hi,

für gewöhnlich ist das von Xbase++, weil die DB ein zweites Mal geöffnet wurde, unter gleichem Namen. Aber wenn Du sagst, Du vergibst immer einen festen Alias Namen....

sowas in der Art hab ich mir gedacht. Das würde z.T. den Absturz erklären

Hast Du schon mal im Einzelschrittmodus nachgesehen, wann die DB geöffnet wird und ob sie wirklich einen Alias von Dir bekommt?
Das wäre der erste Schritt, den ich gehen würde.

Nein, dazu hatte ich gestern keine Lust mehr. Aber ich glaube es immer
noch nicht, den auf dem "kurzen Weg" kann nichts passiert sein :

Code: Alles auswählen

Called from LAE2REPL(2062)
Called from LAEUM2(2015)
Called from LIEFAE(311)
Called from JOBWAHL3(123)
Called from YIUINTRO(1923)
Called from (B)CREATEMENUSYSTEM(516)
Called from MAIN(1034)

PROCEDURE MAIN
...
   CASE m_wahl == 3
      mt_nr1= 3
      hilfe := "30000"
      S_HELL()
      JOBWAHL3(oDraw,oCrt)                      // Faktura
      S_NORMAL()
...
PROCEDURE JOBWAHL3(oParent,oCrt)
...
DO WHILE .T.
...
   IF m_wahl1 > 0 .AND. m_wahl1 < 9
      IF USED()
         CLOSE DATABASE
         SELECT 26
         DO WHILE .T.
            IF USE2LOCK(zlogbuch,.F.,lock_dauer)
               EXIT
            ENDIF
         ENDDO
         SELECT 0
      ENDIF
  ENDIF

  DO CASE
   CASE m_wahl1  = 1
...
   CASE m_wahl1  = 3
...
         SELECT 8
         LIEFAE(oParent,oCrt)
         SELECT 4
...
STATIC FUNCTION  LAE2REPL(cKDNR)
LOCAL lwarschon:= .F.
LOCAL retvar   := .F.
LOCAL text0
LOCAL nRec     := LIEFTEMP->RECNO()

   DO WHILE .T.
      IF LIEFTEMP->FKDNR == cKDNR
         SELECT 8                               // zLIEFER
         IF ADDRECORD(lock_dauer) .AND. .NOT. lwarschon
               REPLACE LIEFER->FKDNR      WITH LIEFTEMP->FKDNR

und da "crasht" er dann nach einem "APPEND BLANK" kann ich kein
"REPLACE" machen :

oError:args         :
          -> VALTYPE: C VALUE: 11272
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: J
oError:cargo        : NIL
oError:description  : Datei oder Datensatz muß für Operation gesperrt sein
oError:filename     :
oError:genCode      :         76
oError:operation    : <FKDNR>:=<11272>
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       8043
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0

Ich komme also "frisch" ins Programm und wähle direkt den Menu Punkt
an. In der Sub Routine wird ein "CLOSE DATABASE" gemacht, also wenn
was offen wäre würde alles geschlossen werden.

Wärend ich bei "LIEFER" / "LIEFER_8" noch mal nachsehen muss, bin ich
mir bei "BESTAND_9" absolut sicher das die nur "einmal" geöffnet wird

Code: Alles auswählen

SELECT 9                                        // zBESTAND
DO WHILE .T.
   IF USE2LOCK(zBESTAND,.F.,lock_dauer)
      EXIT
   ELSE
      F_MELDUNG(21,zBESTAND +" konnte nicht geöffnet werden")
   ENDIF
ENDDO
...
SELECT 9                         // zBESTAND
IF ist_az_on                     // Flag zum An/Abschlalten
   DO WHILE .T.
      IF ADDRECORD(lock_dauer)
         REPLACE az_user    WITH ID_USER
...
SELECT 9                                        // zBESTAND
CLOSE BESTAND

Es gibt im dem Modul "nur" 3 Stellen wo ein "SELECT 9" vorhanden ist
sodas man das "eigendlich" schnell übersehen kann.

Das ganze ist erst jetzt mit der "latest" Version aufgetaucht die ich mit
dem "neuen PC" unter XP compile/link gemacht haben. Allerdings hab
ich "den" Codeteil seit der Umstellung von Cl*pper auf Xbase++ Hybrid
nicht mehr angefasst so das ich mir das überhaupt nicht erklären kann.

Ich hab in der Version auch keine weiter Threads eingebaut (ausser zum
drucken) sodas die auch nicht "doppelt geöffenet" sein können ...

Also erstmal Danke für die "Erklärung", ich muss wohl doch wieder den
Win98se PC reaktivieren und mal sehen ob die *.EXE eine Unterschied
aufweisen.

gruss by OHR
Jimmy

[Manfred]

Hi,

also nach einem Append Blank geht kein replace? Hm, das macht mich jetzt etwas stutzig, weil der Satz laut Doku immer sofort versucht wird zu sperren. Das scheint dann nicht zu gehen bei Dir. Also ich würde es wirklich mit dem Einzelschrittmodus probieren, dabei habe ich schon die urkomischsten Dinge entdeckt, bei denen ich vorher geschworen habe, dass kann so gar nicht sein.

Machst Du das eigentlich auch noch bei aktuellen Programmen, dass Du immer über ein Select alles anspringst? Das ist m.E. aber sehr stressig, alles immer unter Kontrolle zu behalten.

[brandelh]

Hi,

auf die Gefahr hin zu nerven, aber was bei XbpCRT gerade noch geht wird bei MDI GUI tötlich enden.

Der einzig richtige Weg ist weg von den fixen Aliasnamen und hin zu deren dynamischer Ermittlung und Speicherung in Variablen (ich nehme immer iVars des Fensters):

Code: Alles auswählen

statt
select xxx
use .... alias "XYZ"

das interessiert uns alles gar nicht, das einzige was wir wollen ist doch auf die einzelne DBF dieses Fensters bzw. auch mehrere eindeutig zugreifen zu können:

Code: Alles auswählen

use cDBF NEW
if neterr()
   // das kann passieren
   ...
endif
nAlias := select()
...
replace (nAlias)->Feldname with ...

Nur so ist es absolut sicher, dass keine Probleme auftreten auch wenn der Anwender das Fenster 1000 mal öffnet (na ja unter Win98 gehts nicht so oft).

Wenn ich die Fehlerbeschreibung zu dem dbCloseAll() noch richtig im Kopf habe war da ja auch eine Abhängigkeit zu select ..., ich hatte den Fehler noch nie, vielleicht liegt es daran dass ich so schon ewig arbeite.

PS: natürlich könnte man auch mit Alias() arbeiten, aber soweit ich weis werde die numerischen Referenzen schneller bearbeitet als die Strings.

[AUGE_OHR]

hi,

also nach einem Append Blank geht kein replace? Hm, das macht mich jetzt etwas stutzig, weil der Satz laut Doku immer sofort versucht wird zu sperren.

genau, deshalb hab ich auch zuerst an der Stelle geguckt bis mir dann
die beiden ALIAS() aufgefallen sind.

Das scheint dann nicht zu gehen bei Dir. Also ich würde es wirklich mit dem Einzelschrittmodus probieren, dabei habe ich schon die urkomischsten Dinge entdeckt, bei denen ich vorher geschworen habe, dass kann so gar nicht sein.

Ja, da komme ich wohl nicht drum rum

Machst Du das eigentlich auch noch bei aktuellen Programmen, dass Du immer über ein Select alles anspringst? Das ist m.E. aber sehr stressig, alles immer unter Kontrolle zu behalten.

Nein, der Code stammt noch auch S87 wo man ja auch "nur" 16 (?)
SELECT Bereiche hatte und ich teilweise erst ein SELECT "zumachen"
musste um noch eine DBF zu öffnen.

Nur beim "debuggen" (unter DOS/CMD) füge ich teilweise ein SELECT
hinzu weil ich sonst im Debugger nur die "aktuelle" SELECT DBF "sehe"

Was mich am meisten irritiert ist das ich solche Stellen im Code schon
ewig nicht mehr "angefasst" habe ... seit Cl*pper ... und es lief die letzten
Jahre. Das einzige was ich tatsächlich gemacht habe ist der "neue" PC
wo ich mein Backup (nicht Image) eingespielt habe und jetzt "default"
mit XP boote.

Auch habe ich NICHT die "hotfix+patch" drin, sondern verwende die
"neueren" TW.8 / TW.5 Version seit einigen Monaten ohne Probleme.

OK, danke erstmal für eure Tips.

gruss by OHR
Jimmy

[brandelh]

hi,

also nach einem Append Blank geht kein replace? Hm, das macht mich jetzt etwas stutzig, weil der Satz laut Doku immer sofort versucht wird zu sperren.

genau, deshalb hab ich auch zuerst an der Stelle geguckt bis mir dann
die beiden ALIAS() aufgefallen sind.

Hallo,

ein Append Blank und ein Use geben keinen Runtimeerror wenn was schief geht, z.B. weil ein anderer die DBF schon gesperrt hat. Nach beiden Befehlen muss man mit NetErr() prüfen ob ein Fehler aufgetreten ist.

[AUGE_OHR]

hi,

also nach einem Append Blank geht kein replace? Hm, das macht mich jetzt etwas stutzig, weil der Satz laut Doku immer sofort versucht wird zu sperren.

genau, deshalb hab ich auch zuerst an der Stelle geguckt bis mir dann
die beiden ALIAS() aufgefallen sind.

ein Append Blank und ein Use geben keinen Runtimeerror wenn was schief geht, z.B. weil ein anderer die DBF schon gesperrt hat. Nach beiden Befehlen muss man mit NetErr() prüfen ob ein Fehler aufgetreten ist.

hab ich auch, aber In der Praxis hatte ich noch nie ein NetErr() bei einem
APPEND BLANK und die "Sperre" funkktioniert immer automatisch (wenn
nicht jemand die DBF exclusive hat was nur bei ReIndex bei mir im
Programm der Fall ist.

Code: Alles auswählen

  BEGIN SEQUENCE
  bSaveErrorBlock := ErrorBlock( {|e| Break(e)} )

   m_dauer := dauer
   DO WHILE .T.
      DO WHILE m_dauer > 0

         APPEND BLANK

         IF .NOT. NETERR()
#IFDEF __XPP__
#ELSE
            SETCOLOR(m_farbe)
#ENDIF
            RETURN (.T.)
         ELSE
            INKEY (0.1)
            m_dauer := m_dauer - 0.1
            text0 := ALIAS() + " Kein APPEND ?! "
            USERPROT (text0)
         ENDIF
      ENDDO
...

Durch das APPEND BLANK muss er auch durchgegangen sein, den sonst
müsste ich was im LogBuch (USERPROT) stehen haben.

Mein erster Debug Versuch war erfolglos weil er alles so macht wie schon
unter Cl*pper ... also weiter forschen was das passiert sein könnte.

Ich habe langsam meine "neue" Machine in "Verdacht" den das ist schon
der 2st "unmögliche" Fehler den ich mit dem PC habe, also muss ich
tatsächlich mal den "alten" PC reaktivieren und sehen ob es da einen
Unterschied gibt.
Tja bei der "alten" Kiste kannte man ja die "Macken", aber bei der "neuen"
passieren doch jetzt nach einiger Zeit paar Sachen die ich noch nicht
kannte ...

gruss by OHR
Jimmy

[AUGE_OHR]

hi,

Tja so wie es aussieht war es der Server der defekt ist ... da kann ich
lange in der Software suchen

gruss by OHR
Jimmy

[Manfred]

Hi,

aber wieso werden dann diese komischen Namen vergeben? Was hat das mit der Hardware zu tun? Gibt es dafür eine Erklärung?

[AUGE_OHR]

hi,

aber wieso werden dann diese komischen Namen vergeben? Was hat das mit der Hardware zu tun? Gibt es dafür eine Erklärung?

Meinst du jetzt jetzt die "Namen" an-und-für-sich ? Dafür gäbe es eine :

DbUseArea()
...
Mehrfaches Öffnen einer Datei
Die gleiche Datei kann in mehreren Workareas geöffnet sein, die dann jeweils einen eigenen Satzzeiger verwalten. Beim Schreiben von Daten in die Felder der Datei müssen in diesem Fall Satzsperren gesetzt werden. Falls eine Datei ohne Angabe von <cAlias> mehrmals geöffnet wird, bildet Xbase++ automatisch einen eindeutigen Aliasnamen. Er besteht aus dem Dateinamen, gefolgt von einem Unterstrich und der Nummer der gewählten Workarea ( <cFileName> + "_" + LTrim(Str(Select())) )

so steht es in den Help File, warauf man mich allerdings auch erst
hinweisen musste.

Ob der "Fehler" nun wirklich "weg" ist wird gerade getestet, aber ich
habe bei "vrepair" (sowas wie ChkDsk unter Novell) zumindest eine
Fehlermeldung gehabt das da was ist (Cluster blabla ... move to).

Nun hab ich auf dem Server alle *.DBF/*.DBT/*.FTP sowie Index Files
gelöscht, gePURGE und ein "locales" Backup manuelle auf den Server
kopiert.

Wenn auch das es nicht bringt, bin ich mit meinen Ideen am Ende ...

gruss by OHR
Jimmy

[brandelh]

Hi,

ich nutze einen zweiten PC als Backup-Medium, dieser hat 3 Platten im Raid5 Verbund und ich nutze xcopy /v beim Kopieren mit Auswertung der errorlevel. Danach prüfe ich oft noch mit windiff.exe ob die Dateien gleich sind.

Vor einigen Monaten hatte ich plötzlich eine Datei, die ohne Fehlermeldung kopiert wurde, aber danach von windiff.exe als unterschiedlich in einigen Bytes gemeldet wurde (alles unter Win2000 NTFS).
Ein REORG Lauf brachte dann Unstimmigkeiten im RAID Verbund zu Tage und nach dem REPAIR ging alles wieder. Da bei aktuellen Festplatten fehlerhafte Speicherstellen gegen andere ausgetauscht werden und der SMART Test keine Fehler aufwies, vermute ich einen - von mir nicht bemerkten - Stromausfall / Stromschwankungen, die das RAID gestört haben. Nun habe ich eine kleine USV vorgeschaltet, diese filtert Spannungsschwankungen aus und gibt dem Rechner die Chance sauber herunterzufahren, wenn der Stromausfall 5 Minuten übersteigt.

[Manfred]

Hi Jimmy,

jetzt verstehe ich. Ich dachte Du hättest das gewußt mit der automatischen Aliasvergabe und es wäre ein vermuteter Hardwarefehler gewesen. Also hattest Du eine Mehrfachöffnung!? Das erklärt natürlich dann alles.

[Rolf Ramacher]

Hallo Jimmy,

also diese Probleme hatte ich bisher noch nie. Aber ich arbeite ausschließlich mit dbappend() - denn hierbei brauchst du keine Sperre.
und mit select arbeite ich auch nicht mehr. use xxx New ggf. alias dabei.
Das ersetzen mache ich immer mit z.B. splief->liefname:=(variable)

Vielleicht solltest du das doch umbauen. Kostet Zeit aber dann hast du es sauber.

[AUGE_OHR]

hi,

also diese Probleme hatte ich bisher noch nie. Aber ich arbeite ausschließlich mit dbappend() - denn hierbei brauchst du keine Sperre.

Das Problem ist ja nicht meine Funktion ADDRECORD(), die wie Hubert
auch sagte auf NETERR() prüft, sondern die "komischen" ALIAS Namen

und mit select arbeite ich auch nicht mehr. use xxx New ggf. alias dabei.
Das ersetzen mache ich immer mit z.B. splief->liefname:=(variable)

Das mache ich im Grundsatz auch so (wobei ich immer REPLACE benutze
weil ich das schneller "sehen" kann).

Vielleicht solltest du das doch umbauen. Kostet Zeit aber dann hast du es sauber.

... "never touch a running System" ...

gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

Das mache ich im Grundsatz auch so (wobei ich immer REPLACE benutze
weil ich das schneller "sehen" kann).

wie darf ich das verstehen, mit dem schneller sehen?

[brandelh]

Hi Manfred,

er meint sicher schneller finden oder erkennen ob eine Variable zugewiesen oder ein FELD replaced wird.

Ich z.B. suche in älteren Programmen gerne nach REPLACE und dem Feldnamen um die Speicherorte zu finden. Wenn man die 'modernere' Feldzuweisung nutzt, geht dies auf Kosten der Übersicht.

[Manfred]

Ach so,

da ich schon seit ewig und 3 Tagen db->feldname benutze, vermisse ich das REPLACE überhaupt nicht. Bzw. heute benutze ich nur noch Methoden, die alles in einem Rutsch schreiben oder lesen.

[AUGE_OHR]

hi,

...Bzw. heute benutze ich nur noch Methoden, die alles in einem Rutsch
schreiben oder lesen.

für neue Programme, weil GUI, setze ich auch nur noch CLASS ein.

Der Hybridcode stammt, wie ich schon sagte, noch aus S87 Zeiten
und hat inzwischen mehr als 250.000 Zeilen. Ausser das ich es "Dual SDI"
bekommen will (nur das Menu auswechseln) werde ich "die" Applikation
wohl nicht mehr "aufbohren". Man müsste schon das ganze Programm
neu in GUI schreiben ...

gruss by OHR
Jimmy

[Tom]

Hallo, Jimmy.

Jedenfalls ist es so, daß Du die gleiche Datei mehrfach öffnest, und zwar - vermutlich - in verschiedenen Workareas. Würdest Du sie in der selben Workarea öffnen, dann würde Xbase zunächst die bisher geöffnete Datei schließen.

Code: Alles auswählen

DbUseArea(.T.,,"customer")                                        
?  Alias() // Antwort: CUSTOMER                                                                                                                                                                                                                                                                                                                                                                                                                                              DbUseArea(.T.,,"customer")
? Alias() // Antwort: CUSTOMER_2

[AUGE_OHR]

hi,

Jedenfalls ist es so, daß Du die gleiche Datei mehrfach öffnest, und zwar - vermutlich - in verschiedenen Workareas. Würdest Du sie in der selben Workarea öffnen, dann würde Xbase zunächst die bisher geöffnete Datei schließen.

Da ich "feste" SELECT verwende KANN das "eigendlich" nicht sein. Die
"Bestand" DBF wird IMMER auf SELECT 9 aufgemacht. Deshalb war/bin
ich ja auch so verwirrt (gewesen)

Nun habe ich eine kleine USV vorgeschaltet ...

... und das war bei mir der "Auslöser". Stromschwankungen sind bei uns
"normal" da wir hier im Industriegebiet sitzen und das Umspannwerk nur
100m entfernt. Deshalb hatte ich auch eine USV am NW Server, doch
leider hat die "versagt". Hab mich wohl zu lange nicht darum gekümmert
(warum wenn er seit Jahren läuft ...) und dabei den "Blei Akku" vergessen
Der war nun "alle" (weil zu alt) und konnte den NW-Server wohl nicht
sauber "runterfahren" und hat wohl doch was "zerrissen".

gruss by OHR
Jimmy