Relative Pfadangaben und deren Probleme [ERLEDIGT]

[Manfred]

Moin,

heute ist mir etwas sehr heftiges aufgefallen. Mit einem genauen Blick darauf, scheint es aber logisch.

Also folgendes Szenario:

In meinen Programmen arbeite ich vom Programmverzeichnis aus, mit relativen Pfadangaben. Also ..\datenbanken\etc. ..\temp\ usw. Das hatte ich damals eingeführt, damit der Anwender das Hauptverzeichnis nennen kann, wie der will. So weit so gut.

Wenn das Programm nun ein Verzeichnis, oder ein Verzeichnis incl. Dateien nicht findet, wird es kurzerhand einfach erzeugt. Also alles automatisch. Eigentlich recht praktisch. Aaaaber. Ich habe mich immer wieder gewundert, warum in verschiedenen Ebenen Verzeichnisse und leere Dateien stehen, die dort nichts zu suchen haben. Ich habe einfach nicht die Lösung gefunden. Bis auf heute, da hat es heftig geklingelt.

Wenn der User in, oder außerhalb des Programmes ein Dateifenster öffnet (innerhalb auf jeden Fall) wird wohl das CurDir() des Programmes in dem Moment verändert und die ganze Technik verrutscht sozusagen. Es werden dann neue Verzeichnisse und Dateien angelegt, die überhaupt nicht angelegt werden dürfen. Sobald die Dateifenster wieder geschlossen sind, werden dann wohl auch die Pfade wieder zurückgesetzt und alles paßt wieder. Aber erst wieder danach. In meinen Programmen setze ich ja die Verzeichnisse nach einem FileDialog() wieder zurück, aber auch dazwischen, solange das Fenster noch auf ist, bekommt der Rest des Programmes, oder sogar der Programme, das falsche Verzeichnis und macht somit Mist.

Mein Frage wäre jetzt, geht das irgendwie zu umschiffen, oder bin ich jetzt doch gezwungen evtl. beim Programmstart mir zu merken, wie das Hauptverzeichnis heißt um dann feste Vorgaben für die Verzeichnisse zu geben und auf die relative Angabe zu verzichten? Sieht wohl ganz so aus, oder?

[Jan]

Moin Manfred,

interessantes Phänomen. Könnte sein, daß ich da auch schon mal drüber gestolpert bin. Und ich hatte mich damals arg gewundert, warum manchmal die Pfade so merkwürdig sind.

Ich lese inzwischen beim Programmstart den Pfad in eine Variable ein, die ich dann an verschiedenen Stellen auslese. Seitdem hatte noch nie mehr irgendwelche Probleme damit.

Jan

[Manfred]

Das mache ich jetzt genauso. Ich habe zwar sehr viele Routinen zentral dafür, aber trotzdem ist es jetzt ordentlich Tipperei, bis alles geändert und dann getestet ist. Manoman.

[Tom]

Ich setze beim Programmstart PATH und DEFAULT, aber dabei geht es ausschließlich um Daten-/Tabellenzugriffe. In der Mehrmandantenversion wird PATH benutzt, um im Pfad den Unterpfad zu wechseln (DEFAULT ist das Datenbankhauptverzeichnis, PATH das jeweils aktuelle Unterverzeichnis mit den mandantenbezogenen Daten). Das funktioniert auch exzellent (wobei ich beim Setzen der Pfade abfange, ob der Pfad relativ ist, und ihn um Laufwerksbezeichner bzw. die korrekte UNC-Notation ergänze). Aber. Der Zugriff auf alle anderen möglichen Daten (z.B. Bilddateien, Texte usw.) sollte sich hierauf nicht verlassen! Irgendwie funktioniert das Zurücksetzen des vorigen Verzeichnisses beim Aufruf von XbpFileDialog nicht, selbst das manuelle Nachsetzen arbeitet oft nicht zufriedenstellend. Deshalb ergänze ich den Zugriff auf alles, was nicht Tabellen sind, immer implizit um die entsprechenden Pfade. Übrigens sollte man sich auch bei einem INDEX ON nicht auf die Pfadeinstellungen verlassen.

[Manfred]

Wie gesagt, das war der richtige Jahreseinstieg. Ich fröddel das jetzt alles auf feste um und dann sollte das Problem weg sein. Ist halt nur blöde Tipparbeit im Moment. Aber wer weiß, welche dubiosen Fehler jetzt plötzlich verschwinden. Ich hatte in letzter Zeit des öfteren Problem damit, dass in DB nicht geschrieben werden konnte, weil die Sätze nicht gesperrt waren, oder nicht zu sperren gingen. Das scheint jetzt alles zu einem Schuh zu werden.

