Fehler mit ALIAS

[andreas]

Hallo Jan,

was sagt DBESetDefault() unmittelbar vor dem USE-Befehl?

Günter

Hallo Jan,

da du mit mehreren Thraeds arbeitest, muss du die Default-DBE für jeden Thread festlegen.

[Rolf Ramacher]

Hi Jan,

wenn du nur 2 verschiedene Sortierungen benötigst, mach es doch so.
Genauso arbeite ich auch. Klappt ohne Probleme.

zunächst erzeugst du den Index mit beiden tag-namen in einer CDX-Datei.

Hier mein Beispiel mit einer meiner Datebanken.

Index on sdkz+filiale+artnr+index tag "verteiler" to "sphaver.cdx"
Index on filiale tag "filiale" to "sphaver.cdx"

nachher im Programm:

use sphaver new
set index to "sphaver.cdx"
sphaver->(ordsetfocus("verteiler"))

Dann kannst du immer zwischendurch den tag-namen mit ordsetfocus ändern und danach dbseek starten.

[brandelh]

Hallo,

die Syntax USE ... INDEX ist sicher nur aus kompatibilitäts Gründen vorhanden. Unter cpm/dos mit dbase auf lokalem computer, was sollte da schief gehen.
Aber heute Multitasking, Multithreadding und Netzwerk, warum sollte da nichts schief gehen ?

[Jan]

So viel auf Mal

Also, das mit der DBE pro Thread hatte ich auch mal gelesen. Da ich das aber gleich beim Start erzeuge und auch immer sauber funktioniert hat, habe ich mich da nicht weiter drum gekümmert. Wie mache ich denn das korrekt?

Ich habe NettErr() probiert, gibt keinen Fehler zurück.

Den Index habe ich bereits "ausgelagert". Und in der Zeile, wo ich den Index öffne, kommt der Fehler. Auch wenn ich den Index umbenenne.

Nur zur Klarstellung: Jeder Dialog in dem Programm läuft in einem eigenen Thread. Und daher öffne ich auch in jedem Thread die genau hier benötigten Datenbanken in jedem Dialog neu (und schließe sie beim Verlassen wieder). Einzig in diesem einen Dialog kommt es zu den Problemen. Auch wenn ich vorher noch keinen anderen Thread erzeugt habe. Es kann also kein Konflikt mit irgendwelchen anderen dbf oder Threads geben.

Ralf: Gerade habe ich gesehen, daß von Dir auch noch etwas kam. Aber ich denke, daß das nicht geht. Folgende Situation: In meiner errorsys werden alle Fehlermeldungen gespeichert. Dazu kommen der Name des Windows-Users und des PC. In jedem Datensatz gibt es also Daten, die für den gesamten Fehler gelten (Betriebssystem, Xbase-Version, User, etc.) und welche, die im Detail den Fehlerverlauf aufzeigen (Prozedur, Zeile, etc.). Ich habe also 2 Browses erstellt: Oben die "globalen" Angaben, und darunter für diese 1 Fehlermeldung die Details. Ich muß gestehen daß ich nicht weiß, wie ich 2 Browses mit der gleichen dbf, aber unterschiedlichen Indizee mit nur einem Use verarbeiten soll. Aber unabhängig davon, ob man das auch eleganter lösen könnte, tritt halt dieser Fehler auf. Und das dürfte eigentlich nicht passieren.

Ich habe den Alias mal in eine der anderen Dialoge eingebaut. Sofort der gleiche Fehler. Bislang ist das nur nie aufgefallen, weil ich sonst nicht mit Alias arbeite.

Jan

[brandelh]

Hi,

das mehrfache Öffnen von DBF und Index Datei in einem oder mehreren Threas ist grundsätzlich erlaubt und muss gehen. Da bin ich voll deiner Meinung.

Hast du eigentlich zufällig ein Raid-System ?
Ich hatte mal die seltsamsten Erscheinungen (PDF waren beim öffnen leer ...) als die Platten nicht mehr syncron gelaufen sind.

