46
Access als Frontend für MYSQL?
Wir haben in der Firma ein ausgereifte MS-Access97 Anwendung. Über das Internet greifen auch externe Mitarbeiter zu (ASP / ODBC). Klappt gut, nur momentan haben wir Performance Probleme, da Stundenweise über 1000 Zugriffe von extern notwendig sind.
Hallo,
Die Frage ist, ob es sinnvoll wäre, die Tabellen (Backend) anstatt in Access in eine MySQL-Datenbank zu legen.
Kann ich dann über Access direkt auf diese Tabellen zugreifen? (also Frontend in Access) Oder geht das nur über ODBC?
Problem ist das intern maximal 5 Mitarbeiter gleichzeitig über Access in der Datenbank arbeiten, aber extern (wenn das "Internet Portal" geöffnet wird) zeitweise bis zu 100 Mitarbeiter gleichzeitig zugreifen. Also muss die Geschwindigkeit nach aussen schneller sein als intern.
Problem ist auch, das wir in der jetzigen Konfiguration keine Trigger nutzen können, und für alle Datenzugriffe eine entsprechende Abfrage in Access existieren muss.
Hinweis: Die Access-Datenbank ist wiederum mit unseren ERP-System (auch über ODBC), und andere Access-Datenbanken verbunden, deshalb möchten wir auch Access als Frontend für die interne Applikation belassen (...ist relativ komplex und umfangreich ...aber stabil)
Weiterer Hinweis: Auf Knopfdruck werden die Daten für die Internet-Applikation aufbereitet, dann automatisch SMS an die alle externe Mitarbeiter gesendet, um diese über die Öffnung des Internetportals zu informieren. Danach können sich die externe Mitarbeiter im Schichtplan selber eintragen. Dabei müssen viele Sachen berücksichtigt werden: Haben die Mitarbeiter noch offene Stunden? Liegt zwischen den belegten Schichten mindestens 11 Stunden? Ist der Mitarbeiter für diesen Arbeitsplatz gesperrt? usw....
Wie gesagt.... funktionniert gut, nur in der Stosszeit dauert bei den externen das Einloggen mehrere Minuten, was letztes Jahr noch kein Problem war, als die Anzahl der externen Mitarbeiter nur ca 40 war.
Bitte um Ideen, Ratschläge,....
Vielen Dank
mfG
Claude
Nachtrag: Hier 2 Bilder über Datenstruktur:
Tabelle [SPlanTbl] (Haupttabelle)
Tabelle [SPlanTbl_ExtMitarbeiter] externe Mitarbeiter mit Logindaten,....
Nachtrag: Hier ein Einblick (Auszug aus unserer Dokumentation), wie die WebApplication zu bedienen ist.
Hallo,
Die Frage ist, ob es sinnvoll wäre, die Tabellen (Backend) anstatt in Access in eine MySQL-Datenbank zu legen.
Kann ich dann über Access direkt auf diese Tabellen zugreifen? (also Frontend in Access) Oder geht das nur über ODBC?
Problem ist das intern maximal 5 Mitarbeiter gleichzeitig über Access in der Datenbank arbeiten, aber extern (wenn das "Internet Portal" geöffnet wird) zeitweise bis zu 100 Mitarbeiter gleichzeitig zugreifen. Also muss die Geschwindigkeit nach aussen schneller sein als intern.
Problem ist auch, das wir in der jetzigen Konfiguration keine Trigger nutzen können, und für alle Datenzugriffe eine entsprechende Abfrage in Access existieren muss.
Hinweis: Die Access-Datenbank ist wiederum mit unseren ERP-System (auch über ODBC), und andere Access-Datenbanken verbunden, deshalb möchten wir auch Access als Frontend für die interne Applikation belassen (...ist relativ komplex und umfangreich ...aber stabil)
Weiterer Hinweis: Auf Knopfdruck werden die Daten für die Internet-Applikation aufbereitet, dann automatisch SMS an die alle externe Mitarbeiter gesendet, um diese über die Öffnung des Internetportals zu informieren. Danach können sich die externe Mitarbeiter im Schichtplan selber eintragen. Dabei müssen viele Sachen berücksichtigt werden: Haben die Mitarbeiter noch offene Stunden? Liegt zwischen den belegten Schichten mindestens 11 Stunden? Ist der Mitarbeiter für diesen Arbeitsplatz gesperrt? usw....
Wie gesagt.... funktionniert gut, nur in der Stosszeit dauert bei den externen das Einloggen mehrere Minuten, was letztes Jahr noch kein Problem war, als die Anzahl der externen Mitarbeiter nur ca 40 war.
Bitte um Ideen, Ratschläge,....
Vielen Dank
mfG
Claude
Nachtrag: Hier 2 Bilder über Datenstruktur:
Tabelle [SPlanTbl] (Haupttabelle)
Tabelle [SPlanTbl_ExtMitarbeiter] externe Mitarbeiter mit Logindaten,....
Nachtrag: Hier ein Einblick (Auszug aus unserer Dokumentation), wie die WebApplication zu bedienen ist.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82335
Url: https://administrator.de/forum/access-als-frontend-fuer-mysql-82335.html
Ausgedruckt am: 31.12.2024 um 20:12 Uhr
46 Kommentare
Neuester Kommentar
Hallo Claude,
um eines direkt vorweg zu nehmen: Leider wird man Dir wahrscheinlich keinen wirklichen Ratschlag geben können.
DU hast ja bereits angedeutet das das "Ganze" relativ komplex ist.
Also bei 5 internen gleichzeitigen Zugriffen, auch mit relativ komplexen Aufgaben, kommt die Jet-Engine in aller Regel noch sehr gut klar. Kommen da aber noch 100 externe Verbindungen hinzu...hmm. Dann kommen unweigerlich Performance-Einbußen...
Wie Du jetzt direkt meinst ist mir nicht ganz klar *g. Für MySQL existieren "nur" ODBC Treiber. (Habe mal was von einem inoffiziellen ADO.Net Provider gelesen, hier aber ohnehin unrelevant)
Somit kannst Du also auf die Daten eines MySQL Backends zugreifen. Entweder eben direkt indem Du Tabelen verlinkst, importierst oder im Code über DAO/ADO.
"Geschwindigkeit". Also bei 100 synchronen Zugriffen sollte wirklich in Erwägung gezogen werden auf eine andere DB-Engine zu wechseln. Du ahnst sicher worauf mein gesamter Post hinausläuft...
Also bestehen wirklich bereits die Überlegungen vielleicht sogar das Gesamte Backend-System zu migrieren? So wie ich es einschätze ist das bei euch schon etwas umfangreicher. Daher auch nichts was mal soeben gemacht werden kann. Nicht nur aus zeittechnischen Gründen, wohl auch weil der Causa hier nicht nur das einzige Front-End ist.
Apropo Front-End: Du hattest mal in einem Deiner vorigen Beiträge erwähnt das bei den Front-Ends eine Portierung auf Access 2003 ein Thema bei euch war...
OK, wenn Ihr das Internetportal erst freischaltet...u.U. könnte man als Zwischenlösung die Stoßzeiten verhindern indem man einfach zu bestimmten Zeiten nur bestimmte Mitarbeiter überhaupt das einloggen ermöglicht. Also einfach verteilt. Eine ausgiebige Abfragenanalyse und Optimierung könnte vielleiht auch noch ein Quentchen mehr Leistung bringen (
Eigentlich kann ich nur auf meinen Eingangssatz verweisen^^^Wenn möglich würde ich wahrscheinlich so viel wie möglich in ein richtiges RDBMS migrieren und gleichzeitig die Front-Ends ebenfalls upTodate bringen. Mit den Überstunden finanzierst Du nebenbei noch gleich den Vierteljahr Urlaub auf Honduras oder wahlweise die Ausbildung Deines Erstgeborenen
Man müsste aber wirklich ausgiebig in der Umgebung analysieren um Dir echten Rat geben zu können. ACCESS 97 sollte aber wirklich aktualisiert werden. Hier mal zwei Links:
Neue Version der Microsoft Jet 3.5
Access und eingebundene ODBC-Tabellen
BG, Felix -misterdemeanor-
um eines direkt vorweg zu nehmen: Leider wird man Dir wahrscheinlich keinen wirklichen Ratschlag geben können.
DU hast ja bereits angedeutet das das "Ganze" relativ komplex ist.Die Frage ist, ob es sinnvoll wäre, die
Tabellen (Backend) anstatt in Access in eine
MySQL-Datenbank zu legen.
Tabellen (Backend) anstatt in Access in eine
MySQL-Datenbank zu legen.
Also bei 5 internen gleichzeitigen Zugriffen, auch mit relativ komplexen Aufgaben, kommt die Jet-Engine in aller Regel noch sehr gut klar. Kommen da aber noch 100 externe Verbindungen hinzu...hmm. Dann kommen unweigerlich Performance-Einbußen...
Kann ich dann über Access direkt auf
diese Tabellen zugreifen? (also Frontend in
Access) Oder geht das nur über ODBC?
diese Tabellen zugreifen? (also Frontend in
Access) Oder geht das nur über ODBC?
Wie Du jetzt direkt meinst ist mir nicht ganz klar *g. Für MySQL existieren "nur" ODBC Treiber. (Habe mal was von einem inoffiziellen ADO.Net Provider gelesen, hier aber ohnehin unrelevant)
Somit kannst Du also auf die Daten eines MySQL Backends zugreifen. Entweder eben direkt indem Du Tabelen verlinkst, importierst oder im Code über DAO/ADO.
Also muss die Geschwindigkeit nach aussen schneller sein als intern.
"Geschwindigkeit". Also bei 100 synchronen Zugriffen sollte wirklich in Erwägung gezogen werden auf eine andere DB-Engine zu wechseln. Du ahnst sicher worauf mein gesamter Post hinausläuft...
Problem ist auch, das wir in der jetzigen Konfiguration keine Trigger nutzen können,
Also bestehen wirklich bereits die Überlegungen vielleicht sogar das Gesamte Backend-System zu migrieren? So wie ich es einschätze ist das bei euch schon etwas umfangreicher. Daher auch nichts was mal soeben gemacht werden kann. Nicht nur aus zeittechnischen Gründen, wohl auch weil der Causa hier nicht nur das einzige Front-End ist.
Apropo Front-End: Du hattest mal in einem Deiner vorigen Beiträge erwähnt das bei den Front-Ends eine Portierung auf Access 2003 ein Thema bei euch war...
Weiterer Hinweis: Auf Knopfdruck werden die Daten für die Internet-Applikation aufbereitet,
dann automatisch SMS an die alle externe Mitarbeiter gesendet, um diese
über die Öffnung des Internetportals zu informieren.
dann automatisch SMS an die alle externe Mitarbeiter gesendet, um diese
über die Öffnung des Internetportals zu informieren.
OK, wenn Ihr das Internetportal erst freischaltet...u.U. könnte man als Zwischenlösung die Stoßzeiten verhindern indem man einfach zu bestimmten Zeiten nur bestimmte Mitarbeiter überhaupt das einloggen ermöglicht. Also einfach verteilt. Eine ausgiebige Abfragenanalyse und Optimierung könnte vielleiht auch noch ein Quentchen mehr Leistung bringen (
Eigentlich kann ich nur auf meinen Eingangssatz verweisen^^^Wenn möglich würde ich wahrscheinlich so viel wie möglich in ein richtiges RDBMS migrieren und gleichzeitig die Front-Ends ebenfalls upTodate bringen. Mit den Überstunden finanzierst Du nebenbei noch gleich den Vierteljahr Urlaub auf Honduras oder wahlweise die Ausbildung Deines Erstgeborenen
Man müsste aber wirklich ausgiebig in der Umgebung analysieren um Dir echten Rat geben zu können. ACCESS 97 sollte aber wirklich aktualisiert werden. Hier mal zwei Links:
Neue Version der Microsoft Jet 3.5
Access und eingebundene ODBC-Tabellen
BG, Felix -misterdemeanor-
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
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
Hallo Felix und Sven,
Zuerst mal vielen Dank für die Rückmeldungen.
1) Access 2003 wäre kein Problem, habe bereits Tests gemacht. Muss nur noch die Runtime fertigstellen. Problem ist das wir ca 15 Datenbanken per Runtime betreiben (und das verteilt auf 6 CITRIX Server), und ich müsste dann alle 15 DBs innerhalb 2-3 Tage konvertieren, testen, usw.. sonst haben wir eine Mischung zwischen AC97 und 2003. Ist aber in Planung, bzw alle Datenbanken sind bereits für die Konvertierung optimiert.
2) Ja, das war mein Gedanke: Alle Tabellen auf MYSQL portieren, und per ODBC über die Frontend für die "interne" Anwendung zugreifen. Für die Web-Application würden wir dann PHP einsetzen.
Weitere Infos folgen....
Nochmal veilen Dank
mfg
claude
Zuerst mal vielen Dank für die Rückmeldungen.
1) Access 2003 wäre kein Problem, habe bereits Tests gemacht. Muss nur noch die Runtime fertigstellen. Problem ist das wir ca 15 Datenbanken per Runtime betreiben (und das verteilt auf 6 CITRIX Server), und ich müsste dann alle 15 DBs innerhalb 2-3 Tage konvertieren, testen, usw.. sonst haben wir eine Mischung zwischen AC97 und 2003. Ist aber in Planung, bzw alle Datenbanken sind bereits für die Konvertierung optimiert.
2) Ja, das war mein Gedanke: Alle Tabellen auf MYSQL portieren, und per ODBC über die Frontend für die "interne" Anwendung zugreifen. Für die Web-Application würden wir dann PHP einsetzen.
Weitere Infos folgen....
Nochmal veilen Dank
mfg
claude
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
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.
Problem ist das wir ca 15 Datenbanken per Runtime betreiben
Also 15 verschiedene Front-Ends, respektive Anwendungen? Woow.
2) Ja, das war mein Gedanke: Alle Tabellen
auf MYSQL portieren,
auf MYSQL portieren,
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.
und per ODBC über
die Frontend für die "interne"
Anwendung zugreifen. Für die
Web-Application würden wir dann PHP
einsetzen.
die Frontend für die "interne"
Anwendung zugreifen. Für die
Web-Application würden wir dann PHP
einsetzen.
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.
Hallo Sven, Danke.
Tabellen über ODBC zu verknüpfen ist kein Thema, das machen wir bereits mit den Tabellen von unserem ERP System, der auf Oracle liegt.
ABER: Wie krieg ich am einfachsten die Tabellen einmalig nach MYSQL: Gibst's da auch wie beim SQL-Server ein Migrationstool für Access? (das hatte ich mal getestet, hat gut geklappt)
Komprimierung: Habe eine selbst erstellte Datenbank, die alle andere Datenbanken Nachts aufruft und komprimiert. Vollautomatisch. Wenn die Datenbanken benutzt werden, versucht es die DB alle 15 Minuten wieder, bis alle DBs komprimiert sind.
Gruss
claude
Tabellen über ODBC zu verknüpfen ist kein Thema, das machen wir bereits mit den Tabellen von unserem ERP System, der auf Oracle liegt.
ABER: Wie krieg ich am einfachsten die Tabellen einmalig nach MYSQL: Gibst's da auch wie beim SQL-Server ein Migrationstool für Access? (das hatte ich mal getestet, hat gut geklappt)
Komprimierung: Habe eine selbst erstellte Datenbank, die alle andere Datenbanken Nachts aufruft und komprimiert. Vollautomatisch. Wenn die Datenbanken benutzt werden, versucht es die DB alle 15 Minuten wieder, bis alle DBs komprimiert sind.
Gruss
claude
Gibst's da
Also da kann ich Dir das von MySQL selbst empfehlen:MySQL Migration Toolkit
Es gibt auch ein nettes Video Tuturial dazu.
auch wie beim SQL-Server ein Migrationstool
für Access? (das hatte ich mal getestet,
hat gut geklappt)
für Access? (das hatte ich mal getestet,
hat gut geklappt)
Also da kann ich Dir das von MySQL selbst empfehlen:MySQL Migration Toolkit
Es gibt auch ein nettes Video Tuturial dazu.
Hi,
Gruss
claude
Also 15 verschiedene Front-Ends, respektive Anwendungen? Woow.
Ja, verschiedene Anwendungen: Schichtplan, Besucherprogramm, LKW-Logistik, FMEA, Reklamationen, IT-Hotline, KVP, Instandhaltung, usw....Worauf ich hier hinauswollte: Verwendet
in eurer PHP-Application besser ADO als
direkte Kommunikation mit einem SQL-Server.
Also wenn ich richtig verstehe: Besser wäre ein SQL-Server als MySql?in eurer PHP-Application besser ADO als
direkte Kommunikation mit einem SQL-Server.
Gruss
claude
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-
Also wenn ich richtig verstehe: Besser
wäre ein SQL-Server als MySql?
wäre ein SQL-Server als MySql?
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
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
Hallo Felix,
Danke für die Hinweise. Gerade weil es "viele" Möglichkeiten gibt, ist es mir wichtig auch solche Themen wie ADO zu erwähnen, damit wir die richtige Entscheidung treffen können.
Und das Thema "Internetportal" zeitlich aufzuteilen geht leider auch nicht, denn die ersten Mitarbeiter würden sich die besten Schichten krallen, und die weiteren Mitarbeiter müssten sich dann mit dem Rest zufrieden geben. Aber technisch wäre es realisierbar.
G Claude
Danke für die Hinweise. Gerade weil es "viele" Möglichkeiten gibt, ist es mir wichtig auch solche Themen wie ADO zu erwähnen, damit wir die richtige Entscheidung treffen können.
Und das Thema "Internetportal" zeitlich aufzuteilen geht leider auch nicht, denn die ersten Mitarbeiter würden sich die besten Schichten krallen, und die weiteren Mitarbeiter müssten sich dann mit dem Rest zufrieden geben. Aber technisch wäre es realisierbar.
G Claude
Und das Thema "Internetportal"
zeitlich aufzuteilen geht leider auch nicht,
denn die ersten Mitarbeiter würden sich
die besten Schichten krallen,
zeitlich aufzuteilen geht leider auch nicht,
denn die ersten Mitarbeiter würden sich
die besten Schichten krallen,
BOFH Mode ON
Dann empfehle ich eine ständig erreichbare Startseite mit einem Verweis auf Dein Spenden-Konto in Luxemburg
BOFH Mode OFF
Hallo Sven,
Es sind Tabellen ohne Referenzen. Also relativ einfache, kompakte Tabellen.
Also der Vorteil von Access und der Web-Application die wir momentan haben, ist der geringe Administrationsaufwand. Ich betreibe meine 15 DBs nebenbei (bin eigentlich gar nicht bei IT angesiedelt ...aber das ist eine lange Geschichte...)
Daher möchte ich jetzt nicht irgendwas installieren, und mich dann dannach jeden Tag 2-3 Stunden darum kümmern müssen.
Bei den meisten der 15 DBs muss ich Monate lang gar nix machen (Komprimierung automatisch, Sicherung automatisch .... Workflow nur bei Fehler,...), das ganze lauft relativ stabil (trotz Access97 .... ich werde von unseren ITler immer angemacht: Access ist doch keine Datenbank)
Also ich denke auch, das MySQL hier ein gute Wahl ist. Wie gesagt: Diese Stosszeit ist nur einmal pro Woche (...da tragen sich die externen für die kommende Woche ein), und dauert 1-2 Stunden .... gerade weil jeder die beste Schicht will.
Gruss Claude
Es sind Tabellen ohne Referenzen. Also relativ einfache, kompakte Tabellen.
Also der Vorteil von Access und der Web-Application die wir momentan haben, ist der geringe Administrationsaufwand. Ich betreibe meine 15 DBs nebenbei (bin eigentlich gar nicht bei IT angesiedelt ...aber das ist eine lange Geschichte...)
Daher möchte ich jetzt nicht irgendwas installieren, und mich dann dannach jeden Tag 2-3 Stunden darum kümmern müssen.
Bei den meisten der 15 DBs muss ich Monate lang gar nix machen (Komprimierung automatisch, Sicherung automatisch .... Workflow nur bei Fehler,...), das ganze lauft relativ stabil (trotz Access97 .... ich werde von unseren ITler immer angemacht: Access ist doch keine Datenbank)
Also ich denke auch, das MySQL hier ein gute Wahl ist. Wie gesagt: Diese Stosszeit ist nur einmal pro Woche (...da tragen sich die externen für die kommende Woche ein), und dauert 1-2 Stunden .... gerade weil jeder die beste Schicht will.
Gruss Claude
Dann empfehle ich eine ständig erreichbare Startseite mit einem Verweis auf Dein Spenden-Konto in Luxemburg
Ist da Lichtenstein nicht besser?
Ist da Lichtenstein nicht besser?
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
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
Heute Nachmittag war es wieder so weit: Öffnung des Internetportals:
Kurz davor dauerte die Anmeldung ca 2-3 Sekunden. Als ca 50 externe bereits eingeloggt waren, dauerte eine erneute Anmeldung bis zu 10 Minuten.
Nach 2 Stunden war der Spuk vorbei, alle Plätze wurden belegt, und das Logfile in der Access-Datenbank um einige Tausend Einträge länger (Die Web Application schreibt in eine Accesstabelle zurück .... wichtig für unsere Analyse, kostet aber natürlich auch Ressourcen)
Dabei haben wir folgende Sachen überwacht:
- CPU auslastung, auf dem Webserver (der Webserver läuft auf einer VM auf einem IIS Server mit 4 CPUs): CPU-Auslastung schwankte um die 50% ...also OK
- Netztwerk Auslastung auf dem Webserver (zum Fileserver, auf dem die Datenbank liegt): Unterhalb von 10%
Ist die Schlussfolgerung dann richtig, dass es nur noch an der ODBC-Verbindung, oder direkt an der Jet Engine liegt?
Wenn ja, in wie fern kann man den ODBC Treiber optimieren? Bzw welche sind in diesem Fall die besten Einstellungen?
ExtendedAnsiSQL, MaxBufferSize, MaxScanRows, PageTimeOut, SafeTransactions, Threads, UseCommutSync?
Oder ist eure Meinung eher: Finger davon lassen, und auf MySQL portieren?
Gruss
Claude
Kurz davor dauerte die Anmeldung ca 2-3 Sekunden. Als ca 50 externe bereits eingeloggt waren, dauerte eine erneute Anmeldung bis zu 10 Minuten.
Nach 2 Stunden war der Spuk vorbei, alle Plätze wurden belegt, und das Logfile in der Access-Datenbank um einige Tausend Einträge länger (Die Web Application schreibt in eine Accesstabelle zurück .... wichtig für unsere Analyse, kostet aber natürlich auch Ressourcen)
Dabei haben wir folgende Sachen überwacht:
- CPU auslastung, auf dem Webserver (der Webserver läuft auf einer VM auf einem IIS Server mit 4 CPUs): CPU-Auslastung schwankte um die 50% ...also OK
- Netztwerk Auslastung auf dem Webserver (zum Fileserver, auf dem die Datenbank liegt): Unterhalb von 10%
Ist die Schlussfolgerung dann richtig, dass es nur noch an der ODBC-Verbindung, oder direkt an der Jet Engine liegt?
Wenn ja, in wie fern kann man den ODBC Treiber optimieren? Bzw welche sind in diesem Fall die besten Einstellungen?
ExtendedAnsiSQL, MaxBufferSize, MaxScanRows, PageTimeOut, SafeTransactions, Threads, UseCommutSync?
Oder ist eure Meinung eher: Finger davon lassen, und auf MySQL portieren?
Gruss
Claude
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-
Ist die Schlussfolgerung dann richtig, dass es nur noch an der ODBC-Verbindung, oder direkt an der Jet Engine liegt?
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.
Oder ist eure Meinung eher: Finger davon lassen, und auf MySQL portieren?
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.
- Netztwerk Auslastung auf dem Webserver (zum Fileserver, auf dem die Datenbank liegt): Unterhalb von 10%
Und wie steht es mit eurer Internetanbindung? Wenn dort euer Uploadkanal zu wenig Bandbreite bereitstellt ist das natürlich auch ein mögliches Problem.
und das Logfile in der Access-Datenbank um einige Tausend Einträge länger (Die Web Application schreibt in eine Accesstabelle zurück .... wichtig für unsere Analyse, kostet aber natürlich auch Ressourcen)
wäre auch interessant worum es sich bei diesen Log-Daten handelt.
BG, Felix -misterdemeanor-
Hallo, Hier mal das Logfile (kurzer Auszug). Ist eine Access Tabelle mit 4 Felder:
Datum Loginamen Aktion UID
05.03.2008 15:35:28 Potapenja, Nadine Login 15490
05.03.2008 15:35:20 Mecker, Elena Jahr:2008; KW:10; Linie:2; Schicht:F; Tag:SA; x1 15489
05.03.2008 15:35:10 Ilik, Fatma Login 15488
05.03.2008 15:34:36 Rjabow, Marina Login 15487
05.03.2008 15:34:31 Potapenja, Nadine Login 15486
05.03.2008 15:34:29 Bakalo, Aljona Login 15485
05.03.2008 15:34:04 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DI; X_DI244012 15474
05.03.2008 15:33:44 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:MO; X_MO244012 15472
05.03.2008 15:33:35 Mikuzys, Ingrid Login 15484
05.03.2008 15:33:30 Ilik, Fatma Login 15482
05.03.2008 15:33:30 Svoboda, Stephanie Login 15483
05.03.2008 15:33:24 Rjabow, Marina Login 15481
05.03.2008 15:33:24 Wulfert, Maike Login 15480
05.03.2008 15:33:20 Grupp, Margit Login 15478
05.03.2008 15:33:20 Wamsler, Petra Login 15479
05.03.2008 15:32:32 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DO; X_DO244012 15469
05.03.2008 15:32:17 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:SV; x2 15465
05.03.2008 15:32:04 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:MI; X_MI244012 15463
05.03.2008 15:31:45 Greve, Samuel Login 15477
05.03.2008 15:30:30 Euteneier, Regin Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; x2 15462
05.03.2008 15:30:18 Euteneier, Regin Login 15461
05.03.2008 15:29:52 Deutsch, Michael Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:MI; X_MI243991 15460
05.03.2008 15:29:49 Gross, Larissa Login 15476
05.03.2008 15:29:31 Rjabow, Marina Login 15475
05.03.2008 15:29:11 Deutsch, Michael Login 15458
05.03.2008 15:28:57 Schaaf, Jürgen Login 15473
05.03.2008 15:28:51 Kassumov, Marina Login 15471
05.03.2008 15:28:32 Bryzgunova, Antonina Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:DI; X_DI243991 15456
05.03.2008 15:28:18 Bryzgunova, Antonina Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:MO; x2 15454
05.03.2008 15:28:09 Mecker, Elena Jahr:2008; KW:10; Linie:2; Schicht:F; Tag:SA; x1 15470
05.03.2008 15:27:54 Bryzgunova, Antonina Login 15452
05.03.2008 15:27:45 Bryzgunova, Antonina Login 15450
05.03.2008 15:27:45 Mayer, Dominic Login 15451
05.03.2008 15:27:37 Bryzgunova, Antonina Login 15449
05.03.2008 15:27:35 Mikuzys, Ingrid Jahr:2008; KW:11; Linie:1; Schicht:N; Tag:SV; x1 15468
05.03.2008 15:27:34 Spreier, Claudia Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:SV; x1 15467
05.03.2008 15:27:26 Wulfert, Maike Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DO; X_DO244012 15466
05.03.2008 15:27:20 Belik, Elena Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; x2 15464
05.03.2008 15:25:02 Möller, Ralph Login 15459
05.03.2008 15:23:44 Spreier, Claudia Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:SV; x1 15457
05.03.2008 15:23:41 Wulfert, Maike Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; X_DI244000 15455
05.03.2008 15:23:09 Deines, Swetlana Jahr:2008; KW:11; Linie:2; Schicht:S; Tag:MO; x1 15453
05.03.2008 15:22:49 Mikuzys, Ingrid Login 15448
05.03.2008 15:21:50 Graf, Ella Login 15447
05.03.2008 15:21:46 Mikuzys, Ingrid Login 15446
05.03.2008 15:21:44 Dronov, Marina Login 15445
05.03.2008 15:21:44 Mikuzys, Ingrid Login 15444
05.03.2008 15:21:30 Belik, Elena Login 15443
05.03.2008 15:21:21 Marfin, Schanna Login 15442
05.03.2008 15:21:13 GIM PortalOeffnung SMS an [SMS:016091377273] Möller, Ralph 15439
05.03.2008 15:21:13 GIM PortalOeffnung eMail intern 15441
Anmerkung: Namen wurden geändert
Anmerkung2: Einträge mit GIM bezeichnen die lokale Anwendung (GIM ist der Name der Datenbank)
Infos zur Datenstruktur folgen
Datum Loginamen Aktion UID
05.03.2008 15:35:28 Potapenja, Nadine Login 15490
05.03.2008 15:35:20 Mecker, Elena Jahr:2008; KW:10; Linie:2; Schicht:F; Tag:SA; x1 15489
05.03.2008 15:35:10 Ilik, Fatma Login 15488
05.03.2008 15:34:36 Rjabow, Marina Login 15487
05.03.2008 15:34:31 Potapenja, Nadine Login 15486
05.03.2008 15:34:29 Bakalo, Aljona Login 15485
05.03.2008 15:34:04 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DI; X_DI244012 15474
05.03.2008 15:33:44 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:MO; X_MO244012 15472
05.03.2008 15:33:35 Mikuzys, Ingrid Login 15484
05.03.2008 15:33:30 Ilik, Fatma Login 15482
05.03.2008 15:33:30 Svoboda, Stephanie Login 15483
05.03.2008 15:33:24 Rjabow, Marina Login 15481
05.03.2008 15:33:24 Wulfert, Maike Login 15480
05.03.2008 15:33:20 Grupp, Margit Login 15478
05.03.2008 15:33:20 Wamsler, Petra Login 15479
05.03.2008 15:32:32 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DO; X_DO244012 15469
05.03.2008 15:32:17 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:SV; x2 15465
05.03.2008 15:32:04 Euteneier, Regin Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:MI; X_MI244012 15463
05.03.2008 15:31:45 Greve, Samuel Login 15477
05.03.2008 15:30:30 Euteneier, Regin Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; x2 15462
05.03.2008 15:30:18 Euteneier, Regin Login 15461
05.03.2008 15:29:52 Deutsch, Michael Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:MI; X_MI243991 15460
05.03.2008 15:29:49 Gross, Larissa Login 15476
05.03.2008 15:29:31 Rjabow, Marina Login 15475
05.03.2008 15:29:11 Deutsch, Michael Login 15458
05.03.2008 15:28:57 Schaaf, Jürgen Login 15473
05.03.2008 15:28:51 Kassumov, Marina Login 15471
05.03.2008 15:28:32 Bryzgunova, Antonina Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:DI; X_DI243991 15456
05.03.2008 15:28:18 Bryzgunova, Antonina Jahr:2008; KW:11; Linie:1; Schicht:S; Tag:MO; x2 15454
05.03.2008 15:28:09 Mecker, Elena Jahr:2008; KW:10; Linie:2; Schicht:F; Tag:SA; x1 15470
05.03.2008 15:27:54 Bryzgunova, Antonina Login 15452
05.03.2008 15:27:45 Bryzgunova, Antonina Login 15450
05.03.2008 15:27:45 Mayer, Dominic Login 15451
05.03.2008 15:27:37 Bryzgunova, Antonina Login 15449
05.03.2008 15:27:35 Mikuzys, Ingrid Jahr:2008; KW:11; Linie:1; Schicht:N; Tag:SV; x1 15468
05.03.2008 15:27:34 Spreier, Claudia Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:SV; x1 15467
05.03.2008 15:27:26 Wulfert, Maike Jahr:2008; KW:11; Linie:33; Schicht:N; Tag:DO; X_DO244012 15466
05.03.2008 15:27:20 Belik, Elena Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; x2 15464
05.03.2008 15:25:02 Möller, Ralph Login 15459
05.03.2008 15:23:44 Spreier, Claudia Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:SV; x1 15457
05.03.2008 15:23:41 Wulfert, Maike Jahr:2008; KW:11; Linie:2; Schicht:N; Tag:DI; X_DI244000 15455
05.03.2008 15:23:09 Deines, Swetlana Jahr:2008; KW:11; Linie:2; Schicht:S; Tag:MO; x1 15453
05.03.2008 15:22:49 Mikuzys, Ingrid Login 15448
05.03.2008 15:21:50 Graf, Ella Login 15447
05.03.2008 15:21:46 Mikuzys, Ingrid Login 15446
05.03.2008 15:21:44 Dronov, Marina Login 15445
05.03.2008 15:21:44 Mikuzys, Ingrid Login 15444
05.03.2008 15:21:30 Belik, Elena Login 15443
05.03.2008 15:21:21 Marfin, Schanna Login 15442
05.03.2008 15:21:13 GIM PortalOeffnung SMS an [SMS:016091377273] Möller, Ralph 15439
05.03.2008 15:21:13 GIM PortalOeffnung eMail intern 15441
Anmerkung: Namen wurden geändert
Anmerkung2: Einträge mit GIM bezeichnen die lokale Anwendung (GIM ist der Name der Datenbank)
Infos zur Datenstruktur folgen
Hallo, Hier der SQLStatement, der beim Login abgefragt wird:
SELECT SPlanTbl_ExtMitarbeiter.NameMitarbeiter, SPlanTbl_ExtMitarbeiter.IDUser, SPlanTbl_ExtMitarbeiter.Gruppe, SPlanTbl_ExtMitarbeiter.pw, SPlanTbl_ExtMitarbeiter.ExtFirma
FROM SPlanTbl_ExtMitarbeiter
WHERE (((SPlanTbl_ExtMitarbeiter.ExtFirma)="NE") AND ((SPlanTbl_ExtMitarbeiter.Aktiv)=True))
ORDER BY SPlanTbl_ExtMitarbeiter.NameMitarbeiter;
SELECT SPlanTbl_ExtMitarbeiter.NameMitarbeiter, SPlanTbl_ExtMitarbeiter.IDUser, SPlanTbl_ExtMitarbeiter.Gruppe, SPlanTbl_ExtMitarbeiter.pw, SPlanTbl_ExtMitarbeiter.ExtFirma
FROM SPlanTbl_ExtMitarbeiter
WHERE (((SPlanTbl_ExtMitarbeiter.ExtFirma)="NE") AND ((SPlanTbl_ExtMitarbeiter.Aktiv)=True))
ORDER BY SPlanTbl_ExtMitarbeiter.NameMitarbeiter;
Hier das SQL Statement für die Auswahl der Schichten:
SELECT SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht, SPlanTbl.NameVorname, SPlanTbl.SV, SPlanTbl.MO, SPlanTbl.DI, SPlanTbl.MI, SPlanTbl.DO, SPlanTbl.FR, SPlanTbl.SA, SPlanTbl.SO, SPlanTbl.UniqueID, SPlanTbl_FreigabeInternet.InternetData_Freigabe, SPlanTbl.Bem, SPlanTbl.SchichtHinweis
FROM SPlanTbl, SPlanTbl_FreigabeInternet, SPlanTbl_FreigabeInternet_Wochen
WHERE (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW0]=True,DatePart("ww",Now()))) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True)) OR (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW1]=True,DatePart("ww",Now())+1)) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True)) OR (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW2]=True,DatePart("ww",Now())+2)) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True))
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
SELECT SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht, SPlanTbl.NameVorname, SPlanTbl.SV, SPlanTbl.MO, SPlanTbl.DI, SPlanTbl.MI, SPlanTbl.DO, SPlanTbl.FR, SPlanTbl.SA, SPlanTbl.SO, SPlanTbl.UniqueID, SPlanTbl_FreigabeInternet.InternetData_Freigabe, SPlanTbl.Bem, SPlanTbl.SchichtHinweis
FROM SPlanTbl, SPlanTbl_FreigabeInternet, SPlanTbl_FreigabeInternet_Wochen
WHERE (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW0]=True,DatePart("ww",Now()))) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True)) OR (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW1]=True,DatePart("ww",Now())+1)) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True)) OR (((SPlanTbl.Jahr)=DatePart("yyyy",Now())) AND ((SPlanTbl.KW)=IIf([KW2]=True,DatePart("ww",Now())+2)) AND ((SPlanTbl.NameVorname) Like "X*") AND ((SPlanTbl_FreigabeInternet.InternetData_Freigabe)=True))
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
Hallo, Infos für Datenstruktur: Habe oben 2 Bilder angefügt.
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
Magst Du mir mal das FE (ohne Daten) mal via eMail schicken? Adresse würdest Du in meinem Profil finden.
BG, Felix -misterdemeanor-
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
SQL Statement für die Auswahl der Schichten
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-
Hallo Felix,
Nein, Die Maske die der InternetUser sieht ist viel einfacher, und natürlich nicht die gleiche wie oben abgebildet.
KW: Es gibt die Möglichkeit entweder die aktuelle (KW0), nächste (KW1) oder übernächste Woche (KW2) für das Portal freizugeben.
RowSource für das Access-Formular selber ist die ganze Tabelle [SPlanTbl].
Die SQL-Statement sind eigentlich "normale" Access-Abfragen. Wäre es dann Vorteilhaft diese von der Syntax abzuspecken (unnötige Klammern, Tabellennamen,....), und diese dann als "Daten definition" abzulegen.
Ich schicke dir gerne etwas. Sag mir aber zuerst was FE bedeutet.
Nein, Die Maske die der InternetUser sieht ist viel einfacher, und natürlich nicht die gleiche wie oben abgebildet.
KW: Es gibt die Möglichkeit entweder die aktuelle (KW0), nächste (KW1) oder übernächste Woche (KW2) für das Portal freizugeben.
RowSource für das Access-Formular selber ist die ganze Tabelle [SPlanTbl].
Die SQL-Statement sind eigentlich "normale" Access-Abfragen. Wäre es dann Vorteilhaft diese von der Syntax abzuspecken (unnötige Klammern, Tabellennamen,....), und diese dann als "Daten definition" abzulegen.
Ich schicke dir gerne etwas. Sag mir aber zuerst was FE bedeutet.
KW: Es gibt die Möglichkeit entweder
die aktuelle (KW0), nächste (KW1) oder
übernächste Woche (KW2) für
das Portal freizugeben.
die aktuelle (KW0), nächste (KW1) oder
übernächste Woche (KW2) für
das Portal freizugeben.
Ah, OK.
Die SQL-Statement sind eigentlich
"normale" Access-Abfragen.
"normale" Access-Abfragen.
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.
Wäre es dann Vorteilhaft diese von der
Syntax abzuspecken (unnötige Klammern,
Tabellennamen,....), und diese dann als
"Daten definition" abzulegen.
Syntax abzuspecken (unnötige Klammern,
Tabellennamen,....), und diese dann als
"Daten definition" abzulegen.
Definitiv.
Ich schicke dir gerne etwas. Sag mir aber
zuerst was FE bedeutet.
zuerst was FE bedeutet.
FE = Front End. Also das womit der InternetUser arbeitet.
wir haben im Upload sowie im Download die gleiche Bandbreite, jeweils 2 Mbit
Hier die abgespeckte version, die ich nun als Daten Definition abgespeichert habe:
SELECT NameMitarbeiter, IDUser, Gruppe, pw, ExtFirma
FROM SPlanTbl_ExtMitarbeiter
WHERE ExtFirma="NE" AND Aktiv=True;
SELECT NameMitarbeiter, IDUser, Gruppe, pw, ExtFirma
FROM SPlanTbl_ExtMitarbeiter
WHERE ExtFirma="NE" AND Aktiv=True;
Hier die abgespeckte Version der Datenasuwahl (hier konnte nicht viel gewonnen werden):
SELECT SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht, SPlanTbl.NameVorname, SPlanTbl.SV, SPlanTbl.MO, SPlanTbl.DI, SPlanTbl.MI, SPlanTbl.DO, SPlanTbl.FR, SPlanTbl.SA, SPlanTbl.SO, SPlanTbl.UniqueID, SPlanTbl_FreigabeInternet.InternetData_Freigabe, SPlanTbl.Bem, SPlanTbl.SchichtHinweis
FROM SPlanTbl, SPlanTbl_FreigabeInternet, SPlanTbl_FreigabeInternet_Wochen
WHERE ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW0]=True,DatePart("ww",Now()))) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True)) OR ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW1]=True,DatePart("ww",Now())+1)) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True)) OR ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW2]=True,DatePart("ww",Now())+2)) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True))
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
SELECT SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht, SPlanTbl.NameVorname, SPlanTbl.SV, SPlanTbl.MO, SPlanTbl.DI, SPlanTbl.MI, SPlanTbl.DO, SPlanTbl.FR, SPlanTbl.SA, SPlanTbl.SO, SPlanTbl.UniqueID, SPlanTbl_FreigabeInternet.InternetData_Freigabe, SPlanTbl.Bem, SPlanTbl.SchichtHinweis
FROM SPlanTbl, SPlanTbl_FreigabeInternet, SPlanTbl_FreigabeInternet_Wochen
WHERE ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW0]=True,DatePart("ww",Now()))) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True)) OR ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW1]=True,DatePart("ww",Now())+1)) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True)) OR ((SPlanTbl.Jahr=DatePart("yyyy",Now())) AND (SPlanTbl.KW=IIf([KW2]=True,DatePart("ww",Now())+2)) AND (SPlanTbl.NameVorname Like "X*") AND (SPlanTbl_FreigabeInternet.InternetData_Freigabe=True))
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
Ich habe jetzt eine einfache Lösung gefunden, wie ich dieses SQL-Statement verkürzen kann: Ich füge ein neues Feld [Selektiert] (Boolean) in der Tabelle [SPlanTbl] hinzu. Beim Öffnen des Portals führe ich ein Aktualisierungsabfrage durch, und markiere alle bettroffene Datensätze. Dann bezieht sich das SQL-Statement nur noch auf eine Tabelle, und wird daher kürzer:
SELECT Jahr,KW,linie,Schicht,NameVorname,MO,DI,MI,DO,FR,SA,SO,UniqueID,Bem,SchichtHinweis,Selektiert
FROM SPlanTbl
WHERE Selektiert=True AND NameVorname Like "X*"
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
SELECT Jahr,KW,linie,Schicht,NameVorname,MO,DI,MI,DO,FR,SA,SO,UniqueID,Bem,SchichtHinweis,Selektiert
FROM SPlanTbl
WHERE Selektiert=True AND NameVorname Like "X*"
ORDER BY SPlanTbl.Jahr, SPlanTbl.KW, SPlanTbl.linie, SPlanTbl.Schicht;
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
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
Hallo Sven, auch vielen Dank für deine Rückmeldung.
Ich muss jetzt eins klar stellen Ich hab schon so manchen "Oracler" oder "SLQler" verwundert, was ich alles in Access hinkriege. Meine Datenbanken können alles was moderne ERP-Systeme anbieten.
Das heisst Access kann (fast) alles, aber hat in Sachen Performance seine Grenzen.
Hier bin ich leider zum ersten Mal an eine Grenze gestossen, wo Access scheitert.
Die verbesserte SQLStatements werden wir nur einsetzen, bis eine endgültige Lösung durchgeführt wird.
Ich denke dass diese Ergebnisse vielleicht anderen helfen werden, schneller zu einem Ergebnis zu kommen, deshalb gehe ich auch hier so in's Detail.
Ich muss jetzt eins klar stellen
Ich hab schon so manchen "Oracler" oder "SLQler" verwundert, was ich alles in Access hinkriege. Meine Datenbanken können alles was moderne ERP-Systeme anbieten.Das heisst Access kann (fast) alles, aber hat in Sachen Performance seine Grenzen.
Hier bin ich leider zum ersten Mal an eine Grenze gestossen, wo Access scheitert.
Die verbesserte SQLStatements werden wir nur einsetzen, bis eine endgültige Lösung durchgeführt wird.
Ich denke dass diese Ergebnisse vielleicht anderen helfen werden, schneller zu einem Ergebnis zu kommen, deshalb gehe ich auch hier so in's Detail.
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
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
Hallo Sven,
Ja, richtig. Es war auch so, dass dieser Access-Schichtplan am Anfang nur intern benutzt wurde, und das Planungspersonal dann die Externe telefonisch angerufen hat, und diese manuel in der Datenbank eingetragen hat. Die gute Dame war ein ganzer Tag mit diesen Telefonate (über 50 Externe anrufen) beschäftigt.
Dann haben wir eine Lösung gesucht, wie man dies automatisieren kann. Hat ja 2 Jahre sehr gut geklappt. Aber nun sind es doppelt so viel Externe, und wir sind an die Grenze des Systems gekommen.
Letztes Jahr war es auch so, dass es 6-7 Stunden gedauert hat, bis alle Plätze belegt waren. Seit 2 Monate stürtzen sich alle miteinander auf die Web-Application, weil jeder den besten Platz haben will. In 1,5 Stunden ist (trotz Probleme) alles belegt.
Es ist auch so das wir mittlerweile unterschiedliche Arbeiten zu besetzen haben, daher interessante und weniger interessante oder anstregende. Ist vielleicht der Grund, warum sich alle nach Erhalt der SMS drauf stürtzen.
Gruss
Claude
Ja, richtig. Es war auch so, dass dieser Access-Schichtplan am Anfang nur intern benutzt wurde, und das Planungspersonal dann die Externe telefonisch angerufen hat, und diese manuel in der Datenbank eingetragen hat. Die gute Dame war ein ganzer Tag mit diesen Telefonate (über 50 Externe anrufen) beschäftigt.
Dann haben wir eine Lösung gesucht, wie man dies automatisieren kann. Hat ja 2 Jahre sehr gut geklappt. Aber nun sind es doppelt so viel Externe, und wir sind an die Grenze des Systems gekommen.
Letztes Jahr war es auch so, dass es 6-7 Stunden gedauert hat, bis alle Plätze belegt waren. Seit 2 Monate stürtzen sich alle miteinander auf die Web-Application, weil jeder den besten Platz haben will. In 1,5 Stunden ist (trotz Probleme) alles belegt.
Es ist auch so das wir mittlerweile unterschiedliche Arbeiten zu besetzen haben, daher interessante und weniger interessante oder anstregende. Ist vielleicht der Grund, warum sich alle nach Erhalt der SMS drauf stürtzen.
Gruss
Claude
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
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:
Edit Link war falsch, hier der Snapshot des Dialoges
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-
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:
SQL = "SELECT TOP {SqlParam_endRecord} Jahr, KW, SVDat, MODat, DIDat, MIDat, DODat, FRDat, SADat, SODat " & vbLf & _
"FROM SPlanTbl_Kalender " & vbLf & _
"WHERE (KW = {KalenderWo} " & vbLf & _
"OR KW = {KalenderWo}+1 " & vbLf & _
"OR KW = {KalenderWo}+2) " & vbLf & _
"AND Jahr = {KalenderYear} {SQL_OrderBy}"
CountSQL = "SELECT COUNT(*) FROM (SELECT Jahr, KW, SVDat, MODat, DIDat, MIDat, DODat, FRDat, SADat, SODat " & vbLf & _
"FROM SPlanTbl_Kalender " & vbLf & _
"WHERE (KW = {KalenderWo} " & vbLf & _
"OR KW = {KalenderWo}+1 " & vbLf & _
"OR KW = {KalenderWo}+2) " & vbLf & _
"AND Jahr = {KalenderYear}) cnt" 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-
Hallo Felix, vielen Dank für deine Mühe.
Ich habe mich selber noch nicht direkt darum gekümmert (macht eine andere Person bei IT), wie der Code aussieht, weil ich hier einfach nicht der Spezialist bin. Aber 11.000 Zeilen !? Habe ich nicht mal in alle 15 Datenbanken zusammen, weil ich ja jede Zeile in Access selber schreibe.
Ich frage mich auch, was die Auswahl der Kalenderwoche hier sucht. In der Access-Abfrage ist es ein Kriterium zur Auswahl der Datensätze (bzw in Access brauche ich das). Sollte hier nicht mehr nötig sein. Die Web-Application muss einfach die ausgewälte Datensätze anzeigen.
Zur Erklärung: Die Dame in der Fertigungssteuerung kann in der ACCESS-DB auswählen, ob Sie die nächste Woche im Portal freigibt (default), Oder zusätzlich dazu die aktuelle, oder die Übernächste.
Für die nächste Woche ist dann KW1=true (und KW0=false, und KW2=false)
Ich gehe davon aus, dass das SELECT COUNT im CodeCharge benutzt wird, um automatisch bei mehr als ZB 20 Datensätze eine Navigation (Blatt 1, Blatt2) automatisch anzuzeigen
mfG
Claude
Ich habe mich selber noch nicht direkt darum gekümmert (macht eine andere Person bei IT), wie der Code aussieht, weil ich hier einfach nicht der Spezialist bin. Aber 11.000 Zeilen !? Habe ich nicht mal in alle 15 Datenbanken zusammen, weil ich ja jede Zeile in Access selber schreibe.
Ich frage mich auch, was die Auswahl der Kalenderwoche hier sucht. In der Access-Abfrage ist es ein Kriterium zur Auswahl der Datensätze (bzw in Access brauche ich das). Sollte hier nicht mehr nötig sein. Die Web-Application muss einfach die ausgewälte Datensätze anzeigen.
Zur Erklärung: Die Dame in der Fertigungssteuerung kann in der ACCESS-DB auswählen, ob Sie die nächste Woche im Portal freigibt (default), Oder zusätzlich dazu die aktuelle, oder die Übernächste.
Für die nächste Woche ist dann KW1=true (und KW0=false, und KW2=false)
Ich gehe davon aus, dass das SELECT COUNT im CodeCharge benutzt wird, um automatisch bei mehr als ZB 20 Datensätze eine Navigation (Blatt 1, Blatt2) automatisch anzuzeigen
mfG
Claude
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.
Aber 11.000 Zeilen !?
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.
Ich gehe davon aus, dass das SELECT COUNT im CodeCharge benutzt wird, um automatisch bei
mehr als ZB 20 Datensätze eine Navigation (Blatt 1, Blatt2) automatisch anzuzeigen
mehr als ZB 20 Datensätze eine Navigation (Blatt 1, Blatt2) automatisch anzuzeigen
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)
Private Function OpenRecordset(sSQL,isCountSQL)
Dim Command
Dim Recordset
If Not isCountSQL And Options.Count>0 Then
Dim Page : Page=IIF(mActivePage>0,mActivePage,1)
Dim Size : Size=IIF(mPageSize>0,mPageSize,0)
If Options.Exists("TOP") Then
'support old variant
If Size > 0 Then
sSQL=Replace(sSQL,"{SqlParam_endRecord}", Page * Size, 1, 1)
Else
sSQL=Replace(sSQL,"{SqlParam_endRecord}", "", 1, 1)
End If
...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.
Hi Felix,
Nochmal vielen Dank für deine Analyse.
Ich denke nun auch, dass wir in Richtung MySQL gehen werden.
Es ist wie du sagst: Der CodeCharge deckt alle Eventualitäten ab, und dabei sind 95% von Sachen drin, die wir hier gar nicht brauchen.
Deshalb hasse ich auch Assitenten in VBA: Ich programmiere lieber alles selber, dann weiss ich was drin ist. Und es ist nur drin was drin sein soll.
Am Montag kommt auch noch ein externer Experte zu uns, um uns bei einer Umstellung zu Unterstützen (oder vorerst mal zu beraten). Du hast ja hier schon mal Super Vorarbeit geleistet. An der Stelle nochmal vielen Dank.
Ich werde aber auch in diesem Beitrag die Umstellung kommentieren, damit der Beitrag komplett ist, und anderen Leute in Forum helfen kann.
Gruss
Claude
Nochmal vielen Dank für deine Analyse.
Ich denke nun auch, dass wir in Richtung MySQL gehen werden.
Es ist wie du sagst: Der CodeCharge deckt alle Eventualitäten ab, und dabei sind 95% von Sachen drin, die wir hier gar nicht brauchen.
Deshalb hasse ich auch Assitenten in VBA: Ich programmiere lieber alles selber, dann weiss ich was drin ist. Und es ist nur drin was drin sein soll.
Am Montag kommt auch noch ein externer Experte zu uns, um uns bei einer Umstellung zu Unterstützen (oder vorerst mal zu beraten). Du hast ja hier schon mal Super Vorarbeit geleistet. An der Stelle nochmal vielen Dank.
Ich werde aber auch in diesem Beitrag die Umstellung kommentieren, damit der Beitrag komplett ist, und anderen Leute in Forum helfen kann.
Gruss
Claude
Hallo, Zu Info,
Habe mal MySQL lokal installiert, eine DB angelegt, die benötigte Tabellen mit dem MigrationsTool rübergeholt, die Tabellen anschliessend in Access über ODBC wieder verknüpft.
Ein paar Zwischeninstallationen waren noch notwendig, wie ZB Sun Java JRE, und der ODBC-Connector.
Es ist lokal genau so schnell wie direkt in der Access-Datenbank. Mal sehen wie es sich im Netzwerk verhält.
Gruss
claude
Habe mal MySQL lokal installiert, eine DB angelegt, die benötigte Tabellen mit dem MigrationsTool rübergeholt, die Tabellen anschliessend in Access über ODBC wieder verknüpft.
Ein paar Zwischeninstallationen waren noch notwendig, wie ZB Sun Java JRE, und der ODBC-Connector.
Es ist lokal genau so schnell wie direkt in der Access-Datenbank. Mal sehen wie es sich im Netzwerk verhält.
Gruss
claude
Hallo,
Heute Morgen wurde intern folgende Entscheidung getroffen:
- SQL Server 2005
- ASP
- Migration der Tabellen wird Morgen durchgeführt.
- Programmierung der Web-Application innerhalb 2 Wochen
Heute Morgen wurde intern folgende Entscheidung getroffen:
- SQL Server 2005
- ASP
- Migration der Tabellen wird Morgen durchgeführt.
- Programmierung der Web-Application innerhalb 2 Wochen
Datenbank auf vorhandenem SQL Server 2005 angelegt, Tabellen migriert, Datenquelle angelegt.
Bemerkung: Hatte das Problem, das die Verknüpfung in Access von Tabellen vom SQL Server nicht geht, wenn der Tabellenname auf dem server zu lang ist ?! Kann man die Länge der Tabellennamen auf dem SQL server begrenzen??
Habe dann den Tabellennamen verkürzt, und anschliessend in Access wieder umbenannt, damit ich nicht Abfragebn und Code ändern musste (Quick and Dirty). Wenn jemand den Grund für dieses Problem kennt ..... Danke
mfG
Claude
PS: Grund der Entscheidung vom Vortag (SQL Server und ASP) ist unteranderem auch Konzern bedingt, da die Entwicklung in unserer Firma in diese Richtung geht (Sharepoint,...), und eine Installation von SQL Server 2005 bereits vorhanden war.
Bemerkung: Hatte das Problem, das die Verknüpfung in Access von Tabellen vom SQL Server nicht geht, wenn der Tabellenname auf dem server zu lang ist ?! Kann man die Länge der Tabellennamen auf dem SQL server begrenzen??
Habe dann den Tabellennamen verkürzt, und anschliessend in Access wieder umbenannt, damit ich nicht Abfragebn und Code ändern musste (Quick and Dirty). Wenn jemand den Grund für dieses Problem kennt ..... Danke
mfG
Claude
PS: Grund der Entscheidung vom Vortag (SQL Server und ASP) ist unteranderem auch Konzern bedingt, da die Entwicklung in unserer Firma in diese Richtung geht (Sharepoint,...), und eine Installation von SQL Server 2005 bereits vorhanden war.
Hallo,
die neu geschriebene Web-Application ist Online .... und schnell
Hier nochmal ein Danke an alle Teilnehmer, hat mir sehr geholfen.
mfG
Claude
PS: Jetzt habe ich neue Probleme mit der Datenbank (Datensatz-Konflikte ....warscheinlich durch den ODBC Treiber) .... werden aber in den nächsten Woche auf AC2003 umsteigen, und das SQL native einsetzen, das müsste dieses neue Problem behoben sein.
die neu geschriebene Web-Application ist Online .... und schnell
Hier nochmal ein Danke an alle Teilnehmer, hat mir sehr geholfen.
mfG
Claude
PS: Jetzt habe ich neue Probleme mit der Datenbank (Datensatz-Konflikte ....warscheinlich durch den ODBC Treiber) .... werden aber in den nächsten Woche auf AC2003 umsteigen, und das SQL native einsetzen, das müsste dieses neue Problem behoben sein.
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
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 Christian,
Danke für die Infos.
Ich will noch nicht zu AC2007 wechseln, weil wir in der Firma Office 2003 einsetzen. Sowiel ich weiss ist auch an der JetEngine von 2007 nic jts mehr verbessert worden.
mfG
claude
Danke für die Infos.
Ich will noch nicht zu AC2007 wechseln, weil wir in der Firma Office 2003 einsetzen. Sowiel ich weiss ist auch an der JetEngine von 2007 nic jts mehr verbessert worden.
mfG
claude
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
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
...ich weiss. Wir benutzen deshalb seit ca 8 Jahre bereits Access97 als Runtime. Die von dir beschriebene Vorteile kann ich nur bestätigen. Wir bieten Office und die Access-Runtime über 6 Citrix-Server an unseren Mitarbeiter an. Daher es arbeiten alle mit den gleichen Versionen. Und nur die Entwickler haben eine Vollversion.
mfG
claude
mfG
claude