[Herbert]

Ja, ja, die Dynamik der nicht modalen Windowsapplikationen...

Ich hole wie Jan bei Programmstart den App-Pfad und den Pfad (falls vorhanden) für alle Benutzer und (falls vorhanden) für alle Mandanten geltenden allgemeinen Bereich und halte diese fest.
Weitere Pfade, die der Benutzer ändern darf (z.B. für Textbausteine, einen temp. Pfad, für Reports) werden in einer Datenbank (pro Mandant) festgehalten.
Auf diese Art kann der Benutzer sogar direkt mit Netzwerkpfaden arbeiten.

[Martin Altmann]

Moin Manfred,

Ich hatte in letzter Zeit des öfteren Problem damit, dass in DB nicht geschrieben werden konnte, weil die Sätze nicht gesperrt waren, oder nicht zu sperren gingen.

das ist dann die Ursache dessen - also kannst Du DIch damit trösten, dass dann die Fehler weg sind.
Ich mache das auch so, dass ich mir am Anfang den Pfad merke und dann nutze. Und auch CurDir() entsprechend merke und wieder zurücksetze (z.B. bei DllCall()-Aufrufen).

Viele Grüße,
Martin

[Manfred]

Ich denke auch. Mir fällt ein Stein vom Herzen. Als am WE keiner am Programm war und es so vor sich hinwerkelte, lief alles problemlos. Aber da muß man erstmal drauf kommen.

[AUGE_OHR]

Also ..\datenbanken\etc. ..\temp\ usw. Das hatte ich damals eingeführt, damit der Anwender das Hauptverzeichnis nennen kann, wie der will.

das Hauptverzeichniss ist doch dort wo die Application gestartet wird.

Code: Alles auswählen

PUBLIC ZPATH := LEFT( AppName( .t. ), LEN( AppName( .t. ) ) - LEN( AppName( .f. ) ) )

dumm nur wenn auch die PUBLIC "manchmal" in einem Thread "verloren" gehen kann ... also die PUBLIC einer Class VAR zuweisen.

p.s. warum brauchst du so viele Unterverzeichnisse ?

[Manfred]

Naja,

ich habe ein PUBLIC Objekt, in der die ganzen Parameter stehen. Wenn also die Var nicht mehr da wäre, dann würde noch mehr fehlen und man es sicherlich recht schnell merken.

Warum ich soviele Verzeichnisse brauche? Erstmal, weil ich es hasse alles in ein Verzeichnis zu pfropfen und dann, weil am Jahresende evtl. einigen 100 bis über 1000 Dateien erzeugt werden, die irgendwo schön geordnet stehen sollen.

[Tom]

Hallo, Jimmy.

Was Du anmerkst, das gilt nur für Applikationen, die auch dort laufen, wo sich ihre Daten befinden. Der Normalfall bei "unserer" Art der Applikationsentwicklung ist allerdings derjenige, dass die App lokal gestartet wird und auf Daten zugreift, die sich anderswo befinden. In Netzen laufen dann zig Instanzen der Apps jeweils lokal und teilen sich die Datenbank auf einem Server, der u.U. auch noch für jeden Arbeitsplatz anders gemappt ist, manchmal sogar per UNC. Wir lösen das auf zwei Arten: Standardmäßig kann in der Verknüpfung ein absoluter Pfad zur Datenbank angegeben werden, den sich das Programm merkt und auch gleich entsprechend bearbeitet (PATH/DEFAULT), und wenn das nicht der Fall ist, wird beim Start nach der Datenbank gesucht bzw. das Zielverzeichnis kann ausgewählt werden. Das wird dann (HKLU) in die Registry geschrieben. Wenn es Mandanten gibt, wird ergänzend eine tabellengesteuerte Verwaltung relativer Datenbankpfade aktiv. Wenn also das Zielverzeichnis mal z:\daten oder mal m:\work\daten ist, sind die Mandanten z.B. dann in \mandant1, \mandant2 usw. verwaltet. Der absolute Pfad wird bei der Aktivierung des jeweiligen Mandanten (z:\daten oder m:\work\daten) um den relativen Pfad ergänzt. PATH bleibt auf z:\daten oder m:\work\daten, DEFAULT wechselt zum jeweiligen Mandanten (z:\daten\mandant1 oder m:\work\daten\mandant1). Bei Tabellenoperationen kann dann ohne Pfad gearbeitet werden, es sei denn, man will z.B. prüfen, ob eine Tabelle existiert oder nicht. Nur beim Erzeugen von Indexen wird der Pfad mit angegeben. Diese Vorgehensweise erlaubt es auch, mehrere Instanzen der App auf einem Arbeitsplatz mit unterschiedlichen Datenbanken zu versorgen.

