Hallo,
ich hab da ne Access-Datenbank die solangsam vor Daten zusammenbricht.
Ich habe ein Frontend (User) und Backend (Server). Ich möchte diese Datenbank in eine „normale“ Datenbank konvertieren. Soweit so gut. Aber kann ich das Access-Frontend auch soweit bearbeiten, dass jenes auch auf MYSQL, MSSQL o.ä. zugreifen kann. Wenn ja, wie?? (Howto?)
Oder muss ich ein komplett neues Frontend in php o.ä. basteln, was sehrsehr viel arbeit wäre (komplexes Frontend!!).
Mfg
Ralf
Hallo, Ralf!
Aber kann ich das Access-Frontend auch soweit
bearbeiten, dass jenes auch auf MYSQL, MSSQL o.ä. zugreifen
kann. Wenn ja, wie?? (Howto?)
Ja, leichtestes von Welt. Wenn Du Deine Serverdatenbank aufgesetzt hast, kannst Du in Deinem Frontend die Tabellen wie aus einer Access-Datei ebenfalls einbinden. Als Datenquelle gibst Du im Dialogfeld den Dateityp „ODBC-Datenbanken“ ein und suchst Dir Deine Datenbank. Ggf. musst Du einmalig die Tabellennamen anpassen, weil einige Datenbanken beim Einbinden einen Präfix für die Tabelle mit angeben. Dann sollte Dein Frontend ohne Probleme weiterlaufen.
Gruß, Manfred
Mahlzeit,
Ja, leichtestes von Welt.
So wie du es beschreibst ja, aber…
Das Problem mit der Datenhaltung in Access ist nicht nur die Struktur, wie die Daten auf dem Dateisystem abgelegt werden, sondern auch und vor allem die Art, wie Access mit ihnen bei der Verarbeitung umgeht. Bei einer Abfrage zum Beispiel wird der Frontend-Rechner die Daten aktiv durchsuchen, egal, wo sich diese befinden - da hat man nur begrenzte Vorteile davon, daß sie auf dem SQL-Server liegen.
Wenn man ein bißchen mehr Aufwand betreibt, wird ein effizientes System daraus. Der Aufwand beinhaltet, alle Abfragen, zumindest aber die Rechenintensivsten, in den SQL-Server zu verlagern. Das erlaubt eine effizientere Nutzung der Ressourcen, da der Server für diese Operationen optimiert ist und meist auch entsprechend dimensioniert ist; als Nebeneffekt werden auch Netzzugriffe dadurch minimiert.
Einen Nachteil hat das Verfahren schon: man wird in den seltensten Fällen die Abfragen 1:1 übertragen können; eine Übersetzung in das native SQL des verwendeten RDBMS wird fast immer erforderlich sein. Die Mühe lohnt sich aber!
Gruß
Sancho
Hallo, Ralf!
Ja, leichtestes von Welt.
So wie du es beschreibst ja, aber…
[Optimierung]
Si. Genau so ist es. Aber überführe erst einmal die Tabellen und bring Dein Programm wieder zum Laufen. Dann kannst Du Dich an die Geschwindigkeit setzen und an den erforderlichen Stellen entsprechend eingreifen, wie Sancho es beschreibt. Denn:
Access=„Schieb mir mal die drei Millionen Datensätze übers Netz, ich suche mir das Feld des einen dann schon selbst raus.“, furchtbarer Netzverkehr, viel Rechenzeit auf Deinem Rechner.
Server=„Such mir mal das Feld des einen Datensatzes aus den drei Millionen raus und schick mir den.“, Netzverkehr ein paar hundert Zeichen SQL-String zum Server und ein paar Zeichen vom Server zurück mit dem Ergebnis, und die Rechenzeit beim (i. d. R. leistungsfähigeren) Server.
Heißt für Dich zu Optimierungszwecken zweierlei: Anpassen/Übersetzen der SQL-Statements in den jeweiligen Dialekt. Zum anderen müssen die Abfragen nicht als Access-Abfragen, sondern als Pass-Through-Abfragen definiert sein. Sonst will Access nämlich arbeiten, und das ging noch selten gut und schnell (und wird wohl SQL-Syntaxfehler produzieren).
Je nach verwendeter Datenbank gibt es obendrein die Möglichkeit, über stored procedures bestimmte Rechenschritte ebenfalls auf den Server auszulagern, die über eine reine Abfrage hinausgehen. Dies sind also i. d. R. etwas komplexere Datenaktualisierungen. Dazu solltest Du Dich dann aber auch ein wenig in der Architektur des verwendeten Datenbanksystems auskennen und die erforderlichen Rechte besitzen.
Gruß, Manfred
Super, Danke, ich werde den Client nun erstmal an die „richtige“ Datenbank anbinden.
Aber das mit dem optimieren hab ich noch nicht ganz gerafft. Kann ich den Client abfragentechnisch so hinbekommen, das der Server (großteils) die Rechenarbeit macht, oder muss ich ein neues Frontend basteln (in php o.ä.)? … gibt es vielleicht auch tools für sowas? 
Ihr wisst ja; ich hab doch keine Zeit!
greetZ
SQL Server 
ie Abfragen laufen auf dem SQL Server, nur Parameter und Ergebnisse werden transportiert, wenn die Abfrage aufgerufen wird.
Bei Access werden all Daten (Tabellen) zum Server gesendet und die Ergebnisse dan wieder zurückgesendet.
Deshalb ist ein SQL Server so schnell.
Ein Access Server wäre ähnlich gut. Ist aber nur im Entwicklerkit von MS Office enthalten.
Gruß Hans
Aber das mit dem optimieren hab ich noch nicht ganz gerafft.
Kann ich den Client abfragentechnisch so hinbekommen, das der
Server (großteils) die Rechenarbeit macht,
Ja. Die Abfragen dazu sind sog. Pass-Through-Abfragen, Online-Hilfe siehe unter „Senden von Befehlen an eine SQL-Datenbank unter Verwendung einer SQL Pass-Through-Abfrage“ (Eingabe bei der Onlinehilfe-Suche „Passthrough“, hier beim meinem gerade offenen A97; dürfte bei den anderen aber ähnlich heißen).
Da steht ziemlich genau beschrieben, wie Du eine Pass-Through-Abfrage generierst. Und diese lässt dann den Server schuften. Je nach verwendetem Server gibt es leichte Dialekt-Unterschiede in der SQL-Syntax. (Oracle will z. B. „DELETE FROM Tabelle“, Access „DELETE * FROM Tabelle“) Als Anhalt kannst Du Dir schon mal die Abfragen unter Access im Entwurf zusammenklicken und dann als SQL-Statement in die Pass-Through-Abfrage reinkopieren. Dann ggf. die Syntax überprüfen. So kriegst Du eigentlich relativ schnell die vorhandenen Abfragen umgeswitcht.
oder muss ich ein
neues Frontend basteln (in php o.ä.)?
Wenn Dir langweilig wird, ja.
Ihr wisst ja; ich hab doch keine Zeit!
Ach so… Dann halt nicht.