Diskussion:Microsoft Access/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Microsoft Access/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Microsoft_Access/Archiv/1#Thema_1

Mehrbenutzerzugriff

Hallo,

AFAIK hat Access insbesondere beim Mehrbenutzerzugriff Probleme. Da ist es besonders schade, dass es zu dem Thema keine weiterführende Informationen gibt (der Link ist rot).

--Badenserbub 08:25, 25. Feb 2005 (CET)

Neutralität

Ich habe den Baustein entfernt, weil hier nicht wie vorgeschrieben eine Begründung dazu steht. -- Simplicius ☺ 01:53, 20. Mai 2005 (CEST)

Unterscheidung

Hallo. Von der Seite "Synthesizer" gelangt man über einen Link auf diese Seite, der eigentlich zu einer Seite über den Hersteller von elektronischen Musikinstrumenten "Access" führen sollte. Da ich nicht weiß, wie man eine solche Auswahlseite einbaut, hier die bitte an die Community, eine solche zu erstellen. (nicht signierter Beitrag von 84.156.172.254 (Diskussion | Beiträge) 16:42, 13. Jun. 2005 (CEST))

Von wem stammt Access?

Unter Datenbank steht, daß Access von Microsoft gekauft wurde. Es wäre interessant zu lesen, wer das Programm ursprünglich entwickelt hat.

Würde mich auch interessieren, denn davon habe ich noch nichts gehört. Möglicherweise ist es eine Verwechslung, denn der SQL-Server wurde von Sybase gekauft und dann noch eine zeitlang gemeinsam entwickelt. Soweit ich weiß, ist auch FoxPro (enthält eine Datenbank) gekauft. Ralf Pfeifer 21:13, 10. Mai 2005 (CEST)

Ich erinnere mich ganz genau, dass Access von Microsoft gekauft und dann in der V1.0 auf den Markt gebracht wurde. Habe damals mit Open Access gearbeitet und mich immer gewundert, dass MS keine vernünftige Datenbank anbietet. Aber ich komme einfach nicht mehr auf den Namen der Vorgängersoftware von MS Access. [R. Klaus]

Wobei man auch noch aufpassen muss, 1983 wurde auch der Spielehersteller "Access Software" von Microsoft aufgekauft. Microsoft Access kam zum ersten Mal 1992 auf den Markt. -- Simplicius - ☺ 20:37, 22. Jun 2006 (CEST)

Das ist ein ziemliches Gerücht. Ich erinnere mich noch an den Codenamen als das Produkt noch gar nicht am Markt war: Cirrus. Da ich damals bei der Konkurrenz gearbeitet habe, die Paradox hergestellt hat, haben uns Nachrichten in der Richtung immer sehr interessiert. Und dann kam die Version 1.0 und die war nicht so toll - aber (wie immer) versprach man bald Besserung. Und die gab es dann wohl auch. Jedenfalls ist meines Wissens Access zu 100% bei Microsoft entwickelt.

Mehrbenutzerzugriff

Die Probleme beim Mehrbenutzerzugriff beruhen vor allem darauf, dass Access beim Zugriff auf Datensätze meines Wissens kein Satzlocking (ein einzelner Datensatz wird während der Bearbeitung vor dem Überschreiben geschützt!) sondern Pagelocking (die gesamte Speicherseite wird geblockt!) einsetzt. Dies kann bei größeren Datenbanken mit vielen Benutzern zu langen Wartezeiten führen.

--S.Möller 10:13, 30. Sep 2005 (CEST)

Das stimmt so nicht - zumindest ab A2000 wird in aller Regel satzweise gesperrt - auch hat Sperren eigentlich wenig mit Wartezeiten zu tun. Wenn bei pessimistischem Sperren zwei auf den gleichen Datensatz zugreifen, gibt es halt eine Fehlermeldung für den Zweiten - da wird nicht gewartet! --Reinhard 22:34, 13. Okt 2005 (CEST)

Bis Jet 3.x gab es nur seitenweises sperren. Seit Jet 4.0 ist satzweises sperren hinzugekommen. Das größte Problem dürfte sein, dass es einige Anwender gibt, die sich über sowas gar keine Gedanken machen. Einziges "echtes" (technisches) Problem ist, dass (aufgrund der dateibasiertheit) geänderte Werte erstmal in den Cache wandern, der sich lokal auf dem ändernden PC befindet. Bei Mehrbenutzer-Anwendungen muss nach jedem Daten wegschreiben explizit der Cache geleert werden. --Ifm 19:54, 27. Apr 2006 (CEST)

Hierzu muss der wichtige Hinweis ergänzt werden, dass das satzweise pessimistische Locking ausschließlich bei DAO-Zugriffen möglich ist. Bei dem Einsatz von Access-Projektdateien, die technisch auf ADO basieren, ist ausschließlich ein optimistisches Locking möglich. D.h. der Datensatz wird erst beim SCHREIBEN gesperrt und es kann zu einem Problem kommen, wenn ein Anwender den betr Datensatz zwischenzeitlich geändert hat. Technisch sei hierzu angemerkt: obwohl es sehr wohl für das Anfordern von ADODB.Recordsets einen Enumerationswert für das Setzen von perssimistischen Lockings gibt, so wird diese Vorgabe grundsätzlich IGNORIERT. Wer es nicht glaubt, soll es bitte ausprobieren!! :D Gruß, ctec76

