mdb-Datenbank ohne Windows-Verwaltung öffnen
-
Hallo,
ich möchte gerne eine MS Access-Datenbank in meinem Programm verwenden. Ich hab bisher immer die BDE-Tools verwendet, allerdings kam ich dann nicht drumherum, die Datenbank vorher manuell in Windows zu registrieren (unter Systemsteuerung). Es soll aber später so sein, dass es einen Open-Dialog gibt, mit dem die Datenbank ausgewählt wird, d.h. eine Registrierung wäre recht viel Aufwand.
Gibt es mit BDE-Mitteln (also TDatabase) eine Möglichkeit, eine Datenbankdatei direkt zu öffnen? Wenn ja, wie mach ich das?
Wenn nein, wie macht man es sonst am elegantesten? Per ADO habe ich es hinbekommen, aber dafür muss ich mein Programm wieder umschreiben (TTable weicht TADOTabel, etc.), was ich eigentlich nicht so gerne möchte.Gruß, Heimelchen
-
Hi Heimelchen,
höre auf zu weinen wegen Deinem geliebten TTable.
Die BDE ist tot und verursacht wenn man daran Leichenschändung betreibt mehr Ärger als Nutzen.
Machs mit ADO und benenne die Dinger meinetwegen in Table1, Table2, Query1... um.
Da die ADO-Schnittstelle, durch die alles muß nicht die schnellste ist, solltest Du bei großen Datenmengen sowieso überlegen, soviel wie irgend möglich mit SQL-Befehlen zu machen.
Wenn Du mit ADO arbeitest braucht das Programm im günstigen Fall (Win-XP und Nachfolger) weder installiert zu werden noch ein Access auf das es zugreifen kann. Die notwendige ADO-Funktionalität ist bereits in XP eingebaut und bruacht nur noch verwendet zu werden. Du kannst Programme schreiben, die nicht installiert werden müssen und sich rückstandsfrei durch einfaches Löschen wieder entfernen lassen. Ist in der heutigen zeit nicht ganz unangenehm.Gruß Mümmel
-
außerdem ist das umschreiben denke ich weniger das Problem, einfach die neuen Komponenten erstellen und dann im Code über "Suchen und Ersetzen" überall ein ADO davor! oder noch einfacher, du nennst deine ADOTable's einfach so wie die vorherigen Table
-
Hallo
Und wenn du schon dabei bist, tausch alle T...Table-Komponenten gleich gegen T...Query-Komponenten aus. T...Query ist wesentlich flexibler als T...Table. Und früher oder später wirst du dich eh in SQL einarbeiten müßen.
bis bald
akari
-
Ich kann die Aussagen meiner Vorredner nur bekräftigen. Weg mit der BDE und TTable. TADOTable solltest Du auch gar nicht erst verwenden. Das Ding ist kaum mehr als ein Marketinggag...
-
Vielleicht habt ihr meine anderen Beiträge verfolgt:
Der Haken kommt an den Stellen, wo die BDE andere Funktionen bietet, also ADO. Dass man ->Session->GetTableNames beim ADO-Pendant nicht mehr filtern kann, habe ich manuell ausgebügelt. Aber so ein verdammtes BatchMove bringt mich zum verzweifeln.
SQL kenn ich von PHP, davor scheue ich mich gar nicht so. Aber das Programm ist halt recht groß, bisher war es mit suchen und ersetzen am einfachsten. Aber nu komm ich zu den Stellen, an denen sich ADO und BDE unterscheiden.
Ist ADO jetzt eigentlich "DIE" Datenbankverbindung?
-
Die Tables verwende ich übrigens hauptsächlich, weil ich diese TDBCheckBox und Edits und so verwende...
-
Hallo
Ist ADO jetzt eigentlich "DIE" Datenbankverbindung?
Nein, sie ist nur eindeutig besser als die BDE, die seit über 10 Jahren nicht weiterentwickelt wurde.
Die Tables verwende ich übrigens hauptsächlich, weil ich diese TDBCheckBox und Edits und so verwende...
Ich sehe jetzt keinen Grund, warum die Datensensitiven DB-Komponenten nicht genauso gut auch mit T...Query zusammenarbeiten sollten. Schließlich sind doch sowohl T...Table als auch T...Query von TDataSet abgeleitet.
bis bald
akari
-
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.