Da Du leider immer noch nicht gesagt hast, was Du unter Foxpro Dokumenten verstehst, gehe ich davon aus, es geht letzlich um Sourcen einer EXE, ein PJX.
Wir hatten schon DSN (außerhalb VFP in ODBC Manager verwaltet), da gibt es ja Benutzer-DSN, System-DSN User und Datei-DSN. Ich sehe anders als so mancher SysOp bei Firmen nicht, dass dies der ideale Weg sei, solche Datenbankconnections zentral zu verwalten.
Alleine schon der Strauss an Varianten lässt mich daran zweifeln. Meine Erfahrung und das Konzept, was ich mit einer AG in meiner zurückliegenden Karriere dort aufgebaut hatte war etwas besseres, zentraleres (nicht nur auf jedem einzelnen Rechner) und berücksichtige
auch das vorhandensein von Verbindungsdaten zu PROD und TEST bzw. DEVeloper Daten also Test und Stagingbereiche neuer Softwareversionen, eine DSN ist immer nur hin zu einer DB und hat z.B. diesen Schalter PROD/TEST nie. Auch deswegen konfrontiere ich gerne
SysOps mit ihrer Aussge DSNs seien das Ideal zur Verwaltung solcher Dinge. Im Aspekt unter deren Kontrolle zu sein gegenüber Sourcecode mit Sicherheit, aber man kann das Konzept selbst besser betreiben als das Betriebssystem.
Ich zähle nochmal auf, wo Du in VFP überall Verbindungen vorfinden kannst:
1. DSN Nutzung, das wird meist per Befehl SQLCONNECT() umgesetzt.
2. Connection Strings, die meist per SQLSTRINGCONNECT() benutzt werden.
3. Connection Objekte in DBCs. Diese können einerseits nun wieder DSN als auch Connectionstring nutzen
4. Cursoradapter - fallen prinzipiell auch unter 2, wenn man VFPs Builder für Cursoradaptoren einsetzt, kann aber da z.B. auch in Klasseneigenschaften hinterllegt sein, VFPs "Code References" Suche schließt die mit ein.
Zu VFP Daten, wie gesagt, sind Credentials überhaupt kein Thema, aber innerhalb der ersten 3 Varianten für Verbindungen von VFP heraus zu anderen DBs gibt es Varianten, die Credentials abzulegen. Sowohl innerhalb einer DSN, genausogut innerhalb von Connectionstrings
und die Connections Objekte, die wir bisher noch nicht am Wickel hatten, erlauben auch die explizite Hinterlegung von Userid und Password.
Daneben können DSN Namen und Strings natürlich auch und idealerweise in Konfigurationsdaten außerhalb jeglicher Sourcen oder Projekteigenschaften gespeichert sein, z.B. INIs. Es wäre demgegenüber Unsitte direkte Konstanten in SQLCONNECT() bzw. SQLSTRINGCONNECT()
einzusetzen, dann muss jeglicher Umzug mit einer neuen EXE begleitet werden, die man orchestriert verteilen müsste.
Zum Thema Unterdrückung von Logindialog hatte ich ja schon diverses gesagt, nur eins noch: Wenn Du sie zuläßt, könnte ein User vielleicht die Verbindung herstellen, allerdings erlaubt der Dialog vom System nicht nur Angabe von Username und Passwort, wenn
nicht bewußt ist, zu welcher DB eine Verbindung gehen soll, kann man sich Erfolgreich auf eine falsche DB verbinden, z.B. Testdaten.
Aus dem Grund hatten wir die Dialoge immer unterdrückt, weil es nicht möglich ist eindeutig deutlich zu machen, wohin die Connection gehen soll und diverse Anwendungen nicht nur eine oder 2, sondern (in einem Datamininig Tool z.B.) sogar bis zu 10 Connections
aufgebaut wurden.
Und daneben sind ja nicht nur Credentials zu ändern, wenn Server umziehen oder konsolidiert werden, dann müssen auch andere Anteile der Connectionstrings angepasst werden. Einzeldaten zu haben und Connections daraus dynamisch zusammenzusetzen zahlt sich
dann aus. Es macht also Sinn, sich um so eine Umsetzung zu kümmern.
Ich sage das nur nochmal ausdrücklich, weil ich denke, dass Dir immer noch überhaupt nicht bewusst ist, welche Probleme bei Euch schlummern könnten, wenn DBs umziehen, Server umziehen, Credentials sich ändern u.v.m.
Tschüß, Olaf.
Olaf Doschke - https://www.doschke.name