[AUGE_OHR]

Was Du anmerkst, das gilt nur für Applikationen, die auch dort laufen, wo sich ihre Daten befinden.

es ging hier nur um "Hauptverzeichniss" zu den "relativen" Verzeichnissen

Der Normalfall bei "unserer" Art der Applikationsentwicklung ist allerdings derjenige, dass die App lokal gestartet wird und auf Daten zugreift, die sich anderswo befinden. In Netzen laufen dann zig Instanzen der Apps jeweils lokal und teilen sich die Datenbank auf einem Server,

ich pflege auch meine Applicationen local auf der Workstation zu haben

der u.U. auch noch für jeden Arbeitsplatz anders gemappt ist, manchmal sogar per UNC.

das mit dem MAP per NET USE sollte man nicht mehr für ein "pure" SMB2 Environment verwenden.
Die "Namens-Auflösung" geht über NetBIOS und damit ist der 1st "Contact" über Port 139 statt 445 wenn du UNC benutzt.
(siehe Taskmanager -> Resource Monitor -> Netzwerk -> Ports )

[Manfred]

Hi Jimmy,

und was heißt das jetzt mit SMB2?

[Herbert]

ich pflege auch meine Applicationen local auf der Workstation zu haben

Warum? So muss bei einem Update auf allen Workstations geupdatet werden? Wie löst ihr denn so was?

