Access als Frontend für MYSQL?

Hallo Claude,


also prinzipiell ist es Möglich die Accesstabellen in MySQL, MSSQL oder ORacle zu importieren und diese dann wieder per ODBC zurück ins Access zu holen und dann mit dem Server zu arbeiten.
Die ganze Sache ist auch recht stabil und je nach Server wo die Datenbank liegt recht flott.
Problem ist und das sehe ich wie Felix das Ihr zwei schritte machen müsst und da ist es wichtig das Ihr keine Operation am offenen Herzen macht wie ich gerne sowas nenne.

Schritt 1:
An deiner Stelle würde ich erstmal klären welche Datenbank Ihr nutzen werdet. Auch mit MySQL kommt man an Grenzen doch ist es um längen besser als Access.

Schritt 2:
Wenn die Datenbank feststeht erstmal die Tabellen portieren. Wenn das einwandfrei klappt die Tabellen in Access per ODBC verknüpfen und dann mit dem Frontend testen.

Schritt 3:
Testen indem einige Mitarbeiter drauf dürfen und arbeiten erst wenn da keien Fehler auftauchen die komplettumstellung.

Schritt 4:
Den Urlaub auf Honduras genießen ;o)

Zwischenschritt:
Ich würde zwischen die Schritte aber auch gleich deinem Chef mitteilen das es besser ist auf Office 2003 oder höher ein Upgrade zu machen und dann weiter bei Schritt 2
;o)

Gruß

Sven

kein problem immer wieder gerne.

Lädst du Dir den ODBC 3.51 von MYSQL runter installieren.

Eine ODBC Quelle anlegen auf die DB die du nutzen willst.

Dann in Access dein Frontend öffnen und dort dann unter dem Menuepunkt Einfügen auf Tabelle gehen. Dort den Punkt Tabelle verknüpfen auswählen und mit "ok" Bestätigen.

Im folgedialog den Dateityp ODBC Quelle auswählen. Dort den zweiten Reiter aktivieren (Computerdatenquelle. Dort werden alle ODBC verbindungen angezeigt ) und deine vorher erstellte ODBC quelle auswählen. Dann die Tabellen auswählen die du brauchst. Ich denke mal das es alle sind. Sprich alle auswählen anklickne und dann mit ok beenden.

Dann hast du alle Tabellen die auf dem MYSQL server liegen in deinem Frontend. Dort kannst du dann so wie vorher auch per query auf deine Tabellen zugreifen. Temporäre Tabellen die du nur kurz brauchst kannst du auch in access anlegen und dann wieder löschen.

Pass nur auf das deine Accessdb dadurch auch wenn du Datensätze löschst immer größer wird da access auch für gelöschte Datensätze oder Tabellen Speicher allociert. Sprich in Regelmäßigen abständen eine DB komprimierung machen. Dabei werden nur die Tabellen die direkt in Access sind berücksichtig nicht die Tabellen die im MYSQL-Server liegen.

Also sinniger ist es dann das du die temptabellen dann auf dem MYSQL anlegst und dort auch wieder löschst.


Hoffe das ich dir noch etwas helfen konnte. Ansonsten schaust du auch nochmal hier nach
Link zu Access mit verlinkten Tabellen

Gruß and have fun at work

Sven

Hi,


Also 15 verschiedene Front-Ends, respektive Anwendungen? Woow.



Bitte stelle Dir das nicht zu einfach vor! Es sind bei einer Migrierung viele Dinge zu beachten. Auch wenn es einige sehr nützliche Tools dafür gibt.


Wie Sven schon empfehlte ist es wichtig sich ersteinmal für ein entsprechendes Backend-System zu entscheiden.

Wenn Ihr euch nun für MySQL entscheidet, mit PHP (und direkter MySQL Kommunikation) die WebApplication erstellt, allerdings in zwei Jahren feststellt das MySQL neuen Anforderungen nicht mehr gerecht wird, müsstet Ihr die WebApplication u.U. komplett auf ein anderes SQL-Server BE anpassen. *Puh* Langer Satz. Worauf ich hier hinauswollte: Verwendet in eurer PHP-Application besser ADO als direkte Kommunikation mit einem SQL-Server.

