Hallo Leute, Ich bin eigentlich aus der Excel-Ecke. Mich würde interessieren ob es ähnlich viele Möglichkeiten wie bei Excel mittels VBA gibt, auch bei Access Abläufe zu steuern. Kann man hier die serielle Schnittstelle direkt nutzen? Und nur noch so aus neugier: Benutzt eigentlich viel Access?
Dönald D. schrieb: > Na ob ihr viel Access benützt? Access ist recht um quick and dirty was zu probieren, aber für den produktiven Einsatz in einer Firma ist es bei weitem zu instabil. Nachdem wir regelmässig ganze Arbeitstage verloren haben, weil am nächsten Morgen Access meldete "Die Accessdatenbank kann nicht geöffnet werden. Dies liegt möglicherweise daran, dass sie beschädigt ist". Abgesehen davon, dass wir da nie draufgekommen wären, half auch nie was anderes als die Sicherung vom Tag vorher einzuspielen und die gestrige Arbeit komplett zu wiederholen. Im Lauf der Zeit wurden daher alle Verirrungen auf Accessbasis ersetzt, obwohl das unangenehm viel Kosten verursacht hat. Aber für solche Jugendsünden muss man irgendwann büssen. Gruss Reinhard
Reinhard Kern schrieb: > Im Lauf der Zeit wurden daher alle Verirrungen auf Accessbasis ersetzt, > obwohl das unangenehm viel Kosten verursacht hat. Aber für solche > Jugendsünden muss man irgendwann büssen. nehmt ihr dann andere Software oder ist das dann was Selberprogrammiertes?
Dönald D. schrieb: > nehmt ihr dann andere Software Na, als Datenbank halt irgendeinen SQL-Server, sei es der von MS oder irgendeinen anderen, gibt ja genug. Als Frontend irgendwas irgendwie selbstgestricktes, sei es ein Webformular, was in VB oder was auch gebautes dafür. So etwas hat den Vorteil, von vornherein mehrbenutzerfähig zu sein, und Datenbank und Oberfläche sauber zu trennen. Auch mit Excel kann man sich mit 'nem "richtigen" SQL-Server unterhalten; vermutlich kann man auch den Access-Kram dazu verwenden.
Früher, wirklich im Anfang von Access und Visual Basic, da funktionierte Access ganz gut. Schnittstellen konnte man auch ansprechen, war aber echt nicht so einfach. Geht heute sicher auch. Heute ist da ja alles und bei allen MS Office Produkten VBA. Auch die Syntax scheint sich stark gewandelt zu haben oder ich blicke da einfach nicht mehr durch. Hab das mal ne Weile gemacht, auch verkauft, aber heute wurde ich gleich ne richtige SQL Datenbank nehmen. Für Linux gibt es da einige freie und kostenlose Sachen, die auch hinter vielen Webseiten arbeiten. Aber um noch richtig was dazu zu sagen, dazu bin ich zu lange raus. Nur den Tipp: mach mit SQL, das lernst du schnell und dann kannst du im Grunde jede Datenbank programmieren.
mit Access ist es wie mit jedem Werkzeug: es muss zum Problem passen. Einen kleinen Nagel für ein Bild klopfst Du ja auch nicht mit dem Vorschlaghammer in die Wand. Eine unternehmenskritische, skalierbare High-Performance-Multiuser-Datenbank-Anwendung würde ich auch nicht zwingend mit Access erstellen wollen. Für kleinere Projekte ist es aber durchaus ok. Was die Stabilität angeht: ich sitze zur Zeit bei einem Kunden der Office 2007 einsetzt ... so oft wie dort ist mir Excel noch nie abgekackt. Access läuft dagegen mehr oder weniger stabil. Dennoch würde auch ich für die Datenspeicherung eher zu einem SQL-Server raten. Was die Programmierbarkeit angeht: VBA ist VBA. Der einzige Unterschied zwischen Excel und Access ist das jeweilige Objekt-Modell. Durch OLE-Automatisierung geht es aber zum Beispiel auch von Excel aus auf Access-Datenbank-Objekte zuzugreifen und umgekehrt. Deshalb: alles was ich in Excel programmieren kann, kann ich auch in Access programmieren. Was sinnvoller ist, hängt aber immer vom konkreten Anwendungsfall ab.
Digi Spark schrieb: > Deshalb: alles was > ich in Excel programmieren kann, kann ich auch in Access programmieren. > Was sinnvoller ist, hängt aber immer vom konkreten Anwendungsfall ab. Alles hängt immer von Einsatzzweck ab. Aber da, zumindest Access, auch SQL 'versteht', sollte er dann doch lieber mit SQL anfangen. Zumal das wirklich erstmal einfach zu erlernen ist.
Danke für die interessanten Einblicke! Ich sehe schon: SQL scheint das Maß aller Dinge zu sein.
das kann man so nun auch wieder nicht sagen. SQL steht für "Structured Query Language" also "Strukturierte Abfrage-Sprache" ... und genau das ist es auch: eine Sprache, mit der man Datenbank-Abfragen und -Manipulationen (wie Update, Insert, Delete oder Create Table) machen kann. Nicht mehr und nicht weniger. Du wirst per SQL z. B. nie mit der seriellen Schnittstelle kommunizieren oder eine Textdatei einlesen können. Auch wirst Du damit nie ein benutzerdefiniertes Formular oder einen Bericht in Access definieren können. Gleichwohl brauchst Du zumindest Grundkenntnisse in SQL, um an die Daten in Deiner Datenbank zu kommen. Wirklich mächtig wird SQL erst bei der Verwendung in sog. Stored Procedures, die direkt auf einem SQL-Server erstellt werden. Damit habe ich schon ganze Workflows komplett umgesetzt (z. B. ein Profit & Loss Reporting System eine großen deutschen Investment-Bank, das nahezu komplett auf Stored Procedures aufbaute und nur noch ein simples Frontend für die Anzeige der Daten verwendet hat). SQL als Maß aller Dinge zu sehen ist also auch nicht richtig. Auch hier gilt wieder: es ist ein Werkzeug, das zum Problem passen muss. Für manche Dinge ist sie geeignet - für andere nicht. Die Frage ist also immer zuerst: was willst Du machen? DANACH kann man dann entscheiden, mit welchem Werkzeug das am besten zu bewerkstelligen ist. Ich bin seit weit über 10 Jahren als Software-Entwickler vor allem im Bankenbereich tätig. Dabei erlebe ich zum Beispiel immer wieder, dass die verrücktesten Anwendungen mit Excel gebaut werden ... nur aus dem Grund weil viele BWL'ler im Studium halt mit Excel angefangen haben und nichts anderes vernünftig können habe ich den Eindruck (Entschuldigung an alle BWL'er ;-) ). Wenn sie statt dessen gelegentlich mal über den Tellerrand hinaus geblickt hätten, wäre in ggf. aufgefallen, dass es oft bessere Alternativen gegeben hätte.
Reinhard Kern schrieb: > Access ist recht um quick and dirty was zu probieren, aber für den > produktiven Einsatz in einer Firma ist es bei weitem zu instabil. > Nachdem wir regelmäßig ganze Arbeitstage verloren haben, weil am > nächsten Morgen Access meldete "Die Accessdatenbank kann nicht geöffnet > werden. Dies liegt möglicherweise daran, dass sie beschädigt ist". Da muss ich doch etwas widersprechen. Ich habe seit den 90ern mehrere Access-Datenbanken entwickelt, per DDE/ODBC mit Daten gespeist und erfolgreich installiert und sie wurden durch Kunden intensiv genutzt. 2 Davon sind sogar für Pharma/Medizintechnik validiert und zertifiziert. Diese laufen immer noch, wurden nur irgendwann mal hostseitig auf SQL-Basis umgestellt, weil der Server getauscht wurde. Man muss natürlich wissen, wie man dezentrale Datenbanken anlegt und betreibt - bei Access gibt es da ja 2 Möglichkeiten: Den Verbundbetrieb mit einer Art von Autoupdate und den Frontend-Backend-Betrieb. Seither hat sich bei Access viel getan und einige Limits (recordset-Beschränkung, Größe, ODBC-Kompatibilität) wurden behoben, womit Access noch einsatzfähiger ist. Ich benutze Access nach wie vor zur halbautomatischen Auswertung von Daten aus Industrieprozessen, indem ich Daten, die der PC gewinnt dort einspiele. Mit Access lassen sich am einfachsten komplexe Fragen stellen und Listen erzeugen - ohne umständliches SQL zu erlernen. Der größte Nachteil von Access ist halt nur die mangelnde Performance. Wer richtig Bandbreite braucht (mehr als 10 User) und/oder große Volumina (>100GB) fährt, muss mit proprietären Systemen Vorlieb nehmen, die auf Performance optimiert sind. Für Kleinbetriebe und -Anwendungen ist Access sehr effektiv. Der Grund, warum es heute nicht mehr sehr oft eingesetzt wird, ist einfach der, dass es für sehr viele Applikationen und Geschäftsvorfälle inzwischen Branchen. und Anwendungslösungen gibt, die das abdecken. Entscheidend ist, dass Firmen da auch Support und Pflege liefern und um sich abzugrenzen, setzen die logischerweise nicht auf eine universelles DB-System sondern programmieren selber einen optimierten Code. Mit Access kann man allerdings auch eigene Oberflächen verwenden, indem man einen Datenzugriffsseite generiert und das Webinterfaace nutzt - oder sich per SQL an das backend hängt. Ich habe das noch vor Jahren mit wxWidgets getan. Das wäre dann auch mal in Richtung Linux/mySQL portierbar. Wie gesagt, kommt es bei Access auch auf die richtige Konfiguration und Nutzung an und da spielt auch die HW-Struktur und die SW-Landschaft ein Rolle: Der Fehler, den Du z.B. beschrieben hast, liegt mit hoher Wahrscheinlichkeit an der Systemdatenbank, bzw der mangelnden Konfiguration derselben oder ihrer temporären Nichtverfügbarkeit infolge von internen Serverproblemen. Schließlich könnte ein Grund für die kaputte DB auch die mangelnde Datenorganisation sein. Wenn Schreibzugriffe per ODBC nicht korrekt abgeschlossen wurden, kommt es zu inkonsistenten Datenbeständen. Man spielt daher Datenänderungen in einen Zwischenbereich, prüft auf Konsistenz und übernimmt sie dann komplett. Zudem lässt man die Änderungen schlauerweise protokollieren, um einen Defekt manuell beheben und die Änderungen nachpflegen zu können. Solche Mechanismen muss man eben bei Access auch implementieren (in proprietären DBs sind die ebenfalls integriert, weil auch da Verbindungsausfälle von den Clients zum Server vorkommen).
Reinhard Kern schrieb: > Access ist recht um quick and dirty was zu probieren, aber für den > produktiven Einsatz in einer Firma ist es bei weitem zu instabil. > Nachdem wir regelmässig ganze Arbeitstage verloren haben, weil am > nächsten Morgen Access meldete "Die Accessdatenbank kann nicht geöffnet > werden. Dies liegt möglicherweise daran, dass sie beschädigt ist". Dann hab ihr was falsch gemacht. Die Datenbank kann nicht dafür! Jede Datenbank kann kaputt gehen, sei doch froh, daß ihr nur die *.mdb zurücksichern müssen. >Dabei erlebe ich zum Beispiel immer wieder, dass die >verrücktesten Anwendungen mit Excel gebaut werden ... nur aus dem Grund >weil viele BWL'ler im Studium halt mit Excel angefangen haben und nichts >anderes vernünftig können ... Das ist die Realität. >das kann man so nun auch wieder nicht sagen. SQL steht für "Structured >Query Language" also "Strukturierte Abfrage-Sprache" ... und genau das >ist es auch: eine Sprache, mit der man Datenbank-Abfragen und >-Manipulationen (wie Update, Insert, Delete oder Create Table) machen >kann. Nicht mehr und nicht weniger. Klarer kann man nicht formulieren.
Digi Spark schrieb: > Dabei erlebe ich zum Beispiel immer wieder, dass die > verrücktesten Anwendungen mit Excel gebaut werden Alles, was n-fach 2-dimensional ist, als eine Parameterspalte und eine oder mehrere Ausgangsspalten haben, ist in Excel am Besten aufgehoben. Man muss nur sehen, dass man maximal 256 Spalten hat und eine begrenzte Zahl von Datensätzen. Die aktuellen Excels kann man so mit Daten vollstopfen, dass 2GB große Files rauskommen. Umfangreiche Suchen oder Zusammenstellungen sind aber bereits ein Kriterium für den Zugriff durch Access. Zur Not kann man ja ein Excel auch mal temporär portieren. Ich habe das immer so gemacht, dass ich es einmalig konvertiere, eine Tabelle erzeuge, die exakt dem Excel entspricht und darauf basierend, dann meine Berichte und Abfragen erzeugt habe. Wenn dann wieder ein Nutzer (und ja es waren immer die BWLler :-) ) sein aktualisiertes Excel angeschleppt hat, wird es einfach markiert und die Tabelle kopiert. Damit sind die Daten portiert. Umgekehrt macht es auch durchaus Sinn, die mittels Abfragen analysierten und auf eine Tabelle reduzierten Daten aus einer Access-DB entsprechend aufzubereiten und in Excel weiterzuverarbeiten. Excel hat bessere Grafikdarstellungen. Was Access prima kann, sind Variationsanalysen: Will man z.B. ein optmiertes Widerstandsnetzwerk für einen bestimmten Fall finden, kann man einfach die R24 Tabelle mehrere male instanziieren und per DDE die Formel eingeben. Access spielt alle Kombis durch, wird die Doubletten raus und listet in der finalen Tabelle nur die erfolgreichen, die dem Ziel nahe genug kommen. So kann man sogar mehrere Kriterien mit einander schneiden, indem man Identitäten in den Tabellen sucht. Eine solche DB habe ich mir auch mal für die Verkettung von PLLs gebaut, wie sie beim Spartan 3E benötigt werden: Es werden für vorhandene Quarze, erlaubte Multiplier und Dividerwerte alle Kombinationen aufgelistet, wo sinnvolle Zwischenfrequenzen rauskommen und für diese dann eine M x M - Verkettung verwendet, um die Möglichkeiten zu finden, eine bestimmte Frequenz herzustellen. So und nur so habe ich seinerzeit eine Möglichkeit gefunden, mit einer Kombination aus zwei kaskadierten DCMs mit seltsamen MUL/DIV Werten genau die benötigten KGV-Frequenzen für Audioformate aus meinem gegebenen Quarz zu generieren. Durch manuelles Rumprobieren wäre ich nicht drauf gekommen.
Juergen Schuhmacher schrieb: > Mit Access kann man allerdings auch eigene Oberflächen verwenden, indem > man einen Datenzugriffsseite generiert und das Webinterfaace nutzt - > oder sich per SQL an das backend hängt. Ich habe das noch vor Jahren mit > wxWidgets getan. Das wäre dann auch mal in Richtung Linux/mySQL > portierbar. Nur als kleiner Hinweis am Rande: Datenzugriffseiten konnten sich nicht wirklich durchsetzen (wie ich finde aus gutem Grund ;-) ) und werden in den aktuellsten Versionen von Access auch nicht mehr unterstützt. Juergen Schuhmacher schrieb: > Alles, was n-fach 2-dimensional ist, als eine Parameterspalte und eine > oder mehrere Ausgangsspalten haben, ist in Excel am Besten aufgehoben. Naja ... darüber kann man streiten ;-) Access gehört nunmal in den Bereich der Relationalen Datenbanken. Das ist ein gänzlich anderes Konzept als das, das Excel verfolgt. Ich würde der Aussage deshalb so nicht zustimmen. Auch hier hängt es - wie immer - davon ab, was ich mit den Daten machen will. Was die Varianten-Lösung betrifft: das geht so natürlich und in der Praxis ist das auch vollkommen ok ... aber :-) ... das widerspricht ein wenig der Leere von relationalen Datenbanken. Dabei verwendest Du ein sog. "Kartesisches Produkt", das eigentlich immer durch einen Fehler - nämlich das Weglassen der korrekten Relationen - in der Datenbank entsteht. Aber wie gesagt: gehen tut es trotzdem ;-)
Reinhard Kern schrieb: > Nachdem wir regelmässig ganze Arbeitstage verloren haben, weil am > nächsten Morgen Access meldete "Die Accessdatenbank kann nicht geöffnet > werden. Dies liegt möglicherweise daran, dass sie beschädigt ist". Schon mal dran gedacht, dass da die Access Anwendung Schuld dran ist, weil der Anwendungsprogrammierer zu faul war, eine vernünftige Transaktionsabsicherung einzubauen und Nutzer die DB-Anwendung nicht vernünftig beendet haben? Da hat wohl die Qualitätskontrolle für die Auftragsprogrammierung gepennt.
@Wolfgang (Gast): auch das kann man so pauschal nicht sagen. Ich habe vor vielen Jahren mal eine Kunden- und Anlagenverwaltung für eine Vermögensverwaltung auf Basis MS-Access geschrieben. Damals noch in der Version 97. Das Ding lief absolut fehler- und problemfrei über viele Monate hinweg, bis plötzlich ähnliche Fälle auftauchten, in denen die Datenbank beschädigt wurde. In der Regel konnte dies durch die Reperatur-Funktion wieder behoben werden. Ich habe damals ne ganze Weile nach der Ursache geforscht. Wir konnten es dann eingrenzen auf den Fakt, dass die Datenbank immer nur beschädigt wurde, wenn sie von einem ganz bestimmten Rechner aus gestartet wurde. Das komische dabei: selbst ein komplettes Neuaufsetzen des Rechners hat daran nichts geändert. Wir haben nie wirklich rausgefunden, was die genaue Ursache war ... aber nach dem Aussondern des Rechners gab es nie wieder Probleme. Was ich damit sagen will: die Fehlerquellen können sehr vielschichtig sein und selbst bei gut funktionierender Qualitätskontrolle kann keine 100prozentige Fehlerfreiheit garantiert werden.
Digi Spark schrieb: > Naja ... darüber kann man streiten ;-) > Auch hier hängt es - wie immer - davon ab, was ich mit > den Daten machen will. Daher schrieb ich ja im Weiteren, dass man zu Access wechseln sollte, sobald eine größere Auswertung geplant ist. > Was die Varianten-Lösung betrifft: das geht so natürlich und in der > Praxis ist das auch vollkommen ok ... aber :-) ... das widerspricht ein > wenig der Leere von relationalen Datenbanken. Dabei verwendest Du ein > sog. "Kartesisches Produkt", das eigentlich immer durch einen Fehler - > nämlich das Weglassen der korrekten Relationen - Nicht ganz, denn durch die Nichtverknüpfung der Relationen wird zunächst gezielt eine Datenvielfalt erzeugt, die dann erst eine oder zwei Ebenen höher wieder eingeschränkt wird - z.B. durch die Bereiche der möglichen Lösungen. Eine derartige Abfrage wäre, ob ein Zielwiderstand zu einem E24 passt - d.h. sein Wert wird in der Accessliste dann mit dem passenden E24-Wert markiert und ab dann mit diesem weitersortiert, wobei gleiche Lösungen entfallen. Das vorgehen, die Primärtabellen unverknüpft zu verwenden, ist auch exakt richtig so, denn praktisch sind diese beiden Informationen auch unkorrelliert und stehen gleichberechtigt nebeneinander. Bei Relationen ist es ja meist so, dass eine Tabelle den Schlüssel für die andere liefert, also so eine Art Master-Slave-Beziehung vorherrscht. Man darf sich hier nicht davon täuschen lassen, dass es jeweils dieselbe Tabelle ist: Es könnten auch eine R und eine C sein, wenn es um RC-Dämpfung geht.
Ich habe ja auch geschrieben, dass das in der Praxis vollkommen i. O. so ... nur halt nicht in der reinen Lehre, da es dort keine Daten gibt, die nicht in Relation zueinander stehen (zumindest über andere Entitäten). Wenn doch, ist das Datenmodell falsch ... aber wie gesagt: das ist eine eher akademische Diskussion. Ich komme auch eher aus der Praxis und deshalb finde ich es auch vollkommen ok, wenn man ein RDBMS (relationales Datenbank Management System) dazu nutz, um so ein kartesisches Produkt zu erzeugen und auszuwerten. Wichtiger ist vielleicht der Hinweis, dass Access als Datenspeicher (=Backend) schon deutlich unter 100GB nicht mehr akzeptabel ist. Genau genommen ist eigentlich bei knapp 2 GB schon Schluss, da die Jet-Engine von Access keine größeren Dateien verwalten kann. Einige andere Einschränkungen und Limitierungen von Access (für die Version 2010) findet man z. B. hier: http://office.microsoft.com/de-de/access-help/access-2010-spezifikationen-HA010341462.aspx
Naja, ich denk mir halt (jetzt bezogen auf Excel vs. Access) der Hauptvorteil bei Access ist, dass man Datenbank und Frontend sauber voneinander trennen kann. Und wenn das Frontend sauber programmiert ist, schätze ich Access schneller, sauberer und va. nicht so umständlich wie Excell ein.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.