[Jan]

Nein, kein RAID. Ziemlich normales Notebook.

Jan

[AUGE_OHR]

hi,

In meiner errorsys werden alle Fehlermeldungen gespeichert.

warum eine *.DBF und nicht das "normale" ERROR.LOG ?
wenn du "mehr" als nur "einen" Eintrag haben willst musst du nur
die Stelle

Code: Alles auswählen

BEGIN SEQUENCE
  SET ALTERNATE TO (cErrorLog) ADDITIVE
  SET ALTERNATE ON
RECOVER

um das ADDITIVE ergänzen und er hängt es "hinten" dran.

Dein FEHLER erinnert mir ein bisschen an "Roger" der eine Datei
"CON.dbf" genannt hat und die nicht ohne Fehler öffnen konnte ...
schon mal versúcht "FEHLER.DBF" ein was anderes "umzubenennen" ?

gruss by OHR
Jimmy

[Jan]

Noch immer bin ich nicht hinter das Geheimnis der Fehlermeldung gekommen. Umbenennen, Herauswerfen der eigenen errorsys, Herausnehmen der individuellen Dateiendungen, etc. haben alles nicht gebracht.

Beim Debuggen bin ich aber auf eine Merkwürdigkeit gestoßen:

Code: Alles auswählen

*****************************************************************************************************************************
*** Thread für Fehler anzeige erzeugen
*****************************************************************************************************************************
FUNCTION Fehlerliste(oAltDlg, oTabDlgFehlerliste)
LOCAL oThread := Thread():new()

oThread:atEnd := {||"DBCloseAll", oTabDlgFehlerliste:destroy()}
oThread:start("Fehlerliste1", oAltDlg, oTabDlgFehlerliste)

RETURN NIL

*****************************************************************************************************************************
*** Fehler anzeigen
*****************************************************************************************************************************
FUNCTION Fehler1(oAltDlg, oTabDlgFehler)
LOCAL nEvent := 0
LOCAL mp1 := NIL
LOCAL mp2 := NIL
LOCAL oXbpFehlerliste := NIL

USE fehler ALIAS uebersicht NEW SHARED
DBSETINDEX("fehler")

(ich habe aus Übersichtsgründen mal die ganzen LOCALS rausgeworfen)

Wie gewünscht wird die Function Fehlerliste() aufgerufen, die dann die Function Fehlerliste1() aufruft. Auch das USE ... wird korrekt aufgerufen. Aber statt danach die DBSETINDEX() aufzurufen springt der Debugger auf das RETURN NIL in der Function Fehlerliste(). In diesem Moment wechselt auch Thread1 von Idle auf Running, Thread3 von Running auf Idle (nebenbei: Wo bleibt Thread2?). Warum das ganze?

Ich hatte zwischen USE und DBSETINDEX() auch ein NetErr(), was aber keinen Fehler ausgeworfen hat.

Jan

[Martin Altmann]

Hallo Jan,
Du hast zu dem Zeitpunkt nicht bereits eine DBF mit dem Namen (oder dem ALIAS) uebersicht offen??

Viele Grüße,
Martin

[Jan]

Moin Martin,

nein. Und wie ich oben mal geschrieben habe: Ich habe auch mal mit einer anderen Funktion versucht, da einen Alias einzubauen. Da kam sofort der gleiche Fehler.

Ich öffne die Datenbanken immer erst direkt am Anfang eines Threads, nihct schon mal prophylaktisch irgendwo vorab. Und da USE ja immer threadlokal ist, dürfte es im SHARED-Modus ohnehin keine Probleme geben.

Jan

[Günter Beyes]

Hallo Jan,

gibt eine lokale Fehlerbehandlung vielleicht Aufschluß? Etwas in dieser Art:

Code: Alles auswählen