Gibst's da

Also da kann ich Dir das von MySQL selbst empfehlen:MySQL Migration Toolkit

Es gibt auch ein nettes Video Tuturial dazu.

Hi,


Nein, nicht unbedingt. mit SQl-Server meinte ich das generell nicht explizit das Produkt von Microsoft. Wollte nur andeuten das wenn Ihr ADO zur Kommunikation mit einem SQL-Server (ob nun MySQL, Oracle, etc) verwendet, wäre bei einem evtl. Umstieg sehr viel weniger Arbeit in eurer PHP-Anwendung. bin jetzt mit PHP nicht so konform, meine aber zu wissen das es spezielle Module für unterschiedliche SQL-Server existieren: also speziell für mySQL, Oracle oder MS SQL-Server.

Mit ADO als Schnittstelle zwischen PHP-(ODBC)-Backend wäre euer PHP Code halt leichter zu warten.
Vielleicht hier in diesem Thread ein eher unwichtiger Hinweis. Kam mir da nur in den Sinn.

BG, Felix -misterdemeanor-

Diese Module gibt es.

Ob nun MySql oder MSSQL könnte wieder zu einem Thread epischer Länge führen. Beide haben ihr Vorteile.
Hast du einfach Tabellen ohne viel Referenzen reicht MySQL vollkommen aus. Hast du viele Referenzen würde ich Dir den MSSQL empfehlen.
Nachteil MSSQL ist der kostenpunkt.
Ansonsten hat es schon seinen Grund warum selbst die Börse auf MSSQL 2005 umgestiegen ist und nicht MYSQL nutzt.
Nein nicht nur Werbung und evtl Vorteile bei Microsoft. Der MSSQL2005 ist sehr stabil und schnell. Er kann zwar keinem Ora Server das Wasser reichen ist aber auch lange nicht so kompliziert zu Administrieren und Trotzdem schnell. Vor allem wenn man evtl noch einen 2003 Srv hat wo er drauf läuft.

Sprich MySQL ist nicht schlecht und MSSQL auch nicht. Es kommt halt auf die Anwendung an die darauf zugreifen soll oder muss.


Gruß

Sven

BOFH Mode ON
Dann empfehle ich eine ständig erreichbare Startseite mit einem Verweis auf Dein Spenden-Konto in Luxemburg
BOFH Mode OFF

IwO. Als echter BOFH kann es für Dich keine Überraschung gewesen sein das spezielle Leute eine spezielle DVD zugespielt bekommen haben. Was nebenbei Deinem Konto selbst nochmal saftige Zinsen in der nächsten Zeit beschert.

Hallo Claude,

nur um dir den Enthusiasmus ein wenig zu nehmen, beide DBMS Systeme egal ob MSSQL oder MySQL sind nicht so einfach zu administrieren wie Access. Es hat schon seinen Sinn warum man für dieses Datenbanken Schulungen angeboten bekommt.
Ich selber bin entwickler und mache den DBA für Oracle Cluster, MSSQL und MYSQL und trotzdem muss ich ab und an mal was nachlesen. Das bleibt nicht aus. Es sind halt echte Datenbanken.

Aber um dir dann wieder ein wenig Mut zu machen mit MYSQL liegst du meiner Meinung nach richtig nachdem du die DB-Struktur ein wenig beschrieben hast.

Automatismen dort einzubauen wie Sicherungen usw. sind auch relativ einfach trotzdem wirst du nicht darum herumkommen dir gute Lektüre zu holen oder zu besorgen ( dafür sollte der Arbeitgeber ein paar Euro über haben ) wo du dich einlesen solltest. Immerhin bietet dir MYSQL eine Menge Möglichkeiten wo du Performance herausholen kannst die Access dir nicht bietet, bzw. nicht bieten kann, da Access einfach keine DB ist sondern einfach nur ein Excel mit netter Oberfläche ( auch wenn ich dafür gesteinigt werden sollte )
Access ist halt nicht aktiv das ist das Problem. ;o) diplomatisch ausgedrückt.

