mdb-Datenbank ohne Windows-Verwaltung öffnen
-
Hi Heimelchen,
es ist nicht DIE Datenbankverbindung, aber es ist das, was Du auf jedem Rechner mit XP aufwärts ohne installieren findest und was ohne instellieren läuft und in Verbindung mit Access für kleinere bis mittlere Datenbestände reicht.
Vieles was in herkömmlihcer Weise mit TTables mühsam von Hand programmiert wird lässt sich mit SQL viel einfacher bewerkstelligen. Also nicht zu kurz springen.
TDBCheckboxen und DBEdits kann man genau so gut mit Querys verwenden. Aber immer einen Autoinc-Index in den Tabellen mitführen und verwenden, damit die Datenbank weiß in welches Feld sie was schreiben muß. Oder das Rückschreiben von Hand erledigen. Ich mache das so, das alle Felder die rückgeschrieben werden müssen einen Tag > 0 bekommen und die Indexfelder nach denen der passende Datensatz rausgesucht wird dann den gleichen als Negativwert. Da kann dann eine kleine Hilfsfunktion den nötigen SQL-Befehl automatisch zusammenbasteln.Gruß Mümmel
-
Aber das ist dann doch schon genau der Punkt, den Query muss ich basteln, mit Table, DataSource und DBEdit ist's schon fertig.
Das Problem ist, ich krieg hier ein Programm vor die Füße, das ich nicht kenne, von dem ich die Datenbank nicht kenne, in einer Sprache, die ich vonr 3 Jahren das letzte Mal verwendet habe und das nicht dokumentiert ist. Und das soll ich nun anpassen. Da scheue ich mich schon, mehr zu ändern, als unbedingt notwendig. Sonst schreib ich das ganze Ding hinterher neu und bin ein halbes Jahr beschäftigt
-
Jetzt probier ich grad ein bissl mit ADOQuery herum und stelle fest, dass ich darauf auch mit TDataSource drauf zugreifen kann. Und dann kann man sogar die Werte über ein DBGrid und DBNavigator ändern.
Da stell ich mir aber die Frage, warum. In der Doku steht, ADOQuery führt den SQL-Befehl beim Open aus und liefert die Daten. Kommen diese denn als Referenz an, sodass ich sie ändern kann? Kenne das von PHP nur so, dass Lesen und Schreiben getrennt voneinander sind.
-
du kannst die daten in der datenbank auch über DBEdits etc. ändern, weil du meintest, dass du DBEdits verwendest ...
-
Hi Heimelchen,
warum leitest Du Dir nicht von TQuery eigene Komponenten ab, die Du dan mit den entsprechenden Fähigkeiten ausstattest. Da kannst Du dann Deine gefilterten Tabellenlisten realisieren genau so wie TBatchMove nachbauen... Die benötigten SQL-Befehle kannst Du dann mit entsprechendem Quelltext automatisch anhand der Eingabeparameter zusammenbauen lassen.... Nebenbei lernst Du dann gleich noch was über die inneren Zusammenhänge der einzelnen VCL-Komponenten.
Auch wenn Du schon etwas SQL kannst, würde ich Dir auf jeden Fall den Balzert empfehlen. Ein kleines Kärtchen das auf (fast) alle SQL-Fragen eine antwort gibt. Newin, ich bin da nciht am Umsatz beteiligt, aber es liegt hier bei mir auf dem Tisch und ist mein wichtigstes Nachschlagewerk.
wirf auch unbedingt mal da einen Blick drauf.
http://support.microsoft.com/kb/275561/deADO-Tables sind sicher nicht ganz zum wegwerfen, aber man sollte sie höchstens für kleine Tabellen benutzen, da beim öffnen der gesamte Tabelleninhalt durch den Flaschenhals ADO geladen werden muss. Das kann bei größeren Tabellen durchaus viele dutzend Sekunden dauern. Wenn Du in denen ändern willst, immer den Primary-Index als Index beutzen, damit ADO weiß, in welchen Datensatz es geänderte Daten zurückschreiben muss, sonst gibts beim Post ne Fehlermeldung.
Gruß Mümmel
-
Heimelchen schrieb:
Kenne das von PHP nur so, dass Lesen und Schreiben getrennt voneinander sind.
Jein. TADOQuery verfügt über die Methoden Insert, Edit, Append und sogar einen Batch-Modus. Damit ist das direkte Ändern möglich, ohne eigene Update- und Insert-Statements zu schreiben. Aber auch nor so lange Du nur eine Tabelle in der Query verwendest. Sobald in der Query auf mehr als eine Tabelle zugegriffen wird (und das ist der Regelfall), musst Du Lesen und Schreiben getrennt durchführen.
-
Ich hoffe, ich steht nicht auf dem Schlauch, aber nochmal nachgehakt:
Ist es so, dass ein SELECT über ein TADOQuery eine Art Referenz auf die abgerufenen Daten liefert?
-
Hi Heimelchen,
select reserviert im Prinzip einen Puffer und füllt den mit dem Ergebnis der Abfrage. Du hast also keine Referenz auf Originaldaten (das wäre bein Joins oder Unions auch zu kompliziert) sondern eine eigens für Deine Verwendung speziell susammengestellte neue Datenmenge. Wenn Du darin änderst, dann versucht ADOQuery zu ermitteln wo was geändert wurde und das in die Ausgangstabelle zurückzuschreiben.
Gruß Mümmel
-
Da ist ADOQuery ja gar nicht so blöd.
Mich verwundert nur, dass es eine "Funktion" Query gibt, in die ich einen SELECT-Befehl schreibe und die trotzdem in meine Datenbank schreibt. Faszinierend!
-
Hi Heimelchen,
so'n ADOQuery ist wesentlich mehr als nur ein Komponentegewordener Select-Befehl.
Das was Du meintest mit Referenz, das findet in dem Sinne bei TTable statt. Da wird einfach nur ein Guckfenster über die linear auf der Platte hintereinander liegenden Daten gezogen (zumindest bei dBase und Paradox) und lediglich für den momentan gerade bearbeiteten Datensatz lediglich ne Art Editorpuffer bereitgestellt.
Bei ADO liegen die Daten dagegen in einem Datensack (genannt Datenbank) und fürs anschauen oder manuell bearbeiten werden die jeweils angeforderten Daten durch ein kleines Zugrifsloch rausgeholt (genauer rauskopiert) und Dir zur Ansicht hingehalten. Nach dem manuellen (oder per C++-Amnweisung) Ändern der Daten müssen dann diese Änderungen alle wieder durch das kleine Eingriffsloch zurück in den Datensack. Alles was dagegen direkt mit SQL-Befehlen erledigt werden kann muß nicht durch das Eingriffsloch sondern nur der Befehl und die eigentliche Änderung kann viel effizienter direkt im Datensack erledigt werden. TADOQuery ist also praktisch ein Vermittler zwischen Dir und dem Datensack, der auch das Weitergeben der Befehle sowie das Rausholen und Zurückstopfen der Daten erledigt. TADOTable entspricht dabei einem ADOQuery mit dem Befehl "select * from Tabelle". Auch es holt alles durch das Eingrifsloch und stopft es anschließend wieder zurück. Entgegen ADOQuery das über select-Optionen nur die jeweils benötigten Daten holt greift ADOTable aber ganz groß rein und holt immer alles raus.Durch die unterschiedliche Arbeitsweise von ADO und normalen TTables gibts Unterschiede in der Abarbeitungsgeschwindigkeit. Manipulationen im Sack mittles SQL gehen vielfach rasend schnell. Konventionelles Bearbeiten von Hand oder mittels C++-Befehl kann dagegen durchaus um mehr als den Faktior 1000 lanbgsamer sein, weil alles durch den schmalen Flaschenhals ADO muss (ist bei anderen richtigen Datenbanken nicht anders).
Gruß Mümmel
-
Joe_M. schrieb:
Heimelchen schrieb:
Kenne das von PHP nur so, dass Lesen und Schreiben getrennt voneinander sind.
Jein. TADOQuery verfügt über die Methoden Insert, Edit, Append und sogar einen Batch-Modus. Damit ist das direkte Ändern möglich, ohne eigene Update- und Insert-Statements zu schreiben. Aber auch nor so lange Du nur eine Tabelle in der Query verwendest. Sobald in der Query auf mehr als eine Tabelle zugegriffen wird (und das ist der Regelfall), musst Du Lesen und Schreiben getrennt durchführen.
Jetzt muss ich meinen alten Thread noch mal ausgraben: mit Zugriff uaf mehere Tabellen meinst du sicherlich JOIN, oder? Wenn ich JOIN verwende, kann ich die Daten trotzdem über DB... Felder ändern.