ODBC Verbindungen sind definitiv nichts Neues, aber Überraschungen gibt es scheinbar immer wieder damit. Gerade letzte Woche bin ich im Zusammenhang mit Excel über die ODBC DSN Verwaltung gestolpert, die wie bekannt die 3 DSN Typen User/Benutzer, System und File/Datei bietet. Im Prinzip sind die Unterschiede ja klar (User ist für den aktuellen Nutzer von Windows sichtbar, System für alle Nutzer des Computers, File ist verteilbar zwischen Systemen), aber die File DSN spielte für Excel in meinem aktuellen Projekt eine mir bisher unbekannte Rolle.
Der Hintergrund: Wenn ich in Excel mit MSQuery Daten dynamisch importiere brauche ich dafür eine Datenbankverbindung und diese baue ich über eine der genannten DSN-Typen auf. Nachteil: Verteile ich das Excel Sheet an Kollegen, läuft es nur, wenn diese die passenden DSN Verbindungen im Datenquellen-Verwalter eingerichtet haben.
Doch man kann die DSN auch einbetten so daß keine separate DSN auf dem Computer mehr von Nöten ist. Und genau das passiert automatisch (oder sollte ich sagen automagisch ?) wenn wir für die Verbindung eine File/Datei DSN benutzen. Danach ist das Excel Sheet frei verteilbar... vorausgesetzt natürlich der Zielcomputer hat die passenden Treiber zur Verfügung.
Fazit: Man lernt auch bei alten Techniken nie aus. Aber mal ganz ehrlich: Wo hätte man dieses kleine aber wichtige Detail auch nachlesen sollen?
... und wenn du dann noch mit den korrekten Pfadangaben der //Server/Freigaben arbeitest statt mit Laufwerksbuchstaben dann hast du schon fast gewonnen. Ansonsten kann man User DNS auch schön über kleine REG Dateien verteilen, vorausgesetzt der Empfänger darf seine Registry auch manipulieren.
Kommentiert von: Riebiesel | 29. September 2009 um 11:26
Das drollige ist dass Excel nicht mal den Pfad zur File DSN braucht; es extrahiert scheinbar den nötigen Connection-String zur Datenquelle. Ein Alias für den DB-Server ist aber sicher sinnvoll.
Kommentiert von: Hans-Joerg (ME) | 29. September 2009 um 19:10