Klingt etwas wie Werbung von MS

Wieso hat der Artikel einen faden Werbe-Beigeschmack? Ich vermisse da etwas die kritische Auseinandersetzung mit mit den Schwächen der Datenbank. -- ?

Das wird im Falle von Access etwas schwierig. Im Gegensatz zu den meisten anderen Produkten hat selbst die c't in ihren Tests wenig an Access auszusetzen. In Vergleichstests mit anderen PC-Datenbanken hat Access immer die besten Karten gehabt. Wenn man so viel Software wie M$ auf den Markt bringt, ist es schon aus statistischen Gründen nicht auszuschließen, dass auch mal ein wirklich gutes dabei ist. Ralf Pfeifer 11:21, 5. Mai 2005 (CEST)

vielleicht sollte mal einer reinschreiben, dass z. B. SQL-Abfragen per Hand eingegeben meistens nicht hinhauen? Beispiele sind u. a. LIMIT oder so... Oder dass die Oberfläche etwas umständlich ist, dass man sich schwer tut zu fremden Servern zu verbinden (MySQL) etc. --E7 17:08, 15. Feb 2006 (CET)

Das ist an den Haaren herbeigezogen. Korrekt formulierte SQL-Statements führen zu korrekten Ergebnissen. Auch die Anbindung von anderen Datenbanken oder anderen Servern ist, zumindest ab Access 2000 problemlos möglich. Matze (unregistered) 09:05, 21. Jan 2008 (CET)

Es ist mir wurscht was die ct schreibt. Die Personenkreise mit Erfahrung werden meine Aussage bestätigen: Wer Access als Datenbanksystem bezeichnet, kennt keine andere Datenbank außer Access. Access hat sehr wohl Schwächen, die für meine Begriffe indiskutabel sind. So reicht eine ungeschickte VBA-Programmierung aus eine DB komplett über den Jordan zu schicken - nein nicht die Daten, sondern dass sich das MDB-File nicht mehr öffnen läßt ohne dass eine Speicherverletzung auf tritt. Eine "DB", die als Menuepunkt "Reparieren" anbietet, beweist damit, dass sie ein grundsätzliches Problem hat.

Access hat mir schon oift geholfen und auch ich verwende Access - aber nicht als Datenbank. im klassischen Sinne.80.187.107.70 11:45, 7. Apr. 2010 (CEST)

Abgrenzung

Access ist auch der Name von Access Music. Wie kommt der Suchende dort hin? (nicht signierter Beitrag von 217.95.245.6 (Diskussion | Beiträge) 22:41, 1. Mai 2006 (CEST))

Unglücklicher Artikel

Irgendwie kommt mir der artikel so vor, als ob Access eine Datenbank ist.

Es soll klar sein im Artikel, dass Access nicht mehr als eine Tabellenverwaltung und ein GUI-Client für datenbanken ist. Richtige DBs sind Oracle, Postgres, SQL Server, DB2... (nicht signierter Beitrag von Michael-O (Diskussion | Beiträge) 00:32, 28. Jul. 2006 (CEST))

Access ist eine Datenbank. Sie ist halt dateibasiert. Du verwechselst, wie wie viele andere auch, Datenbank mit Datenbanksystem. Der Artikel ist aber wirklich etwas inkorrekt, da es laut Text ein Datenbanksystem sein soll. Siehe dazu auch den Artikel Datenbank. (Es fehlt aber auch nicht viel an einem DBS, so dass die Diskusion um diesen Unterschied eher akademischer Natur ist) --Ifm 23:25, 2. Aug 2006 (CEST)

Inhaltsverzeichnis?!

Wie wärs mal mit nem Inhaltsverzeichniss / bessere Gliederung? Hab leider grad keine Zeit.. (nicht signierter Beitrag von Micronax (Diskussion | Beiträge) 20:06, 21. Feb. 2007 (CET))

Office 2007

Hat es einen Grund, dass Access 2007 in der Liste nicht mit aufgeführt wird? (nicht signierter Beitrag von Maxliebscher (Diskussion | Beiträge) 15:58, 1. Mär. 2007 (CET))

Letzter Absatz

Der letzte Absatz ist totales Fanboy Gequatsche, angebliche Benutzer die zwischen Programmen hin- und herwechseln... ja, das ist ja auch so gut begründbar. Wenn keine Statistiken/Umfragen oder Dergleichen existieren, brauchen wir das echt nicht. 80.120.102.42 14:52, 20. Aug. 2007 (CEST)

Da hast Du recht, ich habe die Filemaker-Lobdudelei entfernt. Kexi gleich mit, da es erstens nicht auf Windows-Systemen läuft und zweitens keine eigene Datenbankengine mitbringt. Bei Aqua Data Studio wollte ich nicht so streng sein, da es wenigstens auch auf Win-System läuft. -- Hgulf Diskussion 15:20, 20. Aug. 2007 (CEST)

quantifizierung vonnöten!

