Soweit ich gelesen habe war Dein Hauptproblem eher den Unterschied im Verhalten von private und default datasession nicht zu kennen. Ein DBC ist zwar für alle Datasessions geöffnet, aber jede private/neue Datasession hat anfangs erst einmal 0 Workareas belegt
und jede DBF, die Du neu öffnest hat damit einen eigenen Datensatzzeiger, Du kannst Dasselbe Formular zweimal mit privater Datasession starten und das eine zeigt von einer DBF ID1 und das andere ID 2 an, ohne dass sich das irgendwo beißt oder gegenseitig beeinflusst.
Natürlich teilen beide Formulare trotzdem dieselbe Tabelle shared.
Nur noch soviel: Selbst wenn Du in einem Formular Dataenvironment eine Datenbank außerhalb Deines PRojektordners verwendest, z.B. den Sample Northwind.DBC auf C:\ nimmst, während Deine Projektsourcen z.B. auf D:\ liegen, dann hast Du im Properties Memo einen
absoluten Pfad wie z.B. Database = c:\program files (x86)\microsoft visual foxpro 9\samples\northwind\northwind.dbc
Selbst dann wenn die Datenbank für den Enduser dort nicht bereitsteht, sondern Du sie kann eine laufende EXE der Northwind.DBC irgendwo in einem Netzwerkshare bereitsteht wird das Dataenvironment dort seine Tabellen suchen, nachdem es einen erfolglosen Versuch
in c:\program files (x86)\microsoft visual foxpro 9\samples\northwind\ gemacht hat. Es wird dann entlang SET PATH Pfaden weitergesucht. Aber selbst ein schon geöffneter DBC veranlasst ein Tabellenobjekt in einem Dataenvironment nicht, die schon geöffnete
DBC zu nehmen.
Gerade ein Dataenvironment mit relative Pfaden bedeutet, dass die Datenbank auch relativ zum Standort der EXE gefunden und genutzt wird, was Du dann u.U. gar nicht möchtest. Deswegen ist es auch üblich, eine EXE gar nicht im Netzwerk aufzurufen, sondern
zuerst in ein lokales Laufwerk zu kopieren und dort zu starten.
Wobei es dann davon abhängt, ob die Anwendung Single oder Multi User ist, ob jeder User seinen eigenen DBC kriegen sollte oder der DBC zentral liegt.
Um da ein bewegliches Gelenk zu haben, was den DBC angeht, nutze ich die Dataenvironments von Formularen gar nicht. Man entwickelt heute OOP und dazu zählen dann Formularklassen statt SCX. Formularklassen havben gar kein Dataenvironment, daher kommt man
gar nicht erst in Versuchung, dieses leicht verschrobene Konstrukt zu nutzen in dem man nie genau weißt, was eigentlich abläuft. Der Luxus die Tabellen da visuell reinzuziehen und relationen automatisch zu erben ist durchaus auch Nachteil. Wenn Du wissen willst,
was passiert, codierst Du einfach OPEN DATABASE (in main o.ä. auch ok) und dann die einzelnen USE, wenn überhaupt.
Heutzutage (seit VFP8 mein ich) hast Du noch das Dataenvironment als einzelne Klasse. Das stand einem in VFP7 auf jeden Fall noch nicht zur Verfügung. Das ermöglicht auch noch hier OOP anzuwenden und ein und dasselbe Dataenvironment auch für verschiedene
Formularklassen zu nutzen und das nicht nur als Kopie, sondern über Nutzung der gleichen Klasse, die zentral aktualisierbar ist. Du kannst viel exakter objektorienteirt arbeiten und wie das die 3 Tier Architektur verlangt sauber Datenzugriff und Frontend/Interface
trennen, eine Formularfreie Datenzugriffsschicht programmieren und testen, ohne ein Formular davor setzen zu müssen, etc.
Tschüß, Olaf.
Olaf Doschke - TMN Systemberatung GmbH
Standardpfade