Trotzdem wünsche Ich dir viel Spaß mit der neuen Aufgabe.

Gruß

Sven

Hallo Claude,


Also ich hatte ja Sven nicht gesteinigt als er Access als besseres Excel bezeichnet hat. Die (red) Jet Engine ist Multiuser-tauglich...es kommt eben darauf an welche Transaktionen und Operationen stattfinden. Nichtsdestotrotz ist es eher als (Engine) für Desktopdatenbanken optimal einzusetzen.

Einzelne ODBC-Einstellungen würden das ganze Problem nicht beseitigen.


Grundlegend wie bereits geschrieben: Ja. Andererseits können diese Performanceeinbußen schlichtweg auch durch schlechte suboptimale SQL-Abfragen, ggfls. auch schon durch die Datenstrukturen hervorgerufen werden. Das will ich Dir nicht unterstellen, aber wir kennen weder diese Datenstrukturen, noch die SQL-Transaktionen/Abfragen die von der web-Applikation (Client-seitig) abgesetzt werden.

Beschreibe doch einmal wie sich eure Web-Applikation mit der/den Access DB(´s) connected, und welche Daten übertragen werden.


Und wie steht es mit eurer Internetanbindung? Wenn dort euer Uploadkanal zu wenig Bandbreite bereitstellt ist das natürlich auch ein mögliches Problem.


wäre auch interessant worum es sich bei diesen Log-Daten handelt.

BG, Felix -misterdemeanor-

Woooow!

Grüß Dich Claude,

da haben wir es doch schon. Dieses SQL-Statement macht mir Angst. Das ist das problemverursachende an der ganzen Geschichte.

Gehe ich richtig in der Annahme das es sich bei dem Internetportal ebenfalls "nur" um ein Access-FE handelt? Sprich das Formular welches Du als erstes Image eingefügt hattest jedem externen zu Verfügung steht und Er/Sie dort bunt herum werkeln kann?

Und das
als RowSource für das Formular(Image1) dient? Bzw. was hat es mit den Felder [KWx] auf sich, das auf diese inm Statement geprüft wird?

Magst Du mir mal das FE (ohne Daten) mal via eMail schicken? Adresse würdest Du in meinem Profil finden.

BG, Felix -misterdemeanor-

Ah, OK.


Ja, mit sehr vielen unnötigen (VBA) Funktionen. Auch gegen eine (z.B.) MySQL, bzw. insbesondere dann, würde solch eine Abfrage enorm schwächeln.


Definitiv.


FE = Front End. Also das womit der InternetUser arbeitet.

Hi Claude,

nur Info, Access schwächelt überall da wenn mehrere User auf ein Select zugreifen der ein gewisse Logik enthält. Der letzte Select hat einiges an Logik drin. ( Funktionen )
Diese Selects werden auf Access nie performant laufen das kannst du knicken. Das ist halt das schon weiter oben erwähnte Problem das Access kein DBMS hat und eigentlich intern nur tabellen mit einträgen durchsucht. Am besten macht man sich klar das access zwar eine riesen funktionsvielfalt hat aber ncihts anderes als einen quicksort oder einen gruppenwechsel auf exceltabellen macht.

Wenn nun noch Logiken dazukommen überfordert man es. Oder noch besser evtl. subselects. Damit haust du Access komplett um.
Euch wird nichts anderes über bleiben als über kurz oder lang auf eine "echte" DB umzusteigen.


Gruß

Sven

ich rede nur über die performance. Sicher kann access auch verschachtelte Select und Subselects und und und. Aber es wird dann halt extrem langsam. Das ist halt das wie schon erwähnte fehlende DBMS. Es hat einfach nicht die technischen vorraussetzungen solche anfragemengen vernünftig zu verwalten. Mehr wollte ich nicht sagen.

