none
Ändern von ODBC Zugangsdaten in FoxPro 7.0 Dokumenten.

    Frage

  • Hallo MSDN Community,

    ich habe eine vermeintlich einfache Frage für Visual FoxPro 7.0 

    Wo finde ich die Zugangsdaten / Parameter für ODBC Verbindungen in einem FoxPro Dokument?

    Danke schon einmal!

    Dienstag, 10. April 2018 11:58

Alle Antworten

  • Fragt sich, was Du unter einem FoxPro Dokument verstehst.

    Wenn Du analog zu Worddokument und Word denkst, dann wäre das wahrscheinlichste Datenbank bzw. Tabelle, DBF wäre da das typischiste Format/Dateiendung.

    VFP ist ähnlich Access Datenbanken MDB bzw. ACCDB serverlos, Zugangsdaten gibt es insofern nicht, als es keinen Server gibt, bei dem man sich anmeldet. Zugriffsrechte sind einzig durch Verzeichnis/Dateirechte geregelt. Es gibt aber analog zu Access die Möglichkeit per ODBC zuzugreifen, ja. Siehe https://www.connectionstrings.com/visual-foxpro/

    Insbesondere der Abschnitt "Microsoft Visual FoxPro ODBC Driver" Man gibt einen DBC Dateinamen oder Pfad zu DBF Dateien an, ergo muss der Client, der sich zu DBFs verbindet LAN Zugriff haben. De ODBC Treiber ersetzt quasi den Server und enthält den Satz an ODBC und Datenzugrifsrelevanten Funktionen bzw. Kommandos, die VFP SQL Engine, ganz analog zur JET Engine bei Access Datenbankzugriff per ODBC.

    Tschüß, Olaf.


    Olaf Doschke - https://www.doschke.name

    Dienstag, 10. April 2018 17:44
  • Hallo,

    wenn wir eine ODBC-Verbindung einrichten, unabhängig ob das in FoxPro, Word oder Excel ist, dann erfordern unsere ODBC-Schnittstellen jeweils Benutzername und Passwort. Diese kann man ja in einer FoxPro Anwendung speichern. Nun ändern sich die Schnittstellen bei uns und wir wollten wissen, wo wir diese Änderungen korrigieren können. In Excel gibt es dafür ja entsprechende Möglichkeiten (Daten --> Verbindungen --> Eigenschaften --> Definitionen). So etwas müsste es ja auch in FoxPro geben, aber wo?

    Danke für deine Mühen.

    Mittwoch, 11. April 2018 10:04
  • Es würde immer noch helfen, wenn Du erzählst, was Du unter einem FoxPro Dokument verstehst.

    Wenn man in Word oder Excel ODBC Verbindungen einrichtet und pflegt, dann ist man in dem Frontend, was auf ein Backend zugreift.

    Foxpro ist kein Word und kein Excel, FoxPro ist die Datenbank in Deinem Fall, oder nicht? Ergo das Backend und nicht die Stelle, die die Konfiguration enthält sondern das Ziel der Konfiguration.

    Außerdem, wie gesagt, ein Foxpro DSN hat die ODBC Parameter für User und Passwort nicht! Foxpro Daten sind per Verzeichnis und Dateirechten geregelt und nichts anderem.

    Wie Du eine ODBC Verbindung mit VFP ODBC Treiber einrichten kannst, hatte ich ja schon aufgezeigt. Fragt sich, welches Problem Du hast, abgesehen von Zweifeln, die sich ja leicht durch ausprobieren lösen ließen.

    Wenn Du mit einer Foxpro Anwendung mit Foxpro Datenbank zu tun hast, dann suchst Du vergeblich nach einer ODBC Konfiguration, VFP greift auf seine Datenbank und Tabellen Files nativ zu. Und dass VFP dazu nur den Pfad zu einer DBC oder den Pfad zu einem Ordner von DBF Dateien benötigt schlägt sich auch darin nieder, dass eine dieser beiden Informationen die Hauptkonfigurationsoption einer ODBC Verbindung zu FoxPro Daten ist, aber nur für Nicht-Foxpro Zugriffe benötigt wird, z.B. in Word mit Mailmerge o.ä., Excel, Access, was auch immer, aber nicht in Foxpro oder "Foxpro-Dokumenten", die es nicht gibt.

    Tschüß, Olaf.


    Olaf Doschke - https://www.doschke.name


    Mittwoch, 11. April 2018 11:27
  • Hallo Olaf,

    bei den FoxPro Anwendungen handelt es sich bei u.a. um einen selbst entwickelten Leitstand. Wir greifen u.a. über ODBC auf andere Datenbanken, wie z.B. eine Oracle Datenbank von unserem ERP System zu, und ziehen uns dort entsprechende Daten zur Weiterverarbeitung. Um den Zugriff auf die Oracle Datenbank zu tätigen haben wir eine ODBC Schnittstelle, diese wiederum erfordert zwingend Benutzername/Passwort. Bindet man so eine bei FP ein, dann wird man aufgefordert diese entsprechend anzugeben. Diese Zugangsdaten müssen dann ja auch irgendwo gespeichert werden. Die wollen wir abändern.

    Danke für deine Hilfe.

    Mittwoch, 11. April 2018 13:58
  • Aha, wir kommen ein Stückchen näher. Ich nehme dann an, Du hast Nutzername und Passwort solcher ODBC Verbindungen aus Foxpro heraus hin zu externe DBs dann nicht in den jeweiligen Connection Strings oder in den DSN Konfigurationen hinterlegt.

    Du kriegst dann einen interaktiven Logindialog, der nach User/Passwort fragt, wenn Du ihn nicht per SQLSETPROP(0,"DispLogin",0)  unterdrückst und stattdessen lieber einen Fehler kassierst.

    Das kann man machen, aber was auch immer dann interaktiv passiert inkl. der eventuellen Speicherung der Credentials, die Du da eingibst ist reine Sache des ODBC Treibers, VFP ist daran völlig unbeteiligt, es kriegt die Angaben, die in dem Login gemacht wurden nicht zurückgemeldet, Returnwert ist immer noch nur der Connectionhandle>0 bei Erfolg oder -1 bei Verbindungsfehler.

    Tschüß, Olaf.


    Olaf Doschke - https://www.doschke.name

    Mittwoch, 11. April 2018 21:20
  • Hi Olaf,

    danke für deine Info. Wir werden das so machen. Wir geben dir am 25.04. Rückmeldung, da wir dieses dann durchziehen werden. Danke.

    Donnerstag, 12. April 2018 05:36
  • >Wir werden das so machen

    Ich habe Dir keinerlei Code gegeben, den Du nun "so machen" könntest. Fragt sich also, was Du jetzt wie umsetzt. Das Speichern der Anmeldedaten im Connectionstring bzw. in einer DSN?

    DispLogin unterdrücken und keine Crredentials in der Connection angeben geht definitiv nicht, dann fehlen die Credentials und werden auch nicht abgefragt.

    Speichern der Credentials muß berücksichtigen, dass sie dadurch lesbar sind. Verschlüsseltes speichern des Connectionstrings verschiebt das Problem auf den Schlüssel der Verschlüsselung etc.

    Und ein User muß letztlich Lesezugriff haben, selbst wenn er nicht weiß, wo die von der Anmeldung benutzten Anmeldedaten dann automatisch herkommen.

    Letztlich ist die einzige Möglichkeit die nötige Entschlüsselungsinformation ein Passwort sein zu lassen, was der User eingeben muss, was ergo also nirgends gespeichert ist. Diese Passwortabfrage kann bzw. muss man dann aber selbst implementieren, und zwar sicher.

    Ich sehe eher Ziele wie

    a) Herauszufinden wo ein ODBC Treiber Credentials zur Wiederverwendung ablegt. Es wäre zu hoffen, dass in irgendeiner Form kryptographisch sicher passiert. Entweder man findet also heraus, dass man sich darauf verlassen könnte oder kriegt einen Schock, wenn das irgendwo im Klartext in der Registry gespeichert wird. Im besten Fall könnte man dafür sorgen, dass Credentials nie gespeichert und immer abgefragt werden.

    b) Möglichst von dem Mechanismus der Trusted_Connection gebrauch zu machen. Ich habe keine Ahnung inwiefern Oracle das z.B. beherrscht, aber es sagt der Zieldatenbank einfach gesagt: "Mach die Identitäsbestimmung mit dem Betriebssystem aus." und das basiert auf sehr gutem Sicherheitskonzept Kerberos.

    Den Logindialog zu unterdrücken ist jedenfalls alleine keine Lösung, wenn ein Verbindungsaufbau ein Login benötigt.

    Tschüß, Olaf.


    Olaf Doschke - https://www.doschke.name

    Donnerstag, 12. April 2018 07:48
  • 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

    Montag, 16. April 2018 12:33