Office: Wechsel des Access Frontend auf andere Datenbanken

Hallo zusammen,

ich bin noch ziemlich neu hier bei Euch, aber ich hoffe auf viele erfolgreiche Threads :-)

Ich baue gerade eine Anwendung auf Basis von Access und komme damit auch ganz gut voran... unter anderem durch die vielen hilfreichen Beiträge hier im Forum. Frontend auf jedem Rechner und Backend über Netzlaufwerk bereitgestellt. Die Anwendung wird nach aktuellem Plan auf insgesamt 213 Tabellen in drei Datenbanken zugreifen.

Ich ertappe mich aber immer wieder bei dem Gedanken, dass es schön wäre das ganze irgendwann einmal online verfügbar zu machen.

Die Frage:
Kann ich mein Frontend später "relativ" einfach (nämlich nur an den Zugriffspunkten auf die Tabellen) auf andere Datenbanken umstellen?
Oder werde ich die gesamte Struktur dann überdenken müssen? Oder geht es zwar, bringt aber Nachteile, wenn ich das Access Frontend weiter verwende aber eine andere Datenbank dahinter lege?

Danke für Eure Antworten und die Häme habe ich bestimmt verdient :-)

:)

 

Hallo,
Access ist als Frontend tauglich.
Wird auch gerne verwendet, da man sehr einfach eine komfortable Benutzeroberfläche gestalten kann. Z. B. die gebundenen Formulare.

 

Hallo Fulgorth,

grundsätzlich kann man eine Access DB schon verwenden. Wenn Du an mehr als 200 Tabellen in mehreren DB's arbeiten musst, würde ich schon beim Start eine MS-SQL DB verwenden. Da hast Du viele Vorteile zu einer Access DB, vor allen wenn das ganze über ein Netzwerk mit mehreren Usern laufen soll. Man sollte natürlich auf gewissen Konventionen beim SQL Server achten. (Feldnamen, Indizes usw.) Du wirst später froh darüber sein.
Abgesehen davon kostet die Express Edition vom SQL Server nichts.

LG, sivi

 

Danke für die schnellen Antworten. Das hört sich doch schonmal gar nicht schlecht an.

Gibt es da eine kleine Übersicht, worauf man achten sollte, wenn man erstmal mit einer Access-DB arbeiten würde? Also zB wenn die Bezeichner nicht länger als 8 Zeichen sein dürfen, kann ich mich ja an solche Regeln schonmal in Access halten. Wenn ich mich da erstmal reinlese, damit ich später froh sein kann, ist es ja tatsächlich besser, gleich komplett in MS-SQL zu arbeiten?

 

Solange du keine access-spezifischen "Features" in den BE's hast (Nachschlagefelder, Berechnete Felder, Anlage) sollte das kein Problem sein.

Ich verwende z.b. u.a. ein Access Frontend was auf einen Postgresql-Server über ODCB zugreift, auf der eine webbasierte Buchungssoftware läuft.

 

Solange du keine access-spezifischen "Features" in den BE's hast (Nachschlagefelder, Berechnete Felder, Anlage) sollte das kein Problem sein.

Ich verwende z.b. u.a. ein Access Frontend was auf einen Postgresql-Server über ODCB zugreift, auf der eine webbasierte Buchungssoftware läuft.

Die Verbindung zum Server erfolgt über einen SSH-Tunnel via Putty, der aus der Access-Anwendung heraus gestartet wird.

 

Danke nochmal!

Ich werde mich mal auf die Suche nach einer abschließenden Liste Access-spezifischer Datenbank-Felder bzw. Besonderheiten machen oder war "Nachschlagefelder, Berechnete Felder, Anlage" schon abschließend? Bin aber hier natürlich auch froh über jeden Hinweis.

 

Bei einem Accessfile als Backend kann man nur die Tabellen ins FE verknüpfen.

Wenn man das gleichlautend für andere Datenbanken (aktive DBMS) macht, wird man eher einen Leistungsabfall bemerken, weil Jet-SQL über einen anderen SQL-Dialekt mit den Daten kommunizieren muss. Vor allem verschenkt man aber die Leistungsfähigkeit eines aktiven DBMS, wenn man dieses nicht selber arbeiten lässt.

Ergo: In der Praxis wird man das FE bei einem Umstieg von Access auf bspw. MS SQL Server als Backend im wesentlichen neu programmieren. Wenn man also nicht fehlinvestieren möchte, wird man sich gleich mit dem Ziel-DBMS beschäftigen, gerne erst einmal mit der Express-version.

Rückfrage: Alle schön verwoben in einem geplanten Datenmodell?
Oder eher Tabelle pro Woche oder Farbe oder so?

 

Hey ebs17,

ja toll, hatte ich mich gerade gefreut, dass alles so einfach aussieht...*wink.gif*

Jetzt zweifle ich wieder. Aber das ist ja auch gut so :-)