...es wäre nicht schlecht, endlich mal zahlen zu nennen: inwiefern ist MSAccess für 'kleinere' bzw. SQLServer für 'größere' anwendungen zu empfehlen?... sprich: obergrenze für die anzahl der datensätze innerhalb einer tabelle, zugriffszeiten, rollback-verhalten usw.usf. --80.136.113.78 16:17, 31. Dez. 2007 (CET)

Access 2.0 hat eine maximale Dateigröße von 1 GB. Access 2003 kann entweder 2 oder 4 GB unterbringen - letzteres weiß ich aber nicht genau, hatten noch nicht mit so großen Datenbanken zu tun. Bei den anderen Versionen weiß ich es nicht. --217.5.224.133 08:52, 8. Jul. 2008 (CEST)

Die Frage ist, was Du genau mit "kleinere" bzw. "größere" Anwendungen meinst. Ich kann ein Beispiel aus der Praxis nennen, da ich Anwendungsentwickler für ERP-Software bin und in diesem Zusammenhang LEIDER dazu GEZWUNGEN bin, mit Access zu arbeiten.

Konkret "darf" (muss) ich tagtäglich das Standardprodukt "Sage Office Line" des ERP-Herstellers Sage Deutschland (siehe www.sage.de) anpassen und für Kundenzwecke umstricken. Hierbei handelt es sich um eine sehr umfangreiche ERP-Software (ich würde sagen für 5-150 Anwender möglich), die als Backend den SQL-Server und als Frontend eben Access über ADP-Projektdateien einsetzt (bis auf einige Geschäftsprozesse, die in COM-DLL´s und - in der neusten Office Line-Version - in .net ausgelagert sind).

Zunächst sei das folgende bemerkenswerte Erlebnis geschildert: Ich kann mich noch sehr gut an den Bericht eines Programmierers von Sage erinnern, der berichtet hat, wie Mitarbeiter von Sage wegen eines akuten Access-Problems in die USA nach Microsoft geflogen sind, um direkt mit Access-Entwicklern von Microsoft zu sprechen. Anders ließen sich die Probleme wohl nicht eingrenzen. Als die Access-Entwickler von MS die Office Line gesehen haben, sind deren Augen wohl immer größer geworden. Nach dem Motto: "wir hätten nie gedacht, dass jemand so viele Objekte in EINEM Access-Container verwaltet ohne dass Access permanent den Geist aufgibt" :-)).

Verlässliche Zahlen gibt es wohl nicht, aber soweit wir wissen, ist die Sage Office Line DAS umfangreichste Access-Projekt überhaupt, wenn man die Objekte und den Quellcode mitrechnet. Alleine die Applikationsdatei der Warenwirtschaft (=Auftragsbearbeitung und Faktura) hat OHNE Datenanbindung und ohne Zusatzmodule (AddIns etc) und DLL-Dateien bereits eine Größe von ~50 MB (Office Line 4.0).

Nun zu meinen konkreten Erfahrungen: der Overhead von Access (ich rede zunächst "nur" vom Frontend!) ist gewaltig. Soll heißen: es ist extrem langsam und es wird einem an vielen Stellen das Leben zur Hölle gemacht. Ich will erst gar nicht davon reden, dass man in compilierten Access-Containern bis heute NICHT in der Lage ist, per Laufzeit komplett NEUE Objekte zu erzeugen, wie z.B. ein NEUES Label auf einem Form etc.

Am übelsten sind die vielen, teilweise völlig unerklärlichen Programmabstürze, insbesondere bei direkt gebundenen Unterformularen mit bestimmten Controls. Also z.B. Fenstern (Forms), die wiederum Unterfenster enthalten, die auch direkt an ein ADO-Objekt, z.B. eine Sicht oder Tabelle gebunden sind. Hat man hier z.B. eine gebundene Checkbox und verändert den Inhalt, dann kann es passieren, dass sich Access OHNE vernünftige Meldung einfach so verabschiedet.

Ein weiteres großes Problem in der Praxis bei Kundenprojekten ist die Druckerunterstützung bzw. das gesamte Thema "Drucken". Hier geht Access teilweise extreme Eigenwege (z.B. keine vernünftige Schachtansteuerung usw).

Krasses Beispiel: um ein Objekt per Quellcode auszudrucken, muss man den Application.DoCmd.PrintOut-Befehl verwenden, der es (bis einschl Access 2007) NICHT gestattet, das zu druckende Objekt explizit namentlich zu benennen. Dies ist der Alptraum eines jeden Entwicklers, da es in diesem Fall von der Fokusierung der Windows-Objekte abhängt, welches Objekt gerade gedruckt wird (also das Objekt, welches gerade den Fokus besitzt). Hierbei kommt Access in umfangreichen Projekten, insbesondere wenn mehrere Objekte geöffnet sind und ggf auch noch sogenannte Zusatzmodule geöffnet sind, extrem ins Schwitzen. Mit Zusatzmodulen sind übrigens weitere Access-Dateien/AddIns gemeint, die aus einer Projektdatei heraus geladen werden können, um darin Code auszulagern und dadurch die Haupt-Projektdatei kleiner zu halten.

Beispiel aus einem aktuellen Kundenfall: Kunde hat von uns eine Programmierung zum Drucken von Etiketten erhalten. Zunächst wird aus der Projektdatei (ADP-Datei) unser AddIn geladen, in dem der eigentliche Code und der Bericht enthalten sind (die ADP-Datei versuchen wir möglichst NIE zu ändern - versucht mal in einem 50 MB-Container vernünftig zu arbeiten ;-)).