Ich selbst arbeite für Desktopanwendungen mit Access. Da brauche ich keine Ora oder MSSQL DB. Da würde ich dann genau die andere Richtung von dir im Moment einschlagen. ;o)

Access hat schon seine Darseinsberechtigung aber nciht mehr in dem Bereich wo du es einsetzt.


Gruß

Sven

Kenne das Problem. Hatte mal eine ähnlich Situation das eine kleinere Anwendung auf einmal zu einem Client Server System mutieren sollte. Problem ist das die Software natürlich ausgestiegen ist weil Sie in keinster Weise dafür ausgelegt war. Wenn du dann jemanden hast der in keinster Weise die technischen Hintergründe versteht oder verstehen will hast du echt erklärungsnot. Aber das scheint ja bei euch nicht der Fall zu sein.

Sieh zu das ihr auf MYSQL umsteigt und du wirst dich wundern wie performant dein System wird. Ich meine es zeugt schon davon das du einiges von der Materie verstehst da dein Access ja die Anforderungen schafft, wenn auch langsam.
Aber nur um mal zu zeigen das ich es ernst meine, Ich denke nicht das ich dein Access bei den Zugriffen performanter machen könnte. evtl. durch den ein oder anderen Kniff aber sicher bin ich mir da nicht.

Gruß

Sven Guenter

Hi Claude,

nun habe ich mir mal den Code des FE´s angeschaut...

Auch wenn ich nicht so recht mit ASP vertraut bin, mit VBScript zwar schon, aber was Dir das CodeCharge Studio Dir da zurecht gebastelt hat...man mann mannn

11.000 Zeilen für solch eine kleine Anwendung, Hammer! Sicher bin ich noch keines Wegs wirklich durchgestiegen, aber 2-3 Dinge sind mir bisher aufgefallen:

• Du verwendest als Connection String eine DSN. Das führt dazu (zumindest im generierten Code) das der ODBC Treiber verwendet wird, auch wenn Du in der DSN den Jet-OLEDB Treiber angegeben hast. Also in CodeCharge einen Connection String- Builden damit auf jeden Fall der Jet-OLEDB Treiber verwendet wird.

Edit Link war falsch, hier der Snapshot des Dialoges

• Im selben Config-Dialog existiert die LIMIT/TOP Option. Die würde ich auch nicht aktivieren. Jetzt bin ich mir nicht 100% sicher, aber ich vermute das der zu jedem SELECT TOPxxx gehörige SELECT COUNT(*) aus diesem Grunde mitausgeführt wird. unnötig und Performance-Killer. Hier mal ein Beispiel aus dem ASP-Code:

Habe jetzt mal dieses SELECT genommen weil mir noch immer nicht klar wurde wieso mehrere Kalenderwochen...? Dann würde ich zumindest eine ComboBox zur Auswahl einer KW implementieren, was insbesondere bei anderen SELECT´s die WHERE-Klauseln enorm verkleinern.

Nunja, wenn ich Zeit habe vertiefe ich mich in den Code, aber wirklich: 11000 Zeilen. Ein Klasse Beispiel dafür das auch mit VB-Script relativ objektorientiert proggen kann

BG, Felix -misterdemeanor-

Hi Claude,


Jepp. Es ist wirklich ein sehr nettes Tool dieses CodeCharge Studio. Im Grunde genommen werden (u.a.) ADO Objekte gekapselt. Sprich Connection, Command, Recordset,...
Und dazu kommen dann noch ein paar Klassen die Daten parsen, auf Besonderheiten verschiedner SQL-Dialekte eingehen, ASP-Controls Kapseln, etc etc
Dies wird teilweise recht tief spezialisiert, sodass gar einige Aspekte der Vererbung simuliert werden. Wirlich sehr beeindruckend.