Die Tabellen sind sehr gut verwoben und ergeben eine gewisse Datenbankintelligenz. Insbesondere aber liegt die hohe Anzahl der Tabellen sicherlich daran, dass ich sehr darauf geachtet habe, die 6 Normalformen so weit wie möglich einzuhalten, was meinem Projekt auch sehr dienlich ist. Außerdem habe ich in einzelnen Bereichen unterschiedliche Tabellen für unterschiedliche Qualitäten der gleichen Informationen genutzt.

Beispiel:
Adresse (unqualifiziert) Straße (Text), PLZ (Text), Ort (Text), Land (Text)
wird in einer Routine - wenn möglich - automatisch umgewandelt in:
Adresse (qualifiziert) - Straße(ID), PLZ (ID), Ort(ID), Land (ID)
(nur grober Umriss des deutlich komplexeren Gebildes - die Adressierung ohne Namen kostet mich allein 17 Tabellen - ist aber auch ein wichtiger Aspekt)

Ziel war dabei:
Adresseingabe (händisch und eingelesen) kann stets aufgenommen (und dokumentiert) werden. Es können automatisierte Korrekturen erfolgen und Korrekturaufträge erteilt werden wo es nötig ist und das System nicht eindeutig entscheiden kann.

 

Wow, so etwas habe ich noch gar nicht gesehen. Allermeistens endet's schon bei der 3. Normalform.
Damit hast Du ein dickes Plus in Sachen Datenintegrität und Redundanzvermeidung, erhöhst aber umgedreht den Rechenaufwand, weil ja schon für einfache Anzeigen viele Tabellen zu verknüpfen sind. Man durchdenke an der Stelle nur einmal, was ein einzelner JOIN so macht.
Aus der Kurzbeschreibung heraus würde ich auch unterstellen, dass zu verwaltende Datenmengen über jene eines privaten Telefonbuches deutlich hinausgehen.

Da brauchst Du von Haus aus Rechenpower, auch von der Datenbankseite her. Schon aus diesem Grund würde ich mit einem Accessfile als Backend gar nicht erst anfangen.

Vergleiche Grundlagen - SQL ist leicht (8) - Index

=> Jet (Access) holt sich die Daten, um sie lokal zu verarbeiten. Wieviel das jeweils sind, ist von verschiedenen Einflussfaktoren abhängig wie Abfragedesign, Indexnutzung. Wenn Jet mit einem anderen SQL-Dialekt kommunizieren muss, wird das nicht immer 1:1 gut gehen, womit dann mglw. Abfragen aufgeteilt und Teilergebnisse geholt werden, was unter dem Strich mehr Traffic bedeuten wird.

=> Ein aktives Datenbankmanagementsystem ist nicht eine dumme Datei zum Daten speichern, sondern darüber hinaus ein Dienst, der selber rechnen kann, und das i.d.R. deutlich leistungsfähiger als Jet. Im Ergebnis würde man sich also nicht Daten zum Rechnen holen, sondern gleich ein Rechenergebnis.
Das Access-FE kann sich dort dann beschränken auf den letzten Feinschliff wie Sortierungen, Ausgabeformatierung.

Im aDBMS kann man erheblich Verarbeitungslogik zentralisieren, so dass man über Schnittstellen verschiedene Frontends aufsetzen könnte.

Das alles spielt auch schon in die Richtung des Wunsches nach Online-Präsentation eine Rolle. Bandbreite und Traffic ist dort ja ein ganz anderes Thema als in einer lokalen Umgebung.

Unter dem Strich: Eine Datenbank richtig nutzen oder nur deren Tabellen irgendwo verknüpfen - das sind ganz unterschiedliche Kriege.

 

Danke ebs17!

Die Rechenpower ist mir bewusst. Aber ich habe zum Glück genau die Anforderungen an mein Projekt, die sich mit den Notwendigkeiten und Vorzügen kompletter Normalformen decken. Wie leistungsfähig das ganze dann mit einer Großen Anzahl von Datensätzen läuft, bleibt abzuwarten, kann aber dann ja zum Glück auch gut justiert werden. Nicht zuletzt deshalb betreibe ich parallel verschiedene "Qualitätslevel" das erhöht zwar den Speicherbedarf, jedoch nicht den des Arbeitsspeicher, weil entweder die eine Qualitätsstufe oder die andere vonnöten sein wird. Neben der Möglichkeit alles bis in die kleinste Haarspitze geclustert zu haben und quasi nicht einen Wert doppelt vorliegen zu haben, habe ich dann noch die Möglichkeit eine Grenze zu ziehen, wo es für die "aktuellen" Ressourcen und Datenvolumina noch nicht ausreichend rund läuft.
Ähnlich wie in einem wirtschaftlich denkenden Betrieb stehen mir zwar alle Türen offen, ich kann mich aber auf die gewinnbringendsten Abläufe fokussieren und das "schön" machen für die Momente niedriger Auslastung bereitstellen... Zumindest so meine Idee, wenn Du verstehst was ich meine.