Der Bericht erscheint auf dem Bildschirm. Kunde klickt einen Button [Drucken] in einer Symbolleiste an (die in der ADP-Projektdatei enthalten sein muss und NICHT in unserem AddIn ist), um den Bericht zu drucken.

Application.DoCmd.PrintOut wird ausgelöst und - warum auch immer - es wird NICHT unser Bericht gedruckt, sondern ein Screenshot vom Regiezentrum (Hauptmenü) der Office Line. Einfach nur der Hammer! Wir haben versucht, das Ganze durch einen manuellen Fokuswechsel auf den Bericht (per Windows-API) zu lösen (schließlich hat man ja auch mal "richtige" Windoof-Programmierung gelernt ;-)). Mit dem Ergebnis, dass Access danach völlig am Rad dreht und es wieder zu unerklärlichen Abstürzen kommt ;-)

Ich könnte stundenlang weitere Erlebnisse aus dem Hut zaubern. Ich erspare es euch, weise aber noch darauf hin, dass wir ohne /Decompile-Schalter überhaupt nicht leben können (die Experten wissen, was mit dieser Option gemeint isT).

Hier mein persönliches Fazit, basierend auf fast 10 Jahren Erfahrung mit Access: Access ist als Frontend für größere, komplexe Anwendungen NICHT zu gebrauchen. Insbesondere dann nicht, wenn auch AddIns und/oder COM-Technik ins Spiel kommt.

Für kleinere Projekte (Mini-Projekte) oder schnell zu strickende Auswertungen, simple Datenerfassungen etc, ist Access ein hervorragendes Tool und IMO allemal gegenüber Programmen wie FileMaker & Co zu bevorzugen - alleine schon aufgrund der sehr guten MS-Office-Integration von Access.

Gruß, ctec76

Das mit deim Problem mit PrintOut kann ich nur ansatzweise verstehen. Folgendes müsste eigentlich funktionieren:

• sCurFormName = Screen.ActiveForm.Name
• DoCmd.OpenReport "foo", [...] ' bei schon geoeffneten Objekten: DoCmd.SelectObject [...]
• DoCmd.PrintOut acPrintAll, , , acHigh, 2, True
• DoCmd.SelectObject acForm, sCurFomName

Das aber auch nur, wenn das gedruckte Objekt geöffnet bleiben soll. Ansonsten wird beim schließen das vorher aktive Objekt wieder aktiviert. So verhällt sich eigentlich jede Programmiersprache.

Für so große Projekte wie Sage OfficeLine eignet sich Access aber sicher nicht. Ich hatte mich schon immer gewundert, warum da nicht schon längst mal migriert wurde. Aber das scheint jetzt ja durch .net Stück für Stück zu passieren. Jedenfalls kann Access nichts dafür, wenn der Enscheider auf ein für sein Vorhaben nicht geeignetes Tool zurückgreift.

Insgesamt löst Access - wie alle RAD-Tools - aber nicht ihr "Versprechen" ein. Das ist auch so absolut nicht möglich. Eigentlich erwartet man als Programmierer die Angabe des Objekts bei PrintOut(), weil es halt bei allen anderen Funktionen ebenso ist (verstößt gegen das Prinzip der geringsten Überraschung). Andererseits bis Du ja Programmierer. Da fände ich es sogar sinnvoller wenn es immer nach o.g. Schema gehen würde.

Absolute Zahlen kann es jedenfalls nicht geben. Das hängt zu sehr von den Rahmendaten des Projekts ab. --Ifm 16:02, 13. Okt. 2008 (CEST)

DoCmd.SelectObject() funktionierte nicht und sollte eigentlich auch dasselbe tun wie der SetFocus-API-Befehl.

Natürlich sollte man native Access-Befehle gegenüber API-Calls bevorzugen (sofern diese verfügbar sind).

Aber wie geschrieben: kein Ansatz brachte in diesem Fall eine sinnvolle Lösung.

Die meisten Probleme enstehen innerhalb von Access definitiv bei großen ADP-Dateien UND mit geladenen AddIns, das Ganze dann eben noch in Kombination mit COM-DLL-Dateien (das Debuggen alleine kann eine Katastrophe sein). Sowohl die Erfahrungen in unserem Unternehmen als auch die Erfahrungen anderer Unternehmen, die ebenfalls mit Access arbeiten, bestätigen dies - was ich in vielen persönlichen Gesprächen mit anderen Händlern erfahren habe.

Aber sicherlich hat nicht jedes Projekt derartige Dimensionen wie die Sage Office Line ;)

Fairerweise muss man auch anmerken, dass die Office Line ein Produkt ist, welches in diesem Umfang nie von Sage (früher "KHK") geplant gewesen ist. Das Produkt ist über die Jahre einfach immer mehr gewachsen.

Mittendrin "mal eben" eine Migration durchzuführen, ist bei einem derart umfangreichen Projekt schlicht unmöglich.