bErr := ErrorBlock({|e|break(e))
BEGIN SEQUENCE
   DBSETINDEX("fehler")
RECOVER USING e
   ErrorBlock( bErr )
   IF valtype(e) = "O"
      MsgBox( var2char(e:genCode) + " " + var2char(e:description) ) 
   ELSE
      MsgBox("Fehler ohne Fehlerobjekt!") 
   ENDIF
END SEQUENCE
ErrorBlock( bErr )

Günter

[Karlo Bender]

Hallo,
habe nicht die Zeit, den ganzen Thread zu lesen, deshalb nur mal schnell ein Schuss ins Blaue: Könnte es eine Rolle spielen, dass beide Tags im Index identisch sind und sich nur im UNIQUE-Attribut unterscheiden? Ich hatte eine solche Konstellation noch nie, und sie erscheint mir zumindest merkwürdig. Vielleicht kommt das System dadurch aus dem Tritt und reagiert mit irreführenden Meldungen.

[Jan]

Hallo Karlo,

unwahrscheinlich. Wie gesagt, ich habe das auch in anderen Dialogen mit anderen Datenbanken versucht. Wo der Index nur einen Tag oder komplett unterschiedliche Tags verwendet. Funktioniert so lange, wie ich den ALIAS rauslasse.

Günter: Versuch ich mal kommende Woche. Aber warum springt der aus der Index-Zeile plötzlich einfach in die Funktion davor?

Jan

[Martin Altmann]

Hallo Jan,

Aber warum springt der aus der Index-Zeile plötzlich einfach in die Funktion davor?

weil er den Befehl davor (also den USE-Eintrag) nicht ausführen konnte!

Viele Grüße,
Martin

[AUGE_OHR]

hi,

nein. Und wie ich oben mal geschrieben habe: Ich habe auch mal mit einer anderen Funktion versucht, da einen Alias einzubauen. Da kam sofort der gleiche Fehler.

... was ich noch nicht ganz verstehe : Wann / wofür wird die "FEHLER.DBF"
genau benötigt ?

Ich das Programm da schon "abgestürzt" oder ist das "nur" eine "Log-"
DBF die "normal" mitlaufen soll oder wird die irgendwie in einem
Errorblock eingesetzt ... ?

gruss by OHR
Jimmy

[Jan]

Martin: Aber NetErr() (der Hinweis von Andreas) gibt keinen Fehler zurück!

Jimmy: Da werden alle Fehlermeldungen drin gespeichert. Zusätzlich zur Bildschirmanzeige. Geöffnet und geschrieben wird das in der Errorsys. Ausschließlich dort. In dem betreffenden Dialog wird die ausschließlich zum Lesen geöffnet, um die bis dahin aufgelaufenen Fehler anzuzeigen.

Aber abgesehen davon: Das ist alles völlig egal. Denn wie schon mehrfach gesagt: Auch in anderen Dialogen mit ganz anderen Datenbanken kommt dieser Fehler, sobald ich da die Alias-Angabe hinzufüge. Ohne Alias funktioniet alles ganz einwandfrei.

Jan

[brandelh]

Ohne Alias funktioniet alles ganz einwandfrei.Jan

Hallo Jan,

wenn ich das oben recht verfolgt habe und diese Aussage lese bleibt meiner Meinung nach nur der Schluss, dass du eine DBF mehrfach mit der gleichen ALIAS Angabe öffnest. Bei der ersten Öffnung geht es gut, bei der zweiten ist der Alias schon in Benutzung und es kracht.

Bei allen MDI Anwendungen muss man die alte Syntax schlicht weg vergessen! FIX vorgegebene Alias haben in modernen Anwendungen nichts verloren, auch wenn man es irgendwie doch hinbekommen kann.
Den Alias speichert man in einer Variablen, entweder als Instanzvariable im Fenster oder als Funktion oder von mir aus in einer public ...

Code: Alles auswählen

    public  nFehlerReadOnly, nFehlerWrite, ...

    if nFehlerReadOnly > 0  // Datei schon offen
       .... 
    else
        use fehler
        if neterr()
           ... fehlermeldung
        else
           nFehlerReadOnly := select()
           ...
           (nFehlerReadOnly)->..... // () da Variable 
    .....

so kann es beim USE kein Problem mit dem Alias kommen, den vergibt
Xbase von alleine und der interessiert uns auch nicht.
Wir nutzten nFehlerReadOnly := select() um den 'numerischen' Alias = den select-Bereich direkt anzusprechen.

In diesem Beispiel ging ich davon aus, dass genau eine Datei in einer Zugriffsart genau einmal geöffnet werden soll (ReadOnly). Wenn man die gleiche Datei mehrfach öffnen will (wie bei einem MDI Fenster) legt man diese je Fenster ab.

Wie auch immer, diese Methode verhindert zuverlässig Fehler wegen Alias doppelbelegung und ermöglicht die zuverlässige Adressierung der DBF.

[Manfred]

Hi,

es dürfte doch recht einfach sein, dass alles zu kontrollieren. Auf das Öffnen der Datei wird ein Breakpoint gesetzt und dann mit dem Debugger nachgesehen, ob der Alias schon vergeben ist. So läßt sich dieses Problem schon ganz einfach lösen. Danach geht es an den nächsten Schritt. Wozu gibt es das Teil denn?

Meine Meinung.

[Jan]

Nein. Kann es nicht sein.

1.) Die Datenbank wird sonst NIRGENDS geöffnet. Außer in der Errorsys, und die springt zu dem Zeitpunkt noch nicht an. Auch die Original errorsys ändert nicht an dem Verhalten. Wie schon mehrfach erwähnt.