Ich hole die App ab Netz (ohne dll's gelinkt, also 1 .EXE - ist Ergebnis meiner damaligen Betrachtungen zur Performance). So wird diese transferiert, bevor jegliche Daten geöffnet werden und stellt doch kein Performance-Problem dar.

Manfred: bezieht sich auf das NET USE, welches bei SMB2-Umgebungen nicht mehr verwendet werden sollte.

[Manfred]

Meine Apps liegen auch im Netz, wenn es denn eines ist. Wie auch die Daten. Herbert hat m.E. Recht mit seiner Aussage, dass sonst alle WS upgedatet werden müßten, im Falle des Falles. Und da würde ich persönlich Bedenken haben, darauf immer achten zu müssen.

Das mit SMB2 würde ja dann ab Win7 gelten, so wie ich das hier nebenbei mit bekommen habe. Aber wie löst man das Problem denn dann? Oder gilt das nicht, wenn z.B. nur 1 Win7 PC darunter ist? Ich spreche jetzt hier von einem Samba Server, der aber keinen PDC darstellt, sondern von dem einfach nur die Verzeichnisse gemappt werden.

[Tom]

Wie auch immer. Unmittelbar nach dem Programmstart sollten aus relativen Pfaden absolute Pfade werden!

[Koverhage]

Manfred,

CurDir() sollte man (nach meinen Erfahrungen) grundsätzlich vermeiden. Du kannst das ganz einfach testen.
Rufe die Funktion auf wo Du CurDir() benutzt, auf vorher vielleicht Outlook, etc.
Bei fast allen MS Programmen (insbesondere die Mail Programme) verbiegen CurDir.
ich merke mir beim Programmstart Appdata und habe CurDir() damit ersetzt. Damit wird
auf jeden Fall immer das richtige Verzeichnis angesprochen.

[AUGE_OHR]

ich pflege auch meine Applicationen local auf der Workstation zu haben

Warum? So muss bei einem Update auf allen Workstations geupdatet werden? Wie löst ihr denn so was?

bei mir gibt es auf dem Server eine VERSION.DBF die bei Login verglichen wird.
Die verschiedenen Versionen der Applicationen liegen auf dem Server von wo sich die Workstationen dann das Update (oder downgrade) holen können.

Das mit SMB2 würde ja dann ab Win7 gelten, so wie ich das hier nebenbei mit bekommen habe. Aber wie löst man das Problem denn dann? Oder gilt das nicht, wenn z.B. nur 1 Win7 PC darunter ist? Ich spreche jetzt hier von einem Samba Server, der aber keinen PDC darstellt, sondern von dem einfach nur die Verzeichnisse gemappt werden.

hm ... mit Samba ...

unter Vista/Win7/2K8 arbeitet man ja mit "Active Directory" die ich auf den Servern bereitstelle.
die User Rechte und Zugriff werden nun durch "Active Directory" geregelt und nicht mehr durch den Lanmanager.
Der Unterschied wird bei "vielen Server" schnell deutlich : man "müsste" sich bei jedem Server anmelden.

Der Lanmanager nutzt ja IP4 und DNS für die "Namen-IP Auflösung" während bei "Active Directory" nun IP6 verwendet wird.

***
Bittorrent hat "früher" mit "Tracker" gearbeitet die ähnlich DNS die Auskunft gaben "wo" sich "was" befindet.
wenn nun diese "Tracker" nicht online waren funktioniert das System nicht mehr.

in einem Bittorrent System ist aber jeder Client auch ein Server für andere ... und dann kam IP6
damit war es nun möglich das man ohne "Tracker" auskam und so etwas wie PirateBay konnte zumachen ... man brauchte es nicht mehr.

zusätzlich hat IP6 ja auch Verschlüsselung und Komprimierung so das mehr User mehr Warez durch das Netz schicken konnten.

da man nun auf die üblichen UDP Ports und NetBIOS verzichten konnte wurde ein zusätzlicher Sicherheitsfaktor erreicht und man kann statt dessen diese Ports zusätzlich (verschlüsselt) nutzen.
***

"Active Directory" kann also z.B. \\ServerXYZ intern verwalten und könnte den Effekt durch den Explorer auslösen weil Windows nun meint das "dies" dass "aktive" Verzeichnis sei ...

wir Martin schon sagte auch bei DllCall oder ActiveX passiert so etwas z.b. Excel ( C:\Programme\Microsoft Office\Office12\ERROR.LOG )

auch C:\Dokumente und Einstellungen\User\Eigene Dateien\ERROR.LOG kommt schon mal vor und das obwohl ich PUBLIC zPATH ausdrücklich festgelegt habe.

[Rolf]

Wenn der User in, oder außerhalb des Programmes ein Dateifenster öffnet (innerhalb auf jeden Fall) wird wohl das CurDir() des Programmes in dem Moment verändert und die ganze Technik verrutscht sozusagen.

CurDir() sollte man (nach meinen Erfahrungen) grundsätzlich vermeiden. Du kannst das ganz einfach testen.
Rufe die Funktion auf wo Du CurDir() benutzt, auf vorher vielleicht Outlook, etc.

Ist der Fehler reproduzierbar? Ich habe dies nun bei mir mal hin und her probiert, kann das Fehlerbild aber nicht bestätigen.
Gibt es eine Schrittfolge. Bei welchem OS oder mit welche MS-Programmen( / Programmversionen) tritt der Fehler auf?

Liebe Grüße
Rolf

[Manfred]

Hm,

ich habe es bemerkt, in dem ich ganz genau den Weg nachvollzogen habe. In dem Moment, wo ich im eigenen Programm ein DateiDialog Fenster geöffnet und darin das Verzeichnis gewechselt hatte, wurde genau von dem gerade angewählten Verzeichnis aus relativ gesehen der Rest an Verzeichnissen und Dateien erzeugt (von einem Hintergrundprozess aus, der gerade werkelte). Das war für mich Beweis genug. Und jetzt, wo ich es umgestellt habe, ist das Problem weg.

[Rolf]

ja, das Problem mit xbpFileDialog() aus dem eigenen Programm verstehe ich, auch wenn ich immer dachte ein restoreDir=.T. stellt alles wieder 100% her.
Aber, dass andere Programme Seiteneffekte auf das Ergebnis von CurDir() erzeugen, kann ich nicht nachvollziehen.

[Manfred]

Nö,

das siehst Du etwas falsch. In dem Moment, wo im Filedialog das Verzeichnis gewechselt wird, scheint es das CurDir zu sein und da knallt es dann.

[brandelh]

dass andere Programme Seiteneffekte auf das Ergebnis von CurDir() erzeugen, kann ich nicht nachvollziehen.

CurDir() fragt das aktuell eingestellte Verzeichnis des Prozesses ab.
JEDES Programm das dieses ändert, hat Einfluss auf curDir().

Ich hatte das vor einiger Zeit bei meinem PDF-Druckertreiber festgestellt,
sobald man dort das Verzeichnis der PDF ändert.

Auch ich prüfe zu Programmbeginn die Verzeichnisse und merke mir was ich brauche.

[Manfred]

Genau, ganz zu Anfang prüfe ich, von wo das Programm aus gestartet wird und das merke ich mir dann. Danach dürfte nichts mehr schief gehen.

[Martin Altmann]

Anderes schönes Beispiel ist z.B. das Schreiben von Mails mittels SocMapi (DLL-Aufrufe).
CurDir() wird dann umgesetzt auf das Verzeichnis, in dem der Mailclient installiert ist.

Viele Grüße,
Martin