Mit der Office Line Evolution (5.x) geht Sage den richtigen Weg, da man dort begonnen hat, die wesentlichen Geschäftsprozesse (COM-DLL-Dateien) in .net assemblies auszulagern.

Hierdurch entsteht jedoch ein gewisser Overhead, da alle .net Aufrufe nun mal eine Interoperabilitätsschicht durchlaufen müssen (Access kann NICHT nativ mit .net assemblies umgehen). Es gibt auch einige technische Hürden zu meistern (Transaktionsmanagement z.B.) Die allgemeinen Performance-Einbußen sind entsprechend spürbar, abgesehen davon, dass Access 2007 gegenüber Access 2003 ebenfalls einen zusätzlichen Overhead mitbringt - manche behaupten, das sei bei jedem Office-Versionssprung der Fall :D

Whatsoever: Access generell "zu verteufeln", war NICHT meine Absicht! Access kann verdammt viel, das muss man neidlos anerkennen.

Die Kunst ist es in meinen Augen, das für Access "zumutbare" Projektvolumen einschätzen zu können und dementsprechend die sinnvolle Verwendung zu planen!

Gruß, ctec76

Access im Zusammenspiel mit COM und/oder .net

Macht es Sinn, hierzu ein paar Details aufzuführen? Weiß jemand, wie lange es noch VBA für Access geben wird und ob irgendwann z.B. eine native Unterstützung für .net geplant ist? (nicht signierter Beitrag von 87.79.68.91 (Diskussion | Beiträge) 22:39, 13. Aug. 2008 (CEST))

Ich weiss leider ebenfalls nichts nichts von konkreten Plänen Microsofts - doch kann es nach meiner Erfahrung durchaus sinnvoll sein, Erweiterungen bestehender Projekte in .net zu implementieren, und diese dann als .dll oder .tlb in Access einzubinden. Grundsätzlich ist auf diese Art auch sukzessive die ganze BI auslagerbar. Ausser durch einen spürbaren Zeitverlust von etwa 1 Sekunde beim ersten Binding der .dll (über ein Netzwerk) ist die Performance nicht zu beanstanden.

-- Nocebo 20:39, 6. Apr. 2009 (CEST)

Keine ADO-Projektdateien (*.adp-Dateien) ab Access 2007 mehr möglich

Vielleicht sollte noch darauf hingewiesen werden, dass ab Access 2007 mit nativen Access 2007-Dateien (Dateiendung *.accdb) die sogenannten Projektdateien NICHT mehr möglich sind (im Artikel gibt es bereits einen Verweis auf die Projektdateien).

D.h. es ist mit Access 2007 NICHT mehr möglich, via ADO-Technologie Datenbankobjekte wie Tabellen oder Sichten direkt einzubinden! Das Einbinden von externen Objekten <> Access ist in Access 2007 meines Wissens nur über ODBC möglich (Rückschritt!?). Alternativ muss man eine Access 2003-Datei als Container verwenden, in denen die ADO-Projektfunktionalität weiterhin genutzt werden kann. (nicht signierter Beitrag von 87.79.68.91 (Diskussion | Beiträge) 22:39, 13. Aug. 2008 (CEST))

Access implementiert SQL-92?

Hallo,

Access unterstützt den SQL-92 Standard, dadurch, dass es auf die Jet-Engine (DAO) aufsetzt, nur teilweise, d.h. es ist noch nicht vollständig ANSI(SQL)92-kompatibel.
Das müsste dringend mit in den Artikel finde ich.
Sonst suchen die Leute spätestens bei Update-Anweisungen mit Join - Syntax bis zum jüngsten Tag...
...wie ich soeben, die ist nämlich ein Beispiel für die Nicht-Konformität von Access mit SQL-92.

Gruß Thor

Das kann ich aus eigener Erfahrung nur bestätigen! Access ist auf keinen Fall 100% ANSI-kompatibel. Es gibt zahlreiche Besonderheiten zu beachten, die einem so manchmal den letzten Nerv kosten ;-) Ein simples, aber frustrierendes Beispiel ist die Delete-Anweisung, die in Access IMMER mit "delete * from ...." angegeben werden muss! Gruß, ctec76

Die Jet-Engine kann sowohl DELETE FROM Tabelle wie auch DELETE * FROM Tabelle. Das mit dem "Update und Join" verstehe ich nicht. Die Jet kann - soweit eindeutig - ein Update in Kombination mit einem Join, nach SQL-92 ist das meines wissens gar nicht möglich. Aber ein "mehr" ist ja ok. Der Standard wird dann trotzdem eingehalten wenn nicht explizit definiert ist, dass es nicht ok ist. --Ifm 15:16, 13. Okt. 2008 (CEST)

Access kann in der Tat nicht 100% SQL-92 - gestern erst gesehen (und hat zu massiven Frustrationen geführt): Mehrere INNER JOINS bei SELECT geht gar nicht, bzw. nur in der veralterten Syntax: statt SELECT <irgendwas> FROM <tabelle> A INNER JOIN <tabelle> B ON <bedingung> INNER JOIN <tabelle C> ON <Bedingung> geht nur SELECT <irgendwas> FROM <tabelle> A, <tabelle> B, <tabelle C> WHERE (<Bedingung>) AND (<Bedingung>) usw. Ist zum Wahnsinnigwerden wenn man das nicht weiß und Access beim zweiten INNER JOIN eine sehr merkwürdige Fehlermeldung ausgibt. Achja, solche Sachen wie CROSS JOIN kann Access auch nicht (bzw. wieder in der alten Notation). SQL-92 konform ist das nicht. --Mark Nowiasz 11:34, 18. Okt. 2008 (CEST)