Jein. Das wird in der Kapselung des Grids vorgenommen. Wie gesagt wird ein ADODB.Recordset gekapselt: z.B.
(clsDBSchichtplanDB.Execute)-->clsDataSource-->clsSPlanTblDataSource-->clsSPlanTbl_Kalender1DataSource

Aber hier wird mir eher ersichtlich wozu diese SELECT Count(*)´s dienen: (Auszug aus der Classes.ASP in der Klasse clsCommand, ab Zeile 3241)

Hier dient es also dazu: SELECT TOP {alle=SELECT Count(*)}, also absoluter Schwachsinn.
Der Member mPageSize ist in diesem Zusammenhang eine Kapselung der ADODB.Recordset.PageSize Property und wird an anderer Stelle gesetzt. Diese TOP-Option ist die im vorigen Post (siehe das Image) erwähnte LIMIT/TOP-Option.
Ich würde dies einfach mal deaktivieren.

Nunja, setze "einfach" einen MySQL-Server auf *rofl Dann wird sich Dein Problem schon irgendwie aufheben.

Hallo zusammen,

als Access-Programmierer der ersten Stunde möchte ich noch ein bißchen steinigen...

Access ist alles andere, aber kein "besseres Excel". Richtig ist, daß die ersten Versionen von Access mehr eine bessere Listenverwaltung als eine Datenbank waren. Die Jet-Engine wurde damals von vielen belächelt und nicht für ernst genommen.
Parallel dazu existierte eine kleine Firma namens "Fox Software", die die damals schnellste (DOS-, später Windows-)PC-Datenbank "FoxPro" herausgebracht hat, eine echte RDB-Maschine. Access hat daneben extrem alt ausgesehen, Microsoft hat mit Access im Gegensatz zu anderen Office-Produkten kein Bein auf die Erde bekommen. Also macht man das, was man schon immer am besten gemacht hat: Man kauft die Firma auf. Und so wurde aus "FoxPro" dann "Visual FoxPro", das Microsoft zwar immer noch aufrechterhält, aber nie wirklich groß bewirbt oder erwähnt.
Kein Wunder: Die sogenannte "Rushmore"-Technologie, auf der FoxPro beruhte, wurde komplett in Access eingebaut und damit wurde Access ab diesem Zeitpunkt zu einer echten Datenbank. Allerdings hat es sein Image irgendwie nie losgekriegt, es wird in der IT-Branche immer noch als Spielzeug belächelt. Ist es aber definitiv nicht mehr. Mir ist zum Beispiel keine andere Datenbank bekannt, mit der ich so schnell und einfach eine Datenbank erstellen kann, die schnell und einfach funktioniert, mit Benutzeroberfläche und Reporting. Die diversen SQL-Server haben zwar heute alle bessere Möglichkeiten, aber es mangelt eigentlich allen an Einfachheit in der Verwendung und Erstellung, und Benutzeroberflächen kann man mit keiner vernünftig erstellen. Hier besinnt man sich dann gerne auf Access und benutzt dann eben ODBC.
Access hat eigentlich nur zwei wesentliche Nachteile: Die Begrenzung einer Datenbankdatei auf 2 GB und die Tatsache, daß ALLES in EINE Datei abgelegt wird (bei FoxPro etwa wurden Masken, Daten, Reports usw. immer in getrennten Dateien abgelegt).
Geschwindigkeit: Access ist höllenschnell, wenn man die simplen Optimierungstricks aus der MS-Hilfe beachtet. Etwa: Abfragen vordefinieren und nur den Abfragenamen in Feldern eintragen und nicht direkt den SQL-Befehl.
Und wenn ich mir so einen Höllen-SQL-Befehl wie oben ansehe, wundert mich auch nichts. Wenn man einen SQL-Befehl mit lauter Funktionen vollstopft, wird das auch bei anderen Datenbanken zu Performance-Einbußen führen.
Und multiuserfähig ist es ebenfalls, wenn man Frontend und Backend richtig plant, so daß selbst bei 100 gleichzeitigen Verwendern kaum Performanceeinbußen zu bemerken sind (was für eine Online-Anwendung natürlich nicht genug ist).