2.) Wird wie Datenbank ohnehin IMMER threadlokal geöffnet, wie schon mehrfach erwähnt.

3.) Wenn ich den Alias abfrage, ergibt das IMMER "FEHLER". Ohne Zusatz _1 oder sonstwas. Trage ich "FEHLER" fest als Alias ein, knallt es.

4.) Auch in anderen Dialogen knallt es sofort, wenn ich da einen Alias eintrage. Wie schon mehrfach erwähnt.

5.) Alias funktioniert, solange ich hinterher keinen Index öffne. Wie ebenfalls schon mehrfach erwähnt. Index alleine geht, Alias alleine geht. Index MIT Alias knallt.

Also, ich möchte hier niemandem zu nahe treten. Ich habe Eure Geduld mit mir und Eure Hilfe für mich immer sehr genossen. Aber liest denn niemand, was schon x-mal geschrieben wurde? Etwa die Hälfte dieses Threads hätte dadurch eingespart werden können.

Jan

[Martin Altmann]

Hallo Jan,
sorry - aber das liegt sicherlich daran, dass wir prinzipiell ungläubig sind
Was spricht denn gegen Huberts Vorschlag?
Öffne Deine DB ohne Angabe des ALIAS-parts und merke ihn Dir im Anschluß in einer Variablen - entweder den Selectbereich (wie Hubert vorgeschlagen hat) oder den Alias().
Wenn es dann klappt und Du dann noch die Muße/das Interesse haben solltest, kannst Du Dir den Inhalt Deiner Alias-Variablen ja mal im Debugger anschauen...

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Aber liest denn niemand, was schon x-mal geschrieben wurde?

ich denke schon das es gelesen wirde, trotzdem ist es "mir" noch immer
nicht klar was du wo machst ...

ja, ich benutze eine modifizierte errorsys. Ich schreibe darin die Fehler in besagte fehler.dbf. Funktioniert auch einwandfrei. Sonst überall.

also ... du hast eine (modifizierte) errorsys ...
in die kommst du aber "gewöhnlich" ja nur wenn das Programm "abstürzt"

in "dieser" Situation machst du dann die "Fehler.DBF" auf ???

In diesem Moment wechselt auch Thread1 von Idle auf Running, Thread3 von Running auf Idle (nebenbei: Wo bleibt Thread2?). Warum das ganze?

wenn "das" passiert würde ich mal behaupten das dein Programm gerade
"abgestürzt" ist ... dann wäre es "kein Wunder" ... und wohl auch die
Antwort auf deine Fragen :