Ich habe mir Deinen Beitrag mal angesehen. Erstmal Respekt für das "Tutorial" da, umreißt ganz gut das was ich in mühsamen Stunden seinerzeit aus meinem Doberenz/Gewinnus Office Access Programmierung 2007 gezogen habe :-)

Das Ganze hat mich tatsächlich nun dazu verleitet einmal den SQL Server Developer, Express und SSMS runterzuladen und damit zu starten... aktuell fühle ich mich allerdings noch ein bisschen wie der Ochs vorm Berg. Da rächt sich wohl, dass ich kein Informatiker bin und nur ein halbwegs ernsthaftes Hobby betreibe.

Habe mir jetzt erstmal angesehen, wie ich das ganze einrichten kann. Aber so richtig weiß ich noch nicht worauf ich mich da jetzt eingelassen habe und wie ich da am besten vorgehe.

Also was mir auch schon aufgefallen ist: Ohne es zu wissen nutze ich in meinem Access-Projekt ohnehin schon SQL

Code:

Das ist zwar mittlerweile in meinem Projekt schon veraltet (Setze das jetzt über eine andere Routine zusammen - jetzt nicht nur optisch besser moduliert - was fast genauso schnell geht und bessere Möglichkeiten beim Updaten und Anpassen bringt. Aber um zu zeigen, wie ich mit der Datenbank spreche, könnte das ja vielleicht helfen.

Die Frage ist jetzt nur: Kann ich mit MS SQL Server genauso kommunizieren aus Access? Macht das Sinn? Kannst Du (… oder natürlich gern auch jeder andere) mir eine Seite (Tutorial) empfehlen, wo ich die Erstellung einer Datenbank über MS SQL (Express) anschauen kann? Ich habe mich bei Problemen idR immer bei Microsoft selbst schlau gemacht, wie die einzelnen Objekte funktionieren und was sie für Eigenschaften, Funktionen und Module haben. Das gilt dann 1:1 für MS SQL? MS SQL bietet kein Frontend in dem Sinne oder?

…..

Möglicherweise bin ich einfach nur geflasht gerade von dem vielen neuen Zeug für mich, daher bitte ich vollkommen hirnrissige Äußerungen und Fragen zu entschuldigen :-)

 

Also Eberhard,

nachdem ich meine Gedanken etwas sortiert habe... Wie verwende ich mit Access statt dem "kastrierten" Jet SQL jenes, das mir alle Möglichkeiten und Vorteile bereitstellt?

Nicht die Antwort.... die richtige Frage zu Finden ist die Kunst. :-)

 

Wenn man sein aktives DBMS kennt, kann man sich als Basis mit dessen SQL-Dialekt auseinandersetzen, beim SQL Server wäre das Transact-SQL.

Praktische Zugriffe:
- Erstellung von Views im SQL Server und verknüpfen dieser in das Frontend. Damit wird im Unterschied zu Tabellen schon mal einiger Abfrageaufwand erledigt.
- Verwendung von Pass-Through-Abfragen
- Kommunizieren über ADODB direkt mit dem SQL Server und dann auch mit T-SQL

Mit einigen Vorkenntnissen zu Access selber ist dieses Werk sehr hilfreich:
Access und SQL Server
Die Autoren: Um das optimale Buch für die Symbiose aus Microsoft Access und Microsoft SQL Server zu schreiben, braucht man ein entsprechendes Autorenpaar: Bernd Jungbluth mit seiner über 10jährigen Migrationserfahrung von Access nach SQL Server sowie vielen Workshops und Vorträgen und André Minhorst mit seinen zahllosen Veröffentlichungen zum Thema Microsoft Access werfen ihr komplettes Know-how zu diesem Thema in die Waagschale.

Code:

6. Normalform und Aufzählungsfelder? Erstaunen macht sich breit ...

 

Wie gesagt, das ist veraltet. Das aktuelle Projekt kommt fast ohne String-Variablen aus. Dafür sieht man im Quellcode nur noch schwer, was passiert wenn man das Projekt nicht kennt - fürs Forum eher unpraktisch. Die "Aufzählungsfelder" waren auch da nicht wirklich Aufzählungsfelder, sondern Übersetzungsfelder, da das Projekt aktuell in drei Sprachen läuft und drei weitere im Aufbau sind... die Grammatik macht es schwer, wenn man auch exotische Sprachen aus dem Arabischen erfassen will und nicht einfach Sätze hinklatscht. Da das aber nicht mein Hauptaugenmerk ist, hinke ich da auch noch weit hinterher.

 

Hallo,

Da wären 3 Felder aber auch ein Normalisierungsfehler, gerade wenn es mal mehr Sprachen werden sollen/können.