2009-03-05 6 views
1

Meine Firma verwendet SAI stark und um Berichte von diesem System zu erstellen, verwenden wir ODBC, um eine Verbindung zur Datenbank herzustellen. Unser Setup ist im Moment regional und wir haben daher separate Umgebungen für jede Region. Beim Versuch, mit MS ACCESS auf diese Umgebungen zuzugreifen, stelle ich fest, dass ich keine Verknüpfung zu Tabellen in verschiedenen Umgebungen herstellen und genaue Daten abrufen kann.Access Caching ODBC-Verbindungseinstellungen

Ich kann die Verbindungen zu verschiedenen Umgebungen mit den spezifischen DSNs erstellen. Ich kann dann auf die Daten zugreifen, aber die erste Tabelle, die ich öffne, egal, zu welcher Region sie gehört, funktioniert einwandfrei. Danach verwenden jedoch alle Tabellen unabhängig von der Region, zu der sie gehören, die DSN-Einstellungen aus der ersten geöffneten Tabelle. Wenn ich Access herunterfalle und neu starte, kann ich mit Daten aus einer anderen Umgebung beginnen, die dann funktionieren wird, aber der Rest der Daten wird dann diese DSN-Einstellungen widerspiegeln. Außerdem, wenn ich auf das Eigenschaftsblatt schaue, sind die DSN Einstellungen wie sie sein sollten.

Lassen Sie mich auch hinzufügen, dass die Tabellen für jede Region alle den gleichen Namen haben. IE die Verkaufstabelle ist Verkäufe in allen Umgebungen, die Produktionstabelle ist die Produktionstabelle in allen Regionen. Als Ergebnis, wenn ich von mehreren Umgebungen auf die Verkaufstabelle verlinke, muss ich in MS ACCESS umbenannt werden.

Antwort

0

Eine Option, die Sie haben könnten (obwohl ein wenig langatmig) wäre, eine Access-Datenbank für jede Region zu erstellen, die mit einer Regions-Tabelle verknüpft ist. zB haben Sie die Verkaufstabelle und die Produktionstabelle für die Region Europa in einer Zugriffsdatenbank und legen Sie diese aus ASIA in eine andere Datenbank.

Sobald Sie diese Einrichtung eingerichtet haben, ist es möglicherweise viel einfacher, eine dritte Access-Datenbank zu verwenden, um eine Verknüpfung zu den beiden anderen Access-Datenbanken herzustellen.

Ich hoffe, das ist nützlich.

+0

Ja sehr langatmig, und Access mochte diese Lösung auch nicht. –

+0

ohh, es war einen Versuch wert. Müsste dann auf statische Tabellen zurückgreifen. –

+0

Ich versuche Sql Server zuerst. Es sieht vielversprechend aus. Ich habe nur sehr wenig Erfahrung mit SQL Server! –

1

Ich würde einen Blick auf diese SO Question einen letzten Monat beantwortet haben.

Es beschreibt eine Reihe von Methoden zum Erzwingen von Access zum erneuten Verknüpfen von ODBC-Tabellen und bietet Ihnen bei einem Fehlschlagen die Möglichkeit, die Datenbank programmgesteuert mit einem kleinen function that you'll find on my blog neu zu starten.

1

Ich vermute, Sie lassen ein paar Details, die wir brauchen.

Wenn Sie diese erste Tabelle öffnen, werden Sie aufgefordert, sich anzumelden? (Dies ist eine kritische Information). Wenn Sie "verschiedene" Links verwenden und die Benutzer-ID/das Passwort in diesen Links speichern, sollten Sie keine ODBC-Eingabeaufforderungen erhalten und Sie können daher problemlos mit mehr als einer Region arbeiten.

Es klingt jedoch so, als ob Sie einen Satz von Links haben und auf einen anderen Server verweisen/erneut verlinken möchten. Dies kann funktionieren - aber NICHT, wenn Sie ODBC-Eingabeaufforderungen sehen/zulassen.

Wenn Sie die Benutzer-ID/das Passwort in die Links einfügen, dann sollten Sie in der Lage sein, zu einem der beiden Systeme zu wechseln. Wenn Sie dies jedoch tun, sind BEIDE uid/password-Kombinationen ARE und WILL gleichzeitig zur gleichen Zeit aktiv.

Wohin die Dinge gehen SEHR falsch ist, dass wenn Sie mit einer falschen Anmeldung neu verknüpfen, dann die vorherige UID/Passwort verwendet wird! Und in der Tat, wenn Sie für eine Anmeldung TEST (auch eine schlechte!), Dann wird die erste legale Anmeldung verwendet werden! Am Ende des Tages bedeutet dies, dass der Schwachpunkt hier WANN ist/wenn Sie nach einer Anmeldung fragen, wird es "Ja" für eine legale Anmeldung geben, auch wenn die Anmeldung schlecht ist! (Da Access auf die vorherige legale Anmeldung zurückgreift), MÜSSEN Sie sich mit diesem Problem befassen.

So wahrscheinlich Dinge zeigen auf Ihren Code, der eine Anmeldung "Test" vor dem Re-Link macht.Was ich vorschlagen würde ist, dass Ihr "Test" -Anmeldecode OK zurückgibt, dann führen Sie eine Pass-Through-Abfrage aus, um den Datenbanknamen zurückzugeben - wenn dieser Datenbankname/Server falsch ist, dann lehnen Sie diese Anmeldung ab und verknüpfen Sie NICHT neu.

So kritisch ist hier, wie Sie für die neue Anmeldung/Server testen? Und Sie möchten NIEMALS, dass die ODBC-Anmeldeaufforderung angezeigt wird - denn wenn ein Benutzer abbricht oder die falsche Anmeldung eingibt, verwendet Ihr ReLink-Code die vorherige zwischengespeicherte Anmeldung.

Sie sollten in der Lage sein, denselben gegebenen Tabellensatz erneut zu verknüpfen und auf einen anderen Server zu verweisen - Sie müssen jedoch sicherstellen, dass die verwendete Anmeldung tatsächlich funktioniert.

Last but not least: Zugriff verwendet IMMER eine DSN weniger Verbindung. Die einzige Ausnahme ist, wenn Sie einen System-DSN verwenden. Wenn Sie also einen Datei-DSN erstellen und erneut verknüpfen, wird der DSN ab diesem Punkt ignoriert und nicht verwendet. (Dadurch können Sie sagen, dass die Anwendung auf andere Desktops verteilt werden soll, ohne dass ein DSN kopiert/aufgenommen werden muss). Sie verwenden fast immer eine DSN-lose Verbindung, und wenn nicht, dann schlage ich vor, dass Sie die System-DSNs ablegen, da Access das USER/Passwort von solchen System-DSNs nicht verwenden kann - auch wenn Sie das USER/Passwort darin einfügen DSN wird immer noch ignoriert.

Auch wenn Sie neu verknüpfen, verwenden Sie das dbAttachSavePWD - Sie sollten nicht müssen, aber ich würde für den Test enthalten.

Wenn Sie den ODBC-Treiber verwenden/zulassen, um den Benutzer zur Anmeldung aufzufordern - dann müssen Sie dies beseitigen und sicherstellen, dass der Code die Anmeldung durchführt.