Mehrere INNER JOINS können nur begleitet von Klammern, also beispielsweise ((A INNER JOIN B ON A.X = B.X) INNER JOIN C ON C.Y = A.Y ) INNER JOIN D ON D.Z = B.Z kaskadiert werden. -- Nocebo 20:49, 6. Apr. 2009 (CEST)

Eigenschaften

Zur Zeit dort zu finden (unterer Abschnitt) "Gleichzeitig fehlt eine textbasierte Umgebung zum Erstellen von SQL-Code, die die Funktionen eines einfachen Texteditors bietet". Vielleicht übersehe ich ja den eigentlichen Inhalt des Satzes, aber mit einem Rechtsklick auf den Designer kann man auf SQL View umschalten - was nichts anderes ist als ein "einfacher Texteditor zum Erstellen von SQL-Code". Halte also den oben zitierten Satz für falsch. Löschen oder Verständlich schreiben ist meiner Meinung nach angebracht. --DanielRenkel (nicht signierter Beitrag von 213.157.29.8 (Diskussion | Beiträge) 11:05, 30. Jan. 2009 (CET))

Da gebe ich Dir recht. Der ganze Absatz entsprach auch nicht WP:NPOV. Ich habe ihn daher entfernt. --Geri, ✉ 13:44, 1. Jan. 2010 (CET)

ACCESS ist kein ernst zu nehmendes DBMS

auch wenn so eine nichtswissende Blockwartseele meint mein Beitrag wäre meine persönliche Meinung widerspreche ich dem nachdrücklich. Unten genanntes ist eine anerkannte Regel der Technik, die in diesem Fachbereich wohlbekannt ist und von entsprechenden Fachleuten auch weithin propagiert wird. Wer sich auf ernst zu nehmende Entwicklungsarbeit einläßt sollte das schon berücksichtigen.

- Ich habe vor 25 Jahren angefangen mich mit Datenbanken zu befassen damals noch mit dBase unter (SCO) UNIX und kenne die Entwicklung seit dieser Zeit recht gut weil ich mich heute immer noch damit befasse (hauptberuflich). - ACCESS ist kein ernst zu nehmendes DBMS im Vergleich mit den Schwergewichten der Branche (DB2, ORACLE, SQL Server usw.). Ich meine damit ausschließlich die Datenbankfunktionalität also das Back End. ACCESS als Datenbank ist brauchbar für kleine Datenbanken mit einem zu vernachlässigendem Sicherheitsanspruch und einer ebenso unwichtigen Verfügbarkeit. Folgende Fakten machen ACCESS als Datenbank für einen professionellen Einsatz unbrauchbar: keine SP, keine Trigger, Constraintdefinition katastrophal, Größenbeschränkung DB, keine ernst zu nehmende Replikation möglich, Mehrbenutzerumgebung katastrophal oder gar unmöglich, Stabilität katastrophal, Backup und Restore katastrophal,und und und....... - ACCESS habe ich wirklich schätzen gelernt als Entwicklungsumgebung für diverse Applikationen. Es geht vieles schneller als z.B. mit Visual Studio oder Delphi. Als Datenbank dahinter habe ich aber immer MS SQL Server oder ORACLE bevorzugt. Man muß den vergegenständlichten Wert sehen, der sich über die Jahre in einer Datenbank ansammelt. Würde ich das als *.MDB Datei auf eine PC Platte oder ein Net Share legen ???????? Ich wäre doch lebensmüde--88.74.191.99 12:37, 6. Mär. 2009 (CET)

Da kann ich nur zustimmen. Ich habe 25 Jahre lang Fortbildungen für Datenbankprogrammierer veranstaltet, die größten Probleme gab es in Firmen mit Access als Frontend. -- Hooblei 07:55, 30. Okt. 2011 (CET)

Projektname Omnibase

Ich würde gerne wissen woher dieser Name kommt. Ich bin mir nämlich sehr sicher, dass der Omega lautete. --Geri, ✉ 13:53, 1. Jan. 2010 (CET)

Ha! Wusst ich's doch! --Geri, ✉ 14:00, 1. Jan. 2010 (CET)

Dateiformate

Es fehlt ein Abschnitt über die Dateiformate mit den entsprechenden Dateiendungen (analog dem entsprechenden Abschnitt in http://de.wikipedia.org/wiki/Microsoft_Excel). UW, 15.07.201. (nicht signierter Beitrag von 212.202.110.199 (Diskussion) 14:56, 15. Jul 2011 (CEST))

Neutralität?

Der gesamte Artikel erscheint mir nciht neutral, sondern eher als eine Art Werbetext für das Programm. Formulierungen wie "Es ist sehr einfach" passen meiner Ansicht nach nicht zum Charakter dieser Enzyklopädie. Da es aber immer sein kann, dass die eigene Ansicht auch mal daneben liegen kann, habe ich den Text nicht einfach geändert, sonder wollte erstmal ein paar Meinungen dazu hören. --SimonHH 00:40, 27. Okt. 2011 (CEST)

es ist schon so, das im ACCESS vieles recht einfach umsetzbar ist, weil es für alles mögliche Assistenten gibt. Ich meine damit vor allem die Aplikationsseite. Im .NET oder Delphi muß da schon ganz anders gecodet werden um gleiche Ergebnisse zu erzielen. Der wirklich gravierende Nachteil bei ACCESS ist, das auf dem PC auf dem die Applikation dann laufen soll auch ACCESS installiert sein sollte um alle Funktionalitäten zu nutzen. Das kann ganz schnell mächtig ins Geld gehen. Dieser Mist mit der sogenannten Laufzeitumgebung ist eine ziemliche Totgeburt. Damit kann man eigentlich nicht arbeiten weil ein Großteil der ACCESS typischen Funktionalität fehlt bzw. nicht unterstützt wird. Ich bin eingefleischter ACCESS Entwickler aber mittlerweile ziehe ich .NET als Entwicklungsumgebung eindeutig vor. Diese compilierten Programme laufen auf allen WINDOWS Maschinen ohne jeden Zusatz. --145.253.160.50 13:06, 4. Mai 2012 (CEST)

Und schon sind wir im Schlamassel: Ich bin Ex-Access-Entwickler (;-)) und habe bisher jede Anwendung in der Runtime zum laufen gebracht. Das ist aber eh egal, weil eigene Erfahrung. Zum Beitrag von SimonHH: Die Einfachheit ist ein Grundfeature von Access, sonst könnte man gleich MS SQL Server nehmen; dies aber ohne Microsoft zu bequellen wird nicht einfach sein. -- Hgulf Diskussion 13:28, 4. Mai 2012 (CEST)

Vorsicht hier muß zwischen Database und Applikation unterschieden werden. ACCESS als Datenbank ist vollkommen wert- und sinnlos. Hier würde ich NUR einen SQL Server oder ORACLE bevorzugen. Als Applikationsumgebung ist ACCESS allerdings eine Überlegung wert. Dabei muß man aber auch einen gewissen Kampf mit den Versionen und den dazugehörigen Laufzeitversionen einkalkulieren. --145.253.160.50 12:34, 16. Mai 2012 (CEST)

Access wird ziemlich häufig als Datenbank (Backend) eingesetzt (es ist dann allerdings nicht mehr Access sondern Jet ... Access ist nur die Oberfläche). Alleine schon, weil es bei allen Mircosoft-Sprache dabei ist, ist das so. Es mach aber auch oft sehr viel Sinn. Warum sollte man denn dem Endbenutzer einen Datenbankserver mit all den administrativen Tätigkeiten aufs Auge drücken, wenn vom Daten -und Nutzeraufkommen her eine Desktop-Datenbank reicht? Innerhalb der Gruppe der Desktop-Datenbanken hat Jet einen weiteren Vorteil gegenüber vielen anderen Produkten. Es besteht aus nur einer Datei. Im Endeffekt steht das auch schon so im Artikel: "MS Access, das auf der Microsoft Jet Engine als Datenbank-Backend basiert, eignet sich gut für kleinere bis mittlere Datenbanken mit (etwa) bis zu zehn konkurrierenden Benutzern." --Ifm (Diskussion) 13:51, 8. Nov. 2012 (CET)

Und inwiefern geht's bei den Beiträgen ab dem zweiten um die Verbesserung des Artikels? Threads kapern ist unfein. --Geri, ✉ 03:10, 15. Nov. 2012 (CET)

Insofern, dass nichts falsches bzw. strittiges in den Artikel gelangt. --Ifm (Diskussion) 09:15, 17. Nov. 2012 (CET)

Du sagst es: „Im Endeffekt steht das auch schon so im Artikel“.

Und die Einleitung oben sagt: Persönliche Betrachtungen zum Artikelthema gehören nicht hierher. --Geri, ✉ 08:20, 18. Nov. 2012 (CET)

Dieser Abschnitt kann archiviert werden. --Geri, ✉ 08:20, 18. Nov. 2012 (CET)

Weitere SQL-Server?

Ich bin selbst Datenbankentwickler (O...) und kann mit Zitat "die Migration zu anderen SQL-Servern ist ebenfalls vergleichsweise unkompliziert" nichts anfangen. Was sollen denn andere SQL-Server sein?

--Leuchuk (Diskussion) 09:53, 8. Nov. 2012 (CET)

Da hast Du recht. Habe diesen seltsamen Satz entfernt. -- Hgulf Diskussion 12:11, 8. Nov. 2012 (CET)

Access = IDE?

Hallo, ich hab mal eine Frage: Ist eigentlich MS Access eine IDE? Die bei IDE beschriebenen Kriterien werden ja von Access soweit ich weiß erfüllt.

• Wenn ja, sollte man Access in der Liste von Integrierten Entwicklungsumgebungen ergänzen.
• Wenn nein: Warum nicht?

Danke schon mal, ich bin gespannt auf Antworten.--93.204.111.179 19:02, 7. Aug. 2013 (CEST)