Du bist "nicht" mehr in "deinem" Thread "Nr" sondern eben in der Errorsys
und das müsste Thread "1" sein.

Und wenn ich die wieder raus nehme ist die Fehlermeldung genau die gleiche. Es liegt also nicht an meiner errorsys.

"das" verstehe ich z.B. nicht ... wie rufst du die dann "normal" auf ?

"USE fehler INDEX fehler ALIAS fehler NEW SHARED"

versuche es mal so :

Code: Alles auswählen

FUNCTION xyz(cDatei,cAlias,cTagName)
...
      DO WHILE .T. 
         USE (cDatei) ALIAS (cAlias) SHARED NEW 
         IF Neterr() .AND. ; 
            Alert( "Datei ist gesperrt!;Zugriff wiederholen?", ; 
                   {"Wiederholen","Abbrechen"} ) <> 2 
            LOOP 
         ENDIF 
         EXIT 
      ENDDO 
      IF Used() 
         SET INDEX TO ("fehler.CDX")
         OrdSetFocus(cTagname) 
      ENDIF 

... aber bitte "NICHT" aus der Errorsys, wenn das Programm schon
abgestürzt ist ...

gruss by OHR
Jimmy

[Jan]

Hallo Martin,

kommt noch, ich hatte nur nicht so viel Zeit in den letzten Tagen, wie ich gerne gehabt hätte. Aber: Wie gesagt: NetErr() gibt mir KEINEN Fehler zurück. Also ist der Part jedenfalls schon mal abgehakt.

Hallo Jimmy (und alle anderen),

trenne Dich in Gedanken doch einfach mal von der errorsys. Denn wie gesagt: Egal ob ich die "normale" oder meine modifizierte nehme: Der Fehler ist der gleiche. Und die "normale" errorsys binde ich natürlich garnicht ein, denn das macht ja Alaska schon von alleine. Die wird schließlich nur dann "überschrieben", wenn ich eine eigene einbinde.

Und wie bereits mehrfach gesagt: NetErr() gibt keinen Fehler!!! Du bist nicht der erste, der den (berechtigten) Hinweis gibt.

Jan

[brandelh]

Hallo Jan,

spätestens nach 7 Postings verlassen mich meine Augen bei der winzigen Schrift, darum ist es schon möglich, dass ich einzelne Passagen nicht ganz so genau gelesen oder einfach nicht behalten habe.

Wenn ich in meinem Programm einen logik-Fehler suche, sehe ich sehr genau hin. Wenn aber ein 'seltsames' Verhalten durch eine veraltete Syntax besteht, die durch eine modernere verschwindet, ist es mir ziemlich egal warum der Compiler mit dem alten Schrott Ärger hat und nehme den neuen. Alles andere ist Zeitverschwendung.

So und jetzt wieder zurück an die Arbeit ...

[Rolf Ramacher]

Hallo Jan,

nochmal für mich zum Verständnis. Du möchtest eine Datenbank 2x öffnen mit 2 verschiedenen Index und diese mit browse anzeigen.

Was spricht dagegen die Datenbank zweimal mit unterschiedlichen Aliasnamen zu öffnen und den Index expliziet neu zu setzen.

z.b.

use fehler New alias "db1"
index on (feld) tag xxx to (db1)+".cdx"

use fehler New alias "db2"
index on (feld) tag xxx to (db2)+".cdx"

das müßte doch funktionieren.

[andreas]

Hallo Jan,

wenn ich bei mir keinen Ausweg mehr sehe, schreibe ich ein kleines Testprogramm.
In deinem Fall würde ich ein kleines Testprogramm schreiben, wo du einfach die Datei aufmachst und mit APPBROWSE + APPDISPLAY anzeigen lässt. Wenn es schon da Probleme geben sollte, dann liegt es wohl an den Dateien.
Wenn nicht, dann kannst du dein Fehler vielleicht damit etwas eingrenzen.