Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Tabellen einbinden oder lieber ADO/DAO

Begonnen von StephanC, Juli 18, 2013, 21:17:25

⏪ vorheriges - nächstes ⏩

StephanC

Hallo Forum,

ich würde gerne eine Datenbank erstellen um Adressen und noch ein paar Daten zu verwalten. Hier stellt sich mir aber jetzt gerade die Frage, wie ich den Zugriff auf die Tabellen gestalte. Binde ich diese im Formular ein und nehme dann die Standart-Access-Schaltflächen oder soll ich die Tabellen doch lieber per Recordset einhängen.
Gibt es eine Faustregel, wann man was macht ? Ich sehe da derzeit keine Vor- bzw. Nachteile ? Vorteil bei Recordset wäre ja, das ich ja relativ einfach zum SQL-Server switchen kann - wobei das ja auch geht, in dem ich die Tabellen einfach einbinde/verknüpfe, oder ?
Liegt vermutlich am Wetter, das ich ein Brett vorm Kopf habe ,)

Gruß,
Stephan

MzKlMu

Hallo,
gebunden Formulare mit gespeicherten Abfragen (nicht die Tabellen) als Datenherkunft alles andere wäre das Rad neu erfinden.
Access macht mit gebundenen Formularen viel Standardfunktionalitäten die ansonsten mit ziemlichem Aufwand programmiert werden müssen.
Servertabellen kannst Du einbinden.
Gruß Klaus

Wurliwurm

Zitat von: StephanC am Juli 18, 2013, 21:17:25
Gibt es eine Faustregel, wann man was macht ? Ich sehe da derzeit keine Vor- bzw. Nachteile ? Vorteil bei Recordset wäre ja, das ich ja relativ einfach zum SQL-Server switchen kann - wobei das ja auch geht, in dem ich die Tabellen einfach einbinde/verknüpfe, oder ?

Der Vorteil des Einbindens ist, daß hier alles ohne Coding machbar ist. Es legt einfach eine Mausklickebene über die Funktionalität. Der Nachteil davon ist, daß hier keine Feineinstellungen machbar sind. Es ist wie der Unterschied Fertiggericht - selber kochen.

DAO geht nur mit einer Accessdatenbank, es ist auf die Jet-Engine beschränkt. Damit scheidet sowohl der SQL Server als auch andere Datenbanken aus.

ADO hat den Vorteil, daß es mit allen möglichen Datenbanken geht, daß es auch fortgeschrittene Konzepte wie Transaktionen, pessimistisches Sperren etc. ermöglicht. Der Nachteil ist, daß man solche Konzepte kennen muß Die Zielgruppe für Access ist weniger der Datenbankexperte als der PC-Poweruser.

Für eine Datenbank mit Adressen und noch ein paar Daten würde ich das Einbinden nehmen.

database

Hallo,

ZitatDamit scheidet sowohl der SQL Server als auch andere Datenbanken aus.

http://msdn.microsoft.com/de-AT/library/11e570ze.aspx

ebs17

ZitatDAO geht nur mit einer Accessdatenbank ...
Nö. DAO funktioniert auch ohne Accessinstallation und ohne Accessdatenbank. Es ist wie ADO eine Komponente von Windows, also i.d.R. vorhanden oder nachladbar.
Allerdings ist DAO optimiert auf Jet-Datenbanken und daher dort die vordere Wahl.

ZitatDie Zielgruppe für Access ist weniger der Datenbankexperte als der PC-Poweruser.
Eine solche Pauschalisierung ist dann nur rein falsch. Es gibt dazu auch ein AEK-Script zu diesem Thema.

- Der Datenbankexperte wird durchaus eine Entwicklungsumgebung schätzen, mit der er sehr schnell ein Frontend erstellen kann (das wird er kaum Usern überlassen).
- Wenn ein aktives DBMS als Backend dient, wird der Datenbankexperte dieses auch vorrangig arbeiten lassen, statt es nur als Datencontainer zu verwenden (wie das bei Nur-Nutzung von Tabellen der Fall wäre).

MfGA
ebs
Mit freundlichem Glück Auf!

Eberhard

Wurliwurm

ZitatDAO funktioniert auch ohne Accessinstallation und ohne Accessdatenbank

Ich meinte, die Datenspeicherung in einer Accessdatenbank erfolgen muß. Wie im geposteten Link beschrieben, kann man mit DAO aber über die ODBC-Brücke auch auf andere Datenbanken zugreifen. Das es geht, heißt aber nicht, daß es gut geeignet ist (wegen dem Overhead).

Das AEK-Skript kenne ich. In dem steht aber auch, daß Access ein bißchen unglücklich positioniert ist. Ein Thema ist, daß es 2-Ebenen-Architektur ein großer Teil der Business-Logik im lokalen Client stattfindet und es suboptimal ist, hier immer die Clients bei Updates austauschen zu müssen. Das ist ein großer Nachteil.

Um jetzt nicht völlig in Grundsatzdiskussionen abzuschweifen, kann ich meine persönlichen Vorlieben beschreiben (wie jeder Mensch benutze ich vor allem das, was ich am meisten gewöhnt bin):

-Datenhaltung auf einem aktiven RDBMS, normalisiert und mit allen möglichen Constraints, Triggern etc. Die Frage ob Oracle oder MS SQL ist wie die Frage Mercedes oder BMW. Ich benutze zuhause das kostenlose Oracle XE.
-Zugriff vom lokalen Frontend per ADO. Dies ist superperformant, skaliert (keine Leistungseinbrüche beim Mehrbenutzerzugriff), sicher (man kann den Userzugriff genau steuern auf Tabellenebene) und stabil (Serialisierbarkeit). Selbst über WLAN kein merkbarer Performance-Unterschied im Vergleich zum Zugriff auf eine lokale Access-DB und es liegen Welten Unterschied zum Zugriff auf eine Access-DB über das Netz. Es können auch Oracle-Funktionalitäten benutzt werden wie GROUP BY CUBE, Materialized Views, PL/SQL-Funktionen u.v.m.
-Zwischenablage der Daten im lokalen Client. Zum Beispiel wenn für Reports Zwischenergebnisse gespeichert werden müssen und SQL allein nicht reicht.
-Zugriff auf die lokalen Daten immer über ganz primitives DAO (CurrentDB...).
Für mich hat es sich gelohnt, mich in ADO und Oracle einzuarbeiten.

Mit dem Einbinden von Tabellen habe ich mich nie beschäftigt. Das halte ich persönlich für nichts halbes und nichts ganzes. So wie viele keine Makros mögen.

Aber wie gesagt, für eine kleine Addressdatenbank ist das wahrscheinlich alles völlig überdimensioniert und daher irrelevant.

Grüße
Johannes