Access wird in zahlreichen Google-Treffern, z.B. Kursankündigungen und Büchern, vor allem mit VBA zusammen als 'integrierte Entwicklungsumgebung' bezeichnet. Da auch der im Artikel 'IDE' aufgeführte Werkzeug-Set gegeben ist, sollte dieses Produkt auch eine 'IDE' sein, nicht nur im Sprachgebrauch, z.B. von Microsoft, so bezeichnet werden. Die o.g. Liste sollte also ergänzt werden.--VÖRBY (Diskussion) 16:20, 10. Aug. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: VÖRBY (Diskussion) 09:46, 20. Mär. 2014 (CET)

Irreführender Artikel

Solche Artikel, wie dieser hier in Wikipedia, sind der Grund warum Leute denken, dass Access eine gute Lösung ist. Alleine schon die Einleitung: "...ist ein proprietäres Datenbankmanagementsystem des...". Das ist absoluter Quatsch. Access ist maximal eine Tabellenverwaltung mit GUI-Elementen. Mit einem DBMS hat es absolut nichts gemein. -- Michael-O (Diskussion) 12:46, 15. Sep. 2013 (CEST)

Hast Du dafür Belege? -- Hgulf Diskussion 17:03, 15. Sep. 2013 (CEST)

Es ist bekannt, dass viele sog. 'gestandene Programmierer' von Access wenig bis nichts halten. Nichtsdestotrotz ist das ein mächtiges und nützliches Instrument. Und deutlich mehr als was du schreibst. Und mit einem (für geeignete Zwecke) vernünftigen DBMS. Was soll an der zitierten Aussage falsch sein? Du scheust dich sogar, das Wort 'Microsoft' in den 'Mund zu nehmen', was deine Einstellung zu bestätigen scheint. --VÖRBY (Diskussion) 20:25, 15. Sep. 2013 (CEST)

Vorschlag: Text an den englischen Artikel anlehnen. Allerdings wird das Werkzeug auch dort als 'Database management system' (mit Link auf DBMS) bezeichnet. Ist es auch, aber nur teilweise, nämlich die Jet Engine betreffend. Korrekterweise sollte man es "System zur Entwicklung von Datenbankanwendungen" nennen. --VÖRBY (Diskussion) 18:35, 16. Sep. 2013 (CEST)

Access nicht als Datenbank zu bezeichnen zeugt von der selben Arroganz wie einen VW Lupo nicht als Auto zu bezeichnen. Access ist eine Datenbank, die sich zwar nicht mit Oracle und Co messen kann, jedoch diesen Anspruch auch gar nicht erhebt. Ich für meinen Teil bin in der Oracle-Welt zuhause und sehe die Einsatzmöglichkeiten für MS Access auch eher begrenzt. Dennoch gibt es Einsatzbereiche, in denen die Verwendung eines solchen Systems eine durchaus sinnvolle Lösung ist. Klar, zum Selbstzweck und als Spielerei kann man auch einen Oracle-Cluster für die Vereinsverwaltung aufsetzen, man kann es aber auch bleiben lassen. Und wenn mir Leute erzählen, das Access eine "Tabellenverwaltung" sei, dann sagt mir das nur, dass diese Personen a) Access nicht wirklich kennen und b) sich die Frage stellt, ob sie selbst wissen, wie sich eine Datenbank respektive ein Datenbanksystem definiert. 79.212.183.252 01:18, 20. Mär. 2014 (CET)

Ich habe die wesentlichen Aussagen aus der en:WP übernommen und den Aspekt 'Endbenutzer' in die Einleitung aufgenommen (mit Beleg). Dass die Jet Engine ein (R)DMBS ist, sollte Konsens sein, "absolut nichts gemein" ist schlicht falsch. --VÖRBY (Diskussion) 19:42, 17. Sep. 2013 (CEST)

Eine ähnliche Diskussion wurde auch in meiner Benutzerdiskussionsseite geführt: Ob Access überhaupt als Datenbank gesehen werden kann. Siehe dort. Fazit dort: Access als Gesamtsystem ist (für den Benutzer) AUCH ein DBMS; dass dazu die JetEngine als Komponente zum Einsatz kommt, ist lediglich ein Implementierungsaspekt.--VÖRBY (Diskussion) 08:44, 2. Okt. 2013 (CEST)

Oma-Test

Liebe Artikelschreiber, den Oma-Test besteht dieser Artikel leider nicht. Bin selbst auch noch keine Oma, habe aber nach dem Lesen der Einleitung trotzdem immer noch keine Idee, wozu ich als Käufer einer Microsoft Suite Access brauchen könnte. Kann man da nicht irgendwie eine allgemeinverständliche Erklärung einbauen? --Franczeska (Diskussion) 05:20, 19. Jan. 2014 (CET)

Guten Morgen liebe Oma ;-) Ich habe die Artikeleinleitung um die Angabe 'zur Herstellung von Datenbankanwendungen' erweitert und denke, jetzt sollte die Einleitung verständlicher sein, ggf. mit Hilfe der angegebenen Links. Wem das auch nicht hilft, der muss sich nicht darüber grämen: Er versteht dann so wenig von der Materie, dass er den Artikel nicht verstehen muss. --VÖRBY (Diskussion) 10:25, 19. Jan. 2014 (CET)