Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Tabelle gelöscht + neu erstellt, ODBC-String unverändert
zurück: Fehlende Bibliothek weiter: Per Button aus mehreren Tabellen Datensätze löschen Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Feedback Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
sthm
lerne täglich dazu...


Verfasst am:
23. Apr 2010, 17:05
Rufname:
Wohnort: Westsachsen

Tabelle gelöscht + neu erstellt, ODBC-String unverändert - Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo miteinander!
Nach einer langen Zeit selbständigen Arbeitens komme ich mal wieder an meine Grenzen - und damit zurück ins Forum:
Eine externe Datenbank und eine Reihe unabhängiger Tabellen soll beim Start meiner lokalen DB immer neu per ODBC eingebunden werden. Die Liste der betroffenen Tabellen incl. aller Parameter habe ich in einer eigenen Tabelle tbl_xODBC-Tabellen gespeichert. Neuerdings erwarten einige der externen Tabellen jeweils ein Passwort. Kein Problem, das baust du in den ODBC-String mit ein - dachte ich. Klappt aber nicht.
Hier mein (gekürzter) Code:
Code:
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim rst As DAO.Recordset
    Dim sTableName As String
    Dim sExtTableName As String
    Dim sConn As String
    Dim sDSNDescription As String
   
    sConn = ""
    Set db = CurrentDb
    Set rst = db.OpenRecordset("tbl_xODBC_Tabellen", dbOpenSnapshot)
    Do While Not rst.EOF
        If rst!aktiv Then
            sTableName = rst!sTbl_name
            sExtTableName = rst!sExt_tabelle
            ' ...
            If ODBCTabelle_exist(sTableName) Then
                DoCmd.DeleteObject acTable, sTableName
            End If
'wenn der Code hier angehalten wird, fehlt die Tabelle wirklich
            sConn = "ODBC;DSN=" & sDSNDescription & ";" _
                  & "SourceDB=" & fct_getStdString("db_pfad") _
                                                       & rst!sSourceDB & ";" _
                  & "SourceType=" & rst!sSourceType & ";" _
                  & "UID=" & rst!sUID & ";PWD=" & rst!sPWD & ";" _
                  & "Exclusive=" & IIf(rst!boExclusive, "Yes", "No") & ";" _
                  & "BackgroundFetch=Yes;" & "Collate=Machine;Null=Yes;" _
                  & "Deleted=No;;Table=" & sExtTableName
            Set tdf = db.CreateTableDef(sTableName)
            tdf.Connect = sConn
            tdf.SourceTableName = rst!sExt_tabelle
            db.TableDefs.Append tdf
        ' ...
    Loop
Die verknüpfte Tabelle wird erstellt, hat aber den alten ODBC-String, in dem die Einträge
Code:
UID=;PWD=;
fehlen. Ich vermute, es handelt sich um irgendeine Rechtefrage (die Original-DB wurde nicht von mir erstellt). Wenn ich aber per Hand eine Verknüpfung auf eben dieselbe Tabelle erstelle, kann ich zumindest den Benutzernamen in den String einfügen.
Am Rande: Ist es eigentlich egal, in welcher Reihenfolge man die Bezeichner DSN=, SourceDB= usw. benennt? Oder ist das genau mein Problem, dass ich nicht die richtige Reihenfolge habe?
SteffenHM
MissPh!
Office-VBA-Programmiererin


Verfasst am:
23. Apr 2010, 17:16
Rufname:
Wohnort: NRW


AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo.
Zitat:
Die verknüpfte Tabelle wird erstellt
Wo ist dann das Problem? Dass UID und PWD im Connect-String der eingebundenen Tabelle fehlen, ist völlig normal. Wäre ja noch schöner, wenn man da die ganzen Passwörter auslesen könnte. Wink
_________________
Gruß MissPh!
sthm
lerne täglich dazu...


Verfasst am:
23. Apr 2010, 18:07
Rufname:
Wohnort: Westsachsen

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Ähm - ja? Aber...
1. Hab ich hier im Forum jede Menge Anleitungen gefunden, wo Benutzernamen und Passwörter genau in den String eingearbeitet werden. Ob sie auch dort gespeichert werden bzw. später dort auslesbar sind, weiß ich natürlich nicht. Aber das wäre ja auch egal, denn
2. ist das Ganze nur für mich gedacht. Der Nutzer sieht ja den Code nicht.
Der Hintergrund ist der: Ohne Benutzerkennung hab ich keine Schreibrechte in der Tabelle, was ich aber brauche. Aber bei jedem Zugriff das PW abfragen, ist ja auch nicht das Gelbe vom Ei (obwohl ich froh wäre, wenn er wenigstens das täte!).
Folgendes hab ich beobachtet: Beim manuellen Verknüpfen externer Tabellen kann ich an einer Stelle angeben "Kennwort speichern". Komischerweise wird das Kennwort dann nie abgefragt. Aber im ODBC-String steht dann
Code:
UID=;
Das Passwort fehlt. Und ich habe auf einmal Schreibzugriff!
Wenn ich das per Code hinkriege, ist mir alles andere egal.
SteffenHM
MissPh!
Office-VBA-Programmiererin


