Werte Damen und Herren,
erstmal ein herzliches Hallo an alle Forumsmitglieder.
Ich bin neu hier und stehe vor einer, nunja, sagen wir mal so: einer sicherlich nicht unüberwindbaren Hürde, doch mir ist sie definitiv zu hoch... :) Für den Aufbau einer Kundendatenbank inkl. der Anlage von Produkten habe ich mich etwas näher mit Access beschäftigt. Grundlegend scheint Access alle notwendigen Funktionen mitzubringen, doch die Programmierung gestaltet sich als etwas schwieriger als angenommen. Ich habe zwar ein paar Grundkenntnisse in der Programmierung, doch diese sind A) bei Access absolut nicht gefragt und B) absolut nicht ausreichend. Ich habe zwar überlegt, mich da selbst reinzufuchsen, habe auch angefangen und bin schon ein paar Schritte vorangekommen, doch mittlerweile stehe ich da vor Herausforderungen die für mich nicht lösbar sind. Nicht ohne Hilfe von außen!!!
Ich würde mich freuen, wenn mir jemand weiterhelfen könnte.
Ich habe mir diese Vorlage von Microsoft geladen und möchte diese noch ein wenig praktikabler machen und erweitern: http://office.microsoft.com/de-de/templates/CT010211577.aspx?tl=2#ai:TC001225342|
Eine Tabelle anzulegen und auch über ein Formular mit Daten zu bestücken habe ich mitbekommen wie das geht. Hier habe ich bereits einige zusätzliche Felder eingefügt und mit Daten bestückt. Das funktioniert auch. Nur das praktikable Einbinden der Untertabellen in denen die Produkte eingepflegt werden, die zu dem Kunden gehören ist die aktuell zu meisternde Aufgabe.
Ich möchte in den Kontaktdetails einen Button haben. Wenn ich auf diesen klicke, dann soll ein Formular aufgehen, in dem ich das Produkt mit den Eigenschaften anlege. Dieses Produkt soll in der Untertabelle bei dem Kunden abgespeichert werden. Auf einem weiteren Reiter in den Kontaktdetails möchte ich dann die eingegebenen Produkte als Bericht einsehen können.
Wenn jetzt bei dem Kunden schon ein Produkt besteht, und ich auf den button klicke, dann soll das Fenster auch aufgehen und ich lege eben ein zweites Produkt an. Oder ein drittes, oder viertes.
Weiterhin sollen Berichte erstellt werden können, mit denen ich dann Einzelheiten zu den Kunden Anzeigen lassen kann und aber auch Berichte in denen beispielsweise alle Produkte (unter allen Kunden) mit den und den Eigenschaften angezeigt werden, also sprich, das nur die Untertabellen aller Kunden ausgewertet werden.
Meine Frage ist, ob mit jemand dabei weiterhelfen kann und ob mein Anliegen prinzipiell überhaupt realisierbar ist.
Weiterhin interessiert mich, wie man externe Dokumente einbindet. Ich möchte diese nicht in der Datenbank haben, sondern es soll nur ein Link zu einer Ordnerstruktur hinterlegt werden.
Ich spreche hier von einer Datenbank mit >1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen.
Ist das überhaupt praktikabel realisierbar? Wie sieht es mit einer Portierung in andere Datenbanken aus?
Fragen ??? über Fragen ??? , aber so ist es nun mal, wenn man neu hier ist...
Ich würde mich freuen, wenn mir jemand weiterhilft!
Viele Grüße sendet
Matthias
Hallo Matthias,
Natürlich lässt sich das von Access hervorragend lösen.
Du hast ja viel geschrieben aber nicht so richtig was passieren soll.
a) Willst du das ganze extern programmieren lassen?
b) Willst du es selber machen?
zu b:
hier habe ich das Gefühl, dass bei dir das Verständnis für Datenbanken allgemein sehr gering ist.
Von Access hast du sicherlich auch schon etwas gehört aber auch hier scheinen mir die Grundkenntnisse zu fehlen.
Ich will dir nicht zu Nahe treten aber wenn du die Lösung b möchtest musst du wahrscheinlich erstmal
Grundkenntnisse sammeln.
Gruß
Johann
Zitat von: fuenfsterne am Januar 31, 2012, 16:17:17
Ich habe zwar überlegt, mich da selbst reinzufuchsen, habe auch angefangen und bin schon ein paar Schritte vorangekommen, doch mittlerweile stehe ich da vor Herausforderungen die für mich nicht lösbar sind. Nicht ohne Hilfe von außen!!!
Hallo Matthias,
in der Tat ist Dein Vorhaben ergeizig. Es stellen sich folgende Fragen:
-Hilfe von außen aus einem Forum ist problematisch, wenn Du eine genaue Auskunft brauchst, aber immer nur einer antwortet, der gerade Zeit und Lust hat
-Wie wichtig ist die Datenbank? Nachdem Access nur für kleine Desktopanwendung vorgesehen ist, mußt Du immer mit Datenverlust rechnen. Access ist im Vergleich zu einer aktiven Datenbank für konkurrierendes Schreiben nur rudimentär ausgestattet. Access-Datenbanken können u.U. auch plötzlich unbenutzbar werden, dann ist die aktuelle mdb nicht mehr brauchbar. Es gibt keine Re-Do-Logs, beim Crash kannst Du immer nur auf die letzte kopierte mdb zurückgreifen. Für geschäftskritische Anwendungen ist Access nicht geeignet.
-Ablage auf dem Desktop oder im Netz? Im Zugriff über das Netz wäre eine Datenbank der angegebenen Größe kaum noch benutzbar.
Zitat
Weiterhin interessiert mich, wie man externe Dokumente einbindet. Ich möchte diese nicht in der Datenbank haben, sondern es soll nur ein Link zu einer Ordnerstruktur hinterlegt werden.
Du kannst in einem Textfeld die URL speichern, das wäre kein Problem.
Zitat
Ich spreche hier von einer Datenbank mit >1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen. Ist das überhaupt praktikabel realisierbar? Wie sieht es mit einer Portierung in andere Datenbanken aus?
Wenn Du das für Dein Geschäft brauchst, warum machst Du Dir dann die Mühe? Du würdest viele hundert Stunden brauchen, wenn Du etwas wirklich brauchbares zusammenbauen wolltest. Es gibt viele fertige Lösungen.
Außerdem wärst Du mit Access immer an Microsoft und VBA gebunden. Wenn Du dich in eine freie Datenbank (wie mySQL) einarbeiten würdest, hättest Du mehr Möglichkeiten zu skalieren.
Für eine Adressdatei oder eine kleine Aufgabenverwaltung ist Access sicherlich das beste. Man kann es schnell lernen. Aber es gerät schnell an seine Grenzen. Mit einer anderen Datenbank hast Du vielleicht keine so steile Lernkurve, es wäre m.E. langfristig aber lohnender.
Hallo Wurliwurm,
deine Aussagen über Access kann ich so nicht stehen lassen. So schlecht wie du es darstellst ist es nicht
was ich dir an viele schon seit Jahren laufende Anwenden beweisen könnte.
z. B. Auskunftssystem mit ca. 250.000 Artikel mit Verfügbarkeit nach Lager, bestellt, Bestellmöglichkeit beim Lieferanten
Zusammensetzung im Detail. Entwickelt mit Acc-95!!! und nur kleine Anpassungen an neue Anforderungen.
Läuft auf einen Server mit Zugriff von bis zu 6 Mitarbeitern. Telefonauskunft ist möglich,.
Auch andere Anwendungen von mir laufen schon seit Jahren.
Bei Matthias bin ich schon der Meinung das für diese Aufgabe zu wenig Grundkenntnisse vorhanden sind.
Aber dazu muss er sich erstmal melden.
Gruß
Johann
Zitat von: Jonny am Februar 01, 2012, 14:36:06
deine Aussagen über Access kann ich so nicht stehen lassen. So schlecht wie du es darstellst ist es nicht
Hallo Johnny,
ich meine nicht, es als schlecht dargestellt zu haben, sondern nur, daß es ab einer einer bestimmten Größe und Anforderungen an die Datenqualität keine so gute Wahl mehr ist. Als Vergleich: Auch mit Excel kann man tolle Dinge machen, unter anderem auch Daten speichern, aber trotzdem ist es als Datenspeicher nicht besonders gut geeignet. Diese Aussage heißt nicht, Excel schlecht zu machen.
Access in einer Größe von dem Auskunftssystem, das Du beschrieben hast ist schon beeindruckend. Aber wahrscheinlich skaliert es nicht mehr, dass heißt, 2,5 Mio Datensätze oder 60 User gehen nicht mehr. Ich kenne Access vor allem als Auswertungstool, das heißt die Daten werden als Dump regelmäßig aus einer großen Datenbank gezogen und dann im Access Queries gemacht. Zum Beispiel dient das Access dann als Datenquelle für Excel (Diagramme etc...). Als OLTP-System mit konkurrierenden Schreib- und Lesezugriffen ist Access nicht verbreitet. Ich möchte nicht mein Konto bei einer Bank führen, die die Kontoinformationen in Access speichert.
Die große Schwäche von Access (das habe ich schon mal ausgeführt) ist die File-Server-Architektur, z.B. Queries werden auf dem Client verarbeitet von der Jet dll und es muß erst einmal alles über das Netz. Wie schnell geht das in Deiner Auskunft-Datenbank, wenn drei Anwender gleichzeitig eine gruppierte Abfrage mit Having-Bedingung machen? (etwa alle Artikelgruppen, von denen insgesamt genau 23 Stück vorhanden sind). In einer aktiven Datenbank muß vielleicht nur jeweils ein Paketchen mit der SQL-Anfrage über das Netz und es kommt 1 KB Treffermenge zurück.
Zitat
Bei Matthias bin ich schon der Meinung das für diese Aufgabe zu wenig Grundkenntnisse vorhanden sind.
Wenn er noch nichts kann, dann kann er sich auch in ein aktives Datenbanksystem einarbeiten, zum Beispiel in Microsoft SQL Server (die freie Version), MySQL oder die Express Version von Oracle. Da wird der Anfang zwar weh tun, weil er nicht einfach sich die Sachen so einfach zusammenklicken kann. Dafür hat er aber vieles mehr wie unterschiedliche User mit genauer Rechtevergabe, Logging und erweiterte Möglichkeiten, die Datenqualität zu kontrollieren wie Trigger, Stored procedures und vieles mehr.
Wir können hier gerne fachsimpeln, aber wahrscheinlich meldet er sich eh nicht mehr...
ZitatIch kenne Access vor allem als Auswertungstool, das heißt die Daten werden als Dump regelmäßig aus einer großen Datenbank gezogen und dann im Access Queries gemacht.
Das ist nun das eigentlich Grauselige: Warum muss man eine solche "fürchterliche Desktop-Datenbank" wie Access verwenden, wo man doch eine
richtige Datenbank zur Verfügung hat. Kann man nicht einfach dort die Queries bereit stellen, die benötigt werden. Statt sich mit dem Finger die Nase hochzuhalten, sollte die IT besser so arbeiten, dass Fachabteilungen gar nicht erst auf solche Ideen kommen können oder müssen und Reports (also unnormalisierte Daten) irgendwie verwurschten müssen.
Daneben ist Access unwidersprochen bestens geeignet, einfach und schnell ein GUI für eine Datenbank (egal ob als Backend SQL Server, PostgreSQL, MySQL oder File-Backends) zu erstellen.
Und: Wenn man sein Produkt kennt und richtig anwendet, kann man mit der kleinen Lösung (Access) sehr viel leisten. Wer wie der Threadersteller froh ist,
eine Tabelle und
ein Formular zu erstellen, denkt wohl kaum an 60 permanent gleichzeitig arbeitende User und Millionen Datensätze pro Tabelle, sondern vielleicht nur einfach daran, sich selber (ganz alleine) die Arbeit etwas zu erleichtern. Wenn ich statt spazieren laufen möchte, brauche ich noch keinen Ferrari auf einer Autobahn.
MfGA
ebs
Hallo Johannes,
auch wenn du rein formal in den Punkten recht hast kann ich die Diskussion in einem
Access-Forum nicht so recht nachvollziehen.
Viele User hier haben schon leistungsstarke DBs entwickelt; die "Schwächen" für eine Access-Anwendung sind bekannt, für Matthias evt. nicht, aber ihn nun mit solchen Thesen als Einsteiger zu bearbeiten erscheint mir wenig zweckmäßig ;D. Zumal nach meinen Erfahrungen die Grenzen von Access eher überschätzt werden!
Nach Abschätztung der Daten von Matthias erscheint doch Access ein sehr geeignetes Werkzeug zu sein (wenn man von nicht "zu vielen" Nutzern ausgeht). Insofern stimme ich Johann zu.
Und übrigens:
Zitatund es muß erst einmal alles über das Netz.
auch wenn man das vielfach liest, wird es dadurch nicht richtig!
Gruß Oma
Hallo ebs,
warst gerade etwas schneller; arbeitest du etwa auch mit solch fürchterlichen Werzeug wie MS-Access?
Gruß Oma
Zitatarbeitest du etwa auch mit solch fürchterlichen Werzeug wie MS-Access?
Ja. Siehe auch Status von Access (http://www.donkarl.com/Downloads/AEK/AEK14_Status.zip).
Übrigens muss man sich auch in Access nicht auf (verfügbare!) Assistenten verlassen (also irgendetwas irgendwie zusammenklicken), sondern man kann auch
- gescheite Prozeduren unter Einbeziehung von Klassen programmieren,
- effektive Abfragen schreiben.
Eine kräftigere Maschine (DBMS) bedeutet nicht zwingend, dass man auch schneller und besser fahren kann. Die vorhandene oder mögliche Straße und Fähigkeiten des Fahrers spielen da auch eine wesentliche Rolle.
Zitat von: ebs17 am Februar 01, 2012, 22:54:17
Kann man nicht einfach dort die Queries bereit stellen, die benötigt werden. Statt sich mit dem Finger die Nase hochzuhalten, sollte die IT besser so arbeiten, dass Fachabteilungen gar nicht erst auf solche Ideen kommen können oder müssen und Reports (also unnormalisierte Daten) irgendwie verwurschten müssen.
Mit Queries können nur noch die Poweruser arbeiten, selbst mit Access als Datenquelle kommen viele nicht zurecht. Normalisiert brauchen die Daten in einer Reporting-Datenbank eh nicht sein, das ist nur bei Update-lastigen Datenbanken ein Thema.
Zitat
Daneben ist Access unwidersprochen bestens geeignet, einfach und schnell ein GUI für eine Datenbank (egal ob als Backend SQL Server, PostgreSQL, MySQL oder File-Backends) zu erstellen.
Absolut. Meine Vorbehalte beziehen sich nur auf die Jet-Engine. Access kann mit aktiven Datenbanken schneller und stabiler besser zusammenarbeitenals mit der Jet-Engine. Die Lernhürde ist dabei, ADO zu lernen.
Zitat
Wer wie der Threadersteller froh ist, eine Tabelle und ein Formular zu erstellen, denkt wohl kaum an 60 permanent gleichzeitig arbeitende User und Millionen Datensätze pro Tabelle, sondern vielleicht nur einfach daran, sich selber (ganz alleine) die Arbeit etwas zu erleichtern. Wenn ich statt spazieren laufen möchte, brauche ich noch keinen Ferrari auf einer Autobahn.
Sicherlich.
Ich habe mir die Präsentation von der Entwicklerkonferenz, die Du hochgeladen hast, angesehen und fand Sie sehr interessant. Da ist eigentlich schon alles gesagt. Vielleicht fehlt aber noch als Ergänzung die Kategorisierung der Access-Freunde, zum Beispiel den Accesser, der alles, was irgendwie gerade noch halbwegs mit Access lösbar ist, unbedingt mit Access lösen will. Diese "Krankheit" ist verwandt mit der Excelitis. :-)
Übrigens: Man kann im Laborversuch die Jet-Engine leicht in die Knie zwingen. Dazu muß man nur eine MDB starten, die in einer Schleife bestimmte Daten immer wieder liest. Dazu noch mindestens zwei mdb starten, die ebenfalls in einer Schleife diese Daten immer wieder löschen und neu anlegen. Wenn man die Geschwindigkeit der Schreibe-mdbs erhöht (die Wartezeit zwischen zwei Durchläufen auf unter 500ms etwa verringert), dann hagelt es bald Fehler, es kommt zu dirty reads und das Backend bläht sich auf bis es platzt. Mit einer aktiven Datenbank hingegen sieht man, was Serialisierung bedeutet: Es läuft seidenweich wie ein Zwölfzylinder, ohne Knattern und Fehlzündungen.
Zitat von: oma am Februar 01, 2012, 22:59:32
Nach Abschätztung der Daten von Matthias erscheint doch Access ein sehr geeignetes Werkzeug zu sein (wenn man von nicht "zu vielen" Nutzern ausgeht). Insofern stimme ich Johann zu.
Hallo Oma,
wahrscheinlich hast Du recht. Soll er es mit Access machen, besser als Excel ist es dafür allemal.
Zitat
Zitatund es muß erst einmal alles über das Netz.
auch wenn man das vielfach liest, wird es dadurch nicht richtig!
Wo soll bitte die Verarbeitung zum Beispiel bei einer gruppierten Query mit Having-Bendigung (wo also die Selektionsbedingungen erst nach der Gruppierung angewandt werden können) denn stattfinden, wenn nicht auf dem Client? Vielleicht hat Jet da einen lokalen Puffer, aber dann entsteht Overhead durch die Synchronisierung dieses Puffers.
Hallo Johannes,
toll was man alles so feststellen kann um Acc schlecht zu machen.
Nimm ein DB-Modell was hier gebraucht wird und wo die Normalisierung gut durchdacht ist.
Nimm die Tabellenzugriffe mit DAO oder ADO.
Stelle vernünftige SQL-String zusammen und mache den Set damit.
Lasse die Laborgeschichte weg, die braucht hier keiner
und du wirst feststellen das man einiges mit Acc machen kann.
Ach ja wir sind hier übrigens in ein Access-Forum wo die Mitglieder mit Acc arbeiten
und dazu Fragen haben. Andere Mitglieder versuchen zu helfen und das Ganze
führt auch noch zum Erfolg.
Gruß
Johann
Zitat von: Jonny am Februar 02, 2012, 13:01:13
toll was man alles so feststellen kann um Acc schlecht zu machen.
Wir reden hier aneinander vorbei. Was soll die Trotzhaltung?
Kannst Du als Access-Profi differenzieren zwischen Kritik an der Jet Engine und Empfehlung von Access als RAD?
Zitat
Nimm die Tabellenzugriffe mit (...) ADO.
Ach was? Das meine ich doch! ADO ist für Zugriff auf aktive Datenbanken da. Man braucht da nur die Parameter der Connection ändern, und schon ist man weg von Jet.
Hier ein anderer Access-Profi zu Deiner Empfehlung von ADO:
http://books.google.de/books?id=PO22n_tT9YIC&pg=PA308&lpg=PA308&dq=baloui+ado+dao&source=bl&ots=k_fQWsvFIF&sig=9ZPMVGT_hNT7klwdasIFNA1wAwM&hl=de&sa=X&ei=s4cqT8-0DdHNswbrre2eDQ&ved=0CCIQ6AEwAA#v=onepage&q=baloui%20ado%20dao&f=false (http://books.google.de/books?id=PO22n_tT9YIC&pg=PA308&lpg=PA308&dq=baloui+ado+dao&source=bl&ots=k_fQWsvFIF&sig=9ZPMVGT_hNT7klwdasIFNA1wAwM&hl=de&sa=X&ei=s4cqT8-0DdHNswbrre2eDQ&ved=0CCIQ6AEwAA#v=onepage&q=baloui%20ado%20dao&f=false)
Zitat"...für Access- Anwender/Programmierer ist jedoch das ältere DAO vorzuziehen, da es optimal an die Jet Engine und Access-Datenbanken angepasst ist und ohne jede Einschränkungen alles zur Verfügung stellt, was für den Umgang mit diesem Datenbanktyp benötigt wird - und das so einfach wie möglich!
Zumindest, solange Sie als Access-Anwender/Programmierer nahezu ausschließlich das tun, was zu vermuten ist: lokale Access-Datenbanken erzeugen und programmieren. Dann sollten Sie das ältere, für diesen Zweck aber besser geeignete DAO verwenden.
ADO sollten Sie einsetzen, wenn Sie zwar Access benutzen, ungewöhnlicherweise an Access-Datenbanken aber nur am Rande oder gar überhaupt nicht interessiert sind. Wenn Sie Access eigentlich nur als Frontend zum Zugriff auf Datenbanken benutzen wollen, die sich auf einem Oracle-, MS SQL-Server oder wo auch immer befinden. .."
ZitatMit Queries können nur noch die Poweruser arbeiten
Das heißt übersetzt: Sei Poweruser (was immer das sein soll) oder lasse strikt die Finger von jeglicher Datenbank. Welch ein Unsinn!
Abfragen sind die erste Verarbeitungsschicht auf Daten, die in Tabellen liegen, und zwar eine extrem wichtige und leistungsfähige. Der Verzicht darauf heißt Verzicht auf Datenbankarbeit.
Ein User sollte übrigens Ergebnisse bekommen und nicht selber Abfragen erstellen müssen. Dafür ist dann der Entwickler zuständig - und sicher auch dafür, dass ein Reporting im "schnurrenden" DBMS vollendet wird und nicht auf Access oder Excel ausweichen muss, dann noch oft betreut von eher Anfängern, Praktikanten u.a., die nicht schnell genug weglaufen können.
ZitatÜbrigens: Man kann im Laborversuch die Jet-Engine leicht in die Knie zwingen.
Man kann auch mit den Tellern seines Meißner Prozellans Nägel in die Wand einschlagen. Aber wer macht so etwas. Man muss sein Produkt schon kennen und richtig einsetzen.
Datenbankarbeit heißt nicht zwangsläufig, die Betriebsdaten eines mittelständigen Unternehmens zu verwalten, sondern durchaus auch eine Verwaltung eines Vereins, einer Kochrezeptesammlung, einer privaten CD-/DVD-Sammlung u.a., und das schlicht lokal (ohne Netzwerk). Dafür wird dann auch niemand ein Oracle aufsetzen, weil es doch so schön leistungsfähig ist.
MfGA
ebs
Zitat von: ebs17 am Februar 02, 2012, 14:18:24
Datenbankarbeit heißt nicht zwangsläufig, die Betriebsdaten eines mittelständigen Unternehmens zu verwalten, sondern durchaus auch eine Verwaltung eines Vereins, einer Kochrezeptesammlung, einer privaten CD-/DVD-Sammlung u.a., und das schlicht lokal (ohne Netzwerk).
Ursprünglich war die Rede von
Zitat
>1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen.
Das ist schon eine ganz andere Dimension als eine CD- oder Kochrezeptesammlung. Das sind schon durchaus mitteldständische Dimensionen.
Zitat
Dafür wird dann auch niemand ein Oracle aufsetzen, weil es doch so schön leistungsfähig ist.
Doch, ich. :-) Aber das vielleicht eine Berufskrankheit.
Der 08/15-User wird für solche Sache wahrscheinlich eh Excel benutzen.
Hallo Ebs, Hallo Johannes,
lass uns doch ein Fazit ziehen und damit die Diskussion beenden.
Access ist in der Theorie nicht zu benutzen. :o
Access ist in der Praxis durchaus benutzbar. ;)
Gruß
Johann
Hallo,
solche Diskussionen gibt es, solange es Access-Foren gibt. Fast immer auch mit der gleichen Rollenverteilungen und gleichen Argumenten (allerdings ist der "Laborversuch" von Johannes schon kreativ, da einmalig).
Übrigens fand ich den Beitrag , AEK14_Status recht gut
@Johannes (Wurliwurm und nicht Johann)
Habe mal überlegt welcher Typ der Access-Feinde aus dem Beitrag zu dir passt ;D
Access-Feind 2# und auch Access-Feind #4 sicher nicht (denn ahnungslos bist du sicher nicht) aber Access-Feind #3 scheint mir wohl in der Nähe... ;D ;D
Nichts für ungut, dass Thema ist ja an sich schon spannend, nur den armen Matthias haben wir aber nun wohl völlig vergrault.
Gruß Oma
Zitat
Access-Feind #3 scheint mir wohl in der Nähe.
Hallo Oma,
da hast Du richtig geraten
Hallo,
wer den Unterschied zwischen einer aktiven Datenbank mit strikt serialisierbaren Transaktionen und der Jet Engine live sehen will, kann sich die auf meinem Mist gewachsene beigefügte Datei runterladen und damit spielen. Stichwort "Leser-Schreiber-Problem". Vergleichen mit Oracle kann man natürlich nur, wenn man Oracle zur Verfügung hat
Zum Laborversuch:
Es gibt eine MDB, die bucht, und zwar immer in einer Transaktion zuerst alle bestehenden Datensätze löscht und anschließend wieder 1000 Datensätze bucht. Alle Datensätze ergeben in der Summe Null (damit man dirty-reads erkennen kann, wo man nicht vollständig gelöschte Datensätze noch oder halbfertige Transaktionen schon sehen kann).
Außerdem gibt es eine MDB, die eine Abfrage startet und im Log ausgibt, wenn unsaubere Daten gelesen werden.
Wenn man den Versuch starten will, dann die Schreibe-mdb n-mal kopieren. Alle MDBs sollten im gleichen Verzeichnis sein, damit die Logs in das Unterverzeichnis \Logs richtig geschrieben werden.
Dann erst die Lese-Mdb starten, dann der Reihenfolge nach die Clients. Man kann bei Interesse die Parametern für die Wartezeit zwischen den Durchläufen ändern. Wenn das Programm eine Zeitlang laufen, kann man sehen, wie die Fehler auftauchen.
Ich habe das ausprobiert auf einem lokalen PC und folgendes festgestellt:
Das Schreiben geht beim Access-Backend sehr schnell, aber es kommt zu Fehlern, so daß eine Transaktion abbricht. Bei Oracle-Backend dauert das Schreiben länger, aber die Historie ist seriell: Eine wunderschöne Abwechslung von Client1 und Client2, sauber wie ein Reißverschluss.
Das Lesen hingegen braucht beim Access länger, aber regelmäßig gibt es Fehler, die schlimmsten davon sind, daß falsche Werte kommen, aber kein Fehler geworfen sind.
Außerdem bläht sich das Access-Backend auf. Wenn es nicht komprimiert wird, dann platzt es irgendwann. Das Oracle-Beispiel läuft und läuft, es gibt niemals Fehler und wenn es nicht abgeschossen wurde, läuft es noch immer. :)
Vielleicht findet ja der eine oder andere es interessant. Es ist alles Access, reines VBA mit ADO.
[Anhang gelöscht durch Administrator]
Zitat von: Wurliwurm am Februar 01, 2012, 15:41:55
Wir können hier gerne fachsimpeln, aber wahrscheinlich meldet er sich eh nicht mehr...
Ha, o doch... :) Da bin ich wieder... Fast hättet ihr mich vergrault, aber nur fast... :D Ist halt dann nur etwas mühsam wenn Beiträge gepostet werden, die wenig bis nichts zur Sache an sich beitragen. Als Threadopener lieste ja doch jeden Beitrag weil du denkst, da steht was drin was dir weiterhilft... Aber gut. Ich kenne das aus anderen Foren... :) Kein Problem...
Habt erstmal vielen Dank für die Reaktionen. Ich habe verstanden, das das Ganze mit Excel lösbar ist, aber sicherlich für einen Anfänger wie mich etwas Arbeit bedeutet.
Zitat von: Jonny am Februar 01, 2012, 09:57:33
Du hast ja viel geschrieben aber nicht so richtig was passieren soll.
Da hast Du Recht. Genau das will ich herausfinden. Es stellt sich folgende Problematik: die fertigen Lösungen!
Zitat von: Wurliwurm am Februar 01, 2012, 13:25:52
Wenn Du das für Dein Geschäft brauchst, warum machst Du Dir dann die Mühe? Du würdest viele hundert Stunden brauchen, wenn Du etwas wirklich brauchbares zusammenbauen wolltest. Es gibt viele fertige Lösungen.
Man kann sehr viel Geld ausgeben für ein CRM oder eine Kundendatenbank, um am Ende festzustellen, das es den Anforderungen entweder nicht genügt oder eben auch viel zu viel kann. Das stellt man dann jedoch leider erst im täglichen Gebrauch fest, daher tendiere ich zu der Lösung eine eigene Variante zu bauen. A) kostet es weniger (zumindest weniger Geld, dafür mehr Zeit) und B) kann ich die Lösung, wenn ich mich da einmal reingefuchst habe, immer wieder Veränderungen anpassen. (z.B. ein zusätzliches Feld einfügen, einen zusätzlichen Bericht erstellen lassen, etc.)
Ich brauche lediglich eine Möglichkeit, Kunden zu verwalten (mit sämtlichen Kundendaten) und die einzelnen Produkte anzulegen. Es müssen Berichte/bzw. Statistiken abrufbar sein wie z.B. Umsatz den der Kunde dem Unternehmen gebracht hat, welche Produkte er gekauft hat, etc. Ich muss auch z.B. Laufzeiten von Produkten anzeigen lassen können, z.B. Laufzeit bis 01.12.2012.
Diese Datenbank soll an sich nicht im Web stehen, obwohl ich ein NAS installiert habe, auf das ich von außen über einen SSL-verschlüsselten Tunnel zugreifen kann. Nennen wir es einfach Intranet... :)
Wenn die Datenbank dort liegt, dann müsste ich die ja auch per Access öffnen können, und wenn ich mir von außen Schreibrechte erteilt habe, dann müsste ich diese ja nach der Dateneingabe auch speichern können. Diese Option sollte schon offen bleiben die Datenbank auch übers Internet abrufen zu können.
Welche Alternativen gibt es denn? Ich höre hier SQL, Oracle, etc.
Mir platzt der Kopf. Wäre denn jemand bereit, sich an eine solche Aufgabe heranzuwagen?
Viele Grüße und ein schönes Wochenende wünscht
Matthias
Hallo Matthias,
schön das Du dich nicht abgemeldet hast.
Hier im Forum die Db mit allen Einzelheiten zu erstellen wird meiner Meinung nach nicht gehen
da es zu Aufwendig ist und wirklich 100 Stunden vergehen bevor Du was gescheites hast.
Eine Möglichkeit wäre das jemand für Dich die grobarbeiten durchführt.
Das Ganze kommentiert und Du musst nur noch kleine Anpassungen vornehmen.
Gruß
Johann
Hallo Matthias,
um die ganzen Beiträge loszuwerden, schlage ich dir die Erstellung eines neuen Themas vor, da hier sowieso keine mehr einsteigt u. alles lesen will!
Ein neues Thema dann, wenn du dich entschließt, die Entwicklung alleine zu betreiben. Alleine bedeutet trotz Unterstützung im Forum etliche Stunden und eine ziemliche lange Zeit bis zur ersten praktischen Arbeit mit der DB.
Ansonsten bleibt auch der Weg, um professionelle Hilfe. Hier im Forum gibt es mehrere Mitglieder, ich würde dir DF6GL empfehlen , den kannst du über eine PN hierzu kontaktieren.
Wenn du den steinigen (aber auch spannenden und "wissenerweiternden") Weg der Eigenentwicklung gehen willst, erstelle ein neues Thema mit:
1. Kurzbeschreibung der Aufgaben
2. Entwurf eines Tabellenaufbaus mit Feldbeschreibung
Gruß Oma
Hallo,
auch ich mach Auftragsprogrammierung auf Rechnung mit UStd-ID ausgewiesen Mehrwertsteuer und
bestimmt keine Schwarzarbeit, genau wie DF6GL.
Bei Interesse kannst Du mir eine PN schicken. Ein Angebot könnte ich Die in der nächsten Woche machen
aber die Programmierung frühestens im März.
Gruß
Johann
Zitat von: fuenfsterne am Februar 03, 2012, 16:20:27
...Diese Option sollte schon offen bleiben die Datenbank auch übers Internet abrufen zu können....
...Welche Alternativen gibt es denn? Ich höre hier SQL, Oracle, etc....
Hallo Matthias,
Access als Frontend ist schon eine gute Wahl. Die anderen Plattformen wie Java, *.Net etc erfordern ein vielfaches an Aufwand, weil sie abstrakter sind und es Jahre braucht, bis man richtig produktiv so arbeiten kann, daß jeder Handgriff sitzt.
Wo die Daten gespeichert werden, da haben wir ja weiter oben die Diskussion gehabt. Ich will hier nicht als Schlechtmacher o.ä. dastehen, deswegen hier nur mein konstruktiver Vorschlag bzw ein paar Schlagwörter:
Benutze als Zugriffstechnik für die Daten ADO. Dann hast Du die Möglichkeit (wenn das sauber aufgesetzt ist), später mit ein paar Handgriffen auf eine aktive ("echte") Datenbank zu migrieren. Damit würde die Lösung auch über das Netz wunderbar funktionieren. Es gibt da ein paar kleine Dinge zu beachten, zum Beispiel nicht den Flag (ja/nein) als Feldwert in der Datenbank zu nehmen, weil es diesen in anderen Datenbanken nicht gibt. Wie das mit ADO geht, da bist Du hier sicher in guten Händen.
Aber zuerst gilt es, ein gutes Datenmodell zu entwerfen, und da bist Du hier sicher auch in guten Händen.
OK, es ist erstmal schön zu wissen, das ich hier an der richtigen Stelle bin.
Da habe ich noch eine Frage. Ein befreundeter Mediengestalter baut mir gerade die Homepage. Entweder mit Drupal oder mit Typo3. Das weiß ich jetzt nicht genau. Dazu habe ich ein Hostingpaket erworben, man braucht ja für die CMS-Systeme i.d.R. SQL-Datenbanken.
Kann man denn diese Datenbanken auch für mein Projekt nutzen? So daß das ganze quasi bei meinem Hoster liegt und ich darauf über ein Backend Onlinezugrif habe? Selbstverständlich SSL-gesichert... Geht das?
Ansonsten werde ich mir in den nächsten Tagen Gedanken machen, wie ich das Ganze nun lösen will.
Erstmal noch ein dickes Dankeschön an euch und ein schönes Wochenende...
Matthias
Zitat von: fuenfsterne am Februar 04, 2012, 13:30:27
Kann man denn diese Datenbanken auch für mein Projekt nutzen? So daß das ganze quasi bei meinem Hoster liegt und ich darauf über ein Backend Onlinezugrif habe? Selbstverständlich SSL-gesichert... Geht das?
Grundsätzlich geht fast alles. In der Entwurfsphase solltest Du mit einer lokalen Access-Datenbank auf dem PC beginnen. Wenn das dann läuft, kannst Du Dir Gedanken machen, wie Du die Architektur machst.
Für Webseiten benutzt man normalerweise php oder java-Servlets. Ich könnte es mir so vorstellen, daß der Kunde die Webseite aufruft und das html per php aufbereitet wird. Du als Unternehmer hingegen greifst auf die Datenbank per Access-Client zu. Für den Zugriff auf die Datenbank vom Access aus ist SSL aber nicht die richtige Verschlüsselungstechnik, SSL gehört zu http (dem Protokoll, mit dem vor allem die html-Seiten übertragen werden).
Zitat von: Wurliwurm am Februar 04, 2012, 14:25:34
Für den Zugriff auf die Datenbank vom Access aus ist SSL aber nicht die richtige Verschlüsselungstechnik, SSL gehört zu http (dem Protokoll, mit dem vor allem die html-Seiten übertragen werden).
Ich habe kurz gegoogelt und wahrscheinlich geht ADO.Connection über SSL doch.