Thema MySQL: Auch hier habe ich oft den Eindruck, daß die Datenbank so ein bißchen als "Spielzeug für Webentwickler" verschrieen ist. Wenn man sich mal die Entwicklungsgeschichte von MySQL anschaut: Der Grund für die Entstehung war ein Auftrag einer großen Firma, eine replizierbare Datenbank zu erstellen einer erheblichen Größe auf verteilten Servern. Daraus wurde später dann das OpenSource-Produkt "MySQL". Soll heißen: Die Datenbank wurde mit einem extrem professionellen Hintergrund erschaffen für eine extrem professionelle Anwendung, die die meisten Leute nie benötigen werden. Es ist also kein Kinderspielzeug, sondern kann anderen SQL-Servern bequem das Wasser reichen. Gerade die perfekte Zusammenarbeit mit PHP macht die Datenbank für Online-Aufgaben höchst interessant und da ist auch der SQL-Server von Microsoft noch sehr entfernt. Dieser hat dafür wieder perfekte Fähigkeiten in Sachen Reporting, Datamining usw., die aber oftmals für Online-Anwendungen nicht so interessant sind.

Ach ja, @Claude: Access 2003 ist zwar bisher eine der besten Versionen von Access und ich arbeite auch sehr gerne damit, aber angesichts der Tatsache, das Access 2007 schon ein ganzes Jahr existiert und stabil läuft, warum nicht gleich hier einsteigen? Du mußt lediglich ein bißchen Umgewöhnungsarbeit leisten bei der komplett neuen Benutzeroberfläche, an die man sich aber schnell gewöhnt. Eindeutiger Vorteil von Access 2007 gegenüber seinen Vorgängerversionen: Eine Runtime wird gleich mitgeliefert und man kann lauffähige Standalone-Datenbanken an die Anwender verteilen, ohne daß diese Access lizenzieren müßten. Das war bislang nur mit den teureren Developer Editions möglich. Somit ist man nicht mehr auf unterschiedlichste Installationsversionen beim Anwender (und den damit verbundenen Problemen) angewiesen, sondern kann jeden mit der gleichen Runtime versorgen, die dann alles beinhaltet, was die Anwendung benötigt.

Gruß

Christian

Hallo Claude,

ob an der Jet Engine etwas verbessert wurde, weiß ich nicht (kann man aber sicher in den MS-Seiten nachsehen). Auf jeden Fall verwendet Access 2007 wieder ein neues Datenbankdateiformat und es wurde eine Menge an der Oberfläche geändert.

Und das Thema "hier wird überall 2003 verwendet" ist ja gerade das gute bei 2007: Es ist egal, was die Anderen verwenden, da Du ja mit der Datenbank zusammen auf den Zielrechnern die Runtime installieren kannst. Das bedeutet: Keiner der User hat mehr auch nur geringfügig abweichende Versionen und kein User kann an der Datenbank selbst herumfummeln (was so ja auch ohne Probleme möglich ist). Da das Datenbankformat auch neu ist, kann der User nicht mal die Datenbank in eine ältere Access-Version einlesen, um dort etwas zu ändern. Macht den Support um einiges leichter.
Bei einem Kunden habe ich schon erlebt, das an x Stellen x Access-Versionen eingesetzt wurden, teilweise auch noch mit unterschiedlichen Einstellungen zu den Verweisen etc. Ergebnis war, daß sie dann x verschiedene Frontends angepaßt haben, damit das Ding dann auch auf jedem System läuft. Und wenn es ein Frontend mit neuen Access-Funktionen gab, konnten die älteren Access-Versionen nur noch die älteren Frontends benutzen... Chaos-EDV.

Mit 2007 hast Du eine Vollversion (und damit auch nur die Kosten für eine Vollversion, nämlich beim Entwickler) und alle User bekommen nur noch die Runtime-Version, die keine Lizenzkosten verursacht.

Gruß

Christian