Verfasst am:
23. Apr 2010, 22:08
Rufname:
Wohnort: NRW

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo noch einmal.

Was genau meinst du mit ODBC-String? Du baust einen Connect-String auf, inklusive UID und PWD - sind die Werte dort korrekt eingefügt? - und bindest mit diesen Angaben die Tabelle ein. Was dann, wie prüfst du das Ergebnis?
Zitat:
Ist es eigentlich egal, in welcher Reihenfolge man die Bezeichner DSN=, SourceDB= usw. benennt? Oder ist das genau mein Problem, dass ich nicht die richtige Reihenfolge habe?
Bei benannten Argumenten dürfte die Reihenfolge egal sein.
_________________
Gruß MissPh!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
24. Apr 2010, 02:17
Rufname:


AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo Steffen,

da muß ich MissPh leider widersprechen: Es ist lediglich der falsche Aufruf von CreateTableDef dafür verantwortlich, daß Dein Passwort und die UserID nicht gespeichert werden. Versuch's mal mit der Zeile:
Code:
            Set td = CurrentDb.CreateTableDef(strLocalTableName _
                                            , dbAttachSavePWD _
                                            , strRemoteTableName, strConnect)
Mit dem Attribut wird das Kennwort im Connectionstring (hier in "strConnect") zusammen mit der UserID gespeichert. "strLocalTableName" speichert den Namen der Tabelle, wie er in Access lauten soll und in "strRemoteTableName" wird der Name der entfernten Tabelle hinterlegt. Im Connectionstring wird, wie gehabt, UID und PWD festgelegt.

Daß beides auch tatsächlich gespeichert wird, kann man in Access 2007 zum Beispiel einfach sehen, indem man mit der Maus über den Tabellennamen im Navigator fährt, wird dann als Tooltip angezeigt. In VBA kann man den Connectionstring so abfragen:
Code:
?CurrentDb.TableDefs(1).Connect
(für Tabelle 1, alternativ Tabellennamen verwenden)

Da steht dann der vollständige Connectionstring inklusive UserID und Passwort im Klartext. Drum soll man ja eigentlich auch diese Daten hier nicht hinterlegen. Aber Access läßt einem da nicht viel Wahl, denn wenn man es nicht tut, muß man die beiden Daten bei jeder ersten Verwendung der Tabelle nach dem Starten von Access eingeben, was sehr nervig ist und damit die User dazu zwingt, eine Benutzernamen/Passwortkombination zu erfahren/zu wissen, die sie eigentlich gar nicht wissen müssen. In einer Runtime können diese Daten ohnehin nicht abgefragt werden, allerdings ist das natürlich für einen Hexeditor oder Debugger auch kein großes Hindernis, wenn man es drauf anlegt. Die meisten Leute kann man damit aber von den Kennwörtern schon fernhalten.

Wenn es um Hochsicherheit geht, führt allerdings kein Weg daran vorbei, diese Daten jedesmal von Hand einzugeben. Handelt es sich bei dem entfernten Server um einen SQL Server, kann man allerdings einfach die Sicherheit auf "Integrierte Sicherheit" einstellen, damit wird automatisch die Windows Benutzeranmeldung als Sicherheitseinstellung verwendet und es werden keine Kennwörter oder Benutzernamen mehr gespeichert/übertragen. Allerdings setzt das Mehraufwand auf dem Server voraus, weil man dann natürlich die betreffenden User auf dem Server anlegen oder zumindestens in einer entsprechenden Gruppe in der Domäne einfügen und dann die Gruppe im Server einfügen muß.
Bei allen anderen Servern, die kein solches Sicherheitsmodell haben, hilft wohl leider nur die oben beschriebene Methode.

Gruß

Christian
MissPh!
Office-VBA-Programmiererin


Verfasst am:
24. Apr 2010, 20:46
Rufname:
Wohnort: NRW

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo Christian,

da muss ich dir leider ebenfalls widersprechen, meiner Erfahrung nach spricht überhaupt nichts dagegen, die Parameter der CreateTableDef-Methode in der oben gezeigten Form über die TableDef-Eigenschaften "nachzureichen". Und natürlich kann man den soeben zugewiesenen Connect-String des aktuellen TableDef-Objekts auch genauso wieder auslesen wie man ihn zugewiesen hat. Interessant wird es aber, wenn man nach dem Einbindungsprozess in die Tabelle MSysObjects schaut und sich den Inhalt der dort abgelegten Connect-Eigenschaft der eingebundenen Tabellen ansieht.

Was die Eingabe des Passworts betrifft, das der User eigentlich gar nicht kennen sollte, so sehe ich auch das anders. Jeder User sollte sich mit seinem eigenen Account und Passwort anmelden und somit nur genau die Rechte haben, die ihm zugewiesen wurden - und zwar bei jedem Start der Anwendung.

_________________
Gruß MissPh!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
24. Apr 2010, 21:21
Rufname:

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo MissPh,

sorry, war etwas unglücklich formuliert. Ich bezog mich mit meinem Widerspruch nicht auf das Nachreichen, sondern hierauf:
Zitat:
Dass UID und PWD im Connect-String der eingebundenen Tabelle fehlen, ist völlig normal. Wäre ja noch schöner, wenn man da die ganzen Passwörter auslesen könnte.
Und wie oben gezeigt, ist es völlig normal, daß beides im Connectionstring enthalten ist und auch wieder ausgelesen werden kann, sofern es da gespeichert wurde.

Mit der UserID/Kennwort gebe ich Dir prinzipiell recht, das Problem liegt meistens an schlechtem Datenbankdesign oder "Faulheit der Administratoren". Es wird oft vom Programmierer eine eigene Benutzerverwaltung implementiert, die dann nur für die Applikation zuständig ist und auf einfachen Tabellen basiert (und meistens auch nicht besonders sicher ist), statt die vorhandenen geprüften Sicherungsverfahren zu verwenden. Da könnte man natürlich auch für jeden Benutzer eine UserID auf Datenbankebene einrichten und hätte sogar den Vorteil, abfragen zu können, wer genau gerade mit der Datenbank verbunden ist. Aber dann gibt es IT-Abteilungen, die lieber nur ein oder zwei UserIDs auf Datenbankebene einrichten und diese sind dann für die ganze Anwendung zu verwenden - in solchen Fällen hilft es dann auch nur, die Kennungen direkt im Connectionstring zu speichern.
In Fällen von Webanwendungen wiederum ist die Trennung von Datenbankanmeldung und Applikationsanmeldung in Ordnung, weil sich ja auch nur der Webserver bei der Datenbank anmeldet und keiner an die BenutzerID und das Kennwort herankommt. Daher wird diese Technik "in alter Gewohnheit" auch eben bei Intranetanwendungen wie Access als Frontend genommen, der Admin spart sich damit die ganze Arbeit von Neuanmeldungen, Kennwortumbenennung, Löschungen alter UserIDs usw.
Deswegen sage ich ja - bei SQL Server würde ich persönlich grundsätzlich die Windows Sicherheit verwenden, das spart schon mal die gesamte Benutzerverwaltung. Aber das geht natürlich leider nur mit SQL Server und diese Methode wird auch nicht in jedem Unternehmen verwendet - warum, weiß der Geier.

Gruß

Christian
MissPh!
Office-VBA-Programmiererin


Verfasst am:
25. Apr 2010, 18:30
Rufname:
Wohnort: NRW

Re: AW: Tabelle gelöscht + neu erstellt, ODBC-String unverän - Re: AW: Tabelle gelöscht + neu erstellt, ODBC-String unverän

Nach oben
       Version: Office 2003

Mit "Connect-String der eingebundenen Tabelle" meine ich folgendes:
MissPh! - 24. Apr 2010, 20:46 hat folgendes geschrieben:
Interessant wird es aber, wenn man nach dem Einbindungsprozess in die Tabelle MSysObjects schaut und sich den Inhalt der dort abgelegten Connect-Eigenschaft der eingebundenen Tabellen ansieht.
Also die nach Ablauf des Codes auslesbaren Eigenschaften.
_________________
Gruß MissPh!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
25. Apr 2010, 18:41
Rufname:

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo MissPh,

ich weiß nicht, was dann in der Systemtabelle steht, die benutze ich eigentlich nie.

Aber mit "?CurrentDb.TableDefs(1).Connect" kann ich den Connectionstring inklusive Benutzername und Kennwort auch (bzw. nur) nach dem Ablauf des Codes auslesen.

Gruß

Christian
MissPh!
Office-VBA-Programmiererin


Verfasst am:
25. Apr 2010, 19:32
Rufname:
Wohnort: NRW

AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Das muss dann wohl an dem eingesetzten ODBC-Treiber bzw. dem zugrunde liegenden DBMS liegen. Meine Erfahrungen basieren auf der Verknüpfung mit Informix-Datenbanken - und was kommt bei euch zum Einsatz?
_________________
Gruß MissPh!
sthm
lerne täglich dazu...


Verfasst am:
26. Apr 2010, 17:24
Rufname:
Wohnort: Westsachsen


AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert - AW: Tabelle gelöscht + neu erstellt, ODBC-String unverändert

Nach oben
       Version: Office 2003

Hallo Ihr beiden,
da habt Ihr ja inzwischen schön weiter diskutiert! Danke an Christian für die ausführlichen Erläuterungen und den Tip, die Parameter gleich mit CreateTableDef zu übergeben. Ist zumindest die elegantere Methode. Ich hatte inzwischen angefangen, zB. dbAttachSavePWD nachträglich über TableDef.Attributes anzuhängen.
Ich will ja nicht nerven, aber trotzdem klappts nicht. Zwei Probleme:
1. Die manuell erstellten Verknüpfungen (sprich Tabellen) haben immer Schreibrechte, die per VBA erstellten nicht. Und das, obwohl beide auf dieselbe fremde Tabelle zugreifen! Jetzt hab ich mir mal die Systemtabelle MSysObjects angesehen, um evt. noch weitere Unterschiede zu finden. Gibt es aber nicht. Aber ich merke immer wieder folgendes:
2. Der Connectionstring in MSysObjects (der ja auch a.u. als Tooltip gelesen werden kann) wird nur unregelmäßig aktualisiert. Ich hab das mit für meinen Zweck unerheblichen Teilen mal probiert, zB.
Code:
SourceDB=C:\MeinPfad\
oder
Code:
SourceDB=c:\meinpfad
bzw.
Code:
Deleted=Yes
oder
Code:
Deleted=No

Immer steht irgendeine Vorgängerversion drin, nie die aktuell angegebene. Auch ein
Code:
    CurrentDB.TableDefs.Refresh
zwischen Löschen und Neuerstellen der Verbindung ändert daran nichts.
Kann mir jemand weiter helfen? Danke schon mal!
SteffenHM
Nachtrag: sthm am 27. Apr 2010 um 15:19 hat folgendes geschrieben:
Ok., das Thema hat sich erledigt. Mein Problem liegt woanders. Deshalb hab ich einen neuen Thread aufgemacht: Verknüpfte Tabelle - manuell o. VBA > anderes Ergebnis?
SteffenHM
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: Kreuztabellenabfrage für neue Tabelle nutzen 3 WaterMan 805 06. Jul 2004, 14:39
mabe38 Kreuztabellenabfrage für neue Tabelle nutzen
Keine neuen Beiträge Access Tabellen & Abfragen: Tabelle exportieren als Excel2000 Arbeitsblatt 1 thomassch 916 06. Jul 2004, 12:46
stpimi Tabelle exportieren als Excel2000 Arbeitsblatt
Keine neuen Beiträge Access Tabellen & Abfragen: tabelle exportieren 1 Gast 1501 01. Jun 2004, 12:25
Willi Wipp tabelle exportieren
Keine neuen Beiträge Access Tabellen & Abfragen: Duplikate einer Tabelle löschen?! 3 Esel 2108 28. Mai 2004, 08:53
lothi Duplikate einer Tabelle löschen?!
Keine neuen Beiträge Access Tabellen & Abfragen: Spaltennamen einer Tabelle ermitteln 1 Alexander Neron 899 27. Mai 2004, 13:47
lothi Spaltennamen einer Tabelle ermitteln
Keine neuen Beiträge Access Tabellen & Abfragen: kein Wert in der Tabelle, dann immer Null (0)?? 3 Michel_9 1005 26. Mai 2004, 14:28
Michel_9 kein Wert in der Tabelle, dann immer Null (0)??
Keine neuen Beiträge Access Tabellen & Abfragen: Operant aus Tabelle in Abfrage verwenden 3 AccessGeek 673 06. Mai 2004, 09:15
lothi Operant aus Tabelle in Abfrage verwenden
Keine neuen Beiträge Access Tabellen & Abfragen: Tabelle formatiert in txt-Datei exportieren 1 robby 1115 12. Apr 2004, 23:10
Helge Tabelle formatiert in txt-Datei exportieren
Keine neuen Beiträge Access Tabellen & Abfragen: Tabelle aus Abfrage erstellen 1 dasti 3317 09. Apr 2004, 12:14
Gast Tabelle aus Abfrage erstellen
Keine neuen Beiträge Access Tabellen & Abfragen: Zeilenumbruch nach Einfügen Word Tabelle 2 topflop 1698 30. März 2004, 16:06
Gast Zeilenumbruch nach Einfügen Word Tabelle
Keine neuen Beiträge Access Tabellen & Abfragen: neue Tabellen erstellen aus vorhandener Tabelle 6 moni 2010 29. März 2004, 15:39
moni neue Tabellen erstellen aus vorhandener Tabelle
Keine neuen Beiträge Access Tabellen & Abfragen: Wert einer Abfrage in Tabelle kopieren? 1 BerlinerWolf 2009 21. März 2004, 12:43
Maya Wert einer Abfrage in Tabelle kopieren?
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Dreamweaver Forum