Access DB Portieren ohne Access installiert zu haben

[FAlter]

Hi,

ich möchte zwei Programme mit TurboDelphi schreiben.

1. Ein Programm, das einmalig ausgeführt werden soll, dass eine bestehende MDB in ein günstigeres DB-Format umwandelt.

2. Ein Programm, das dann mit dieser neuen DB arbeitet.

Es sollen beide Programme ohne Installation weiterer Software lauffähig sein.

Habt ihr eine Idee dafür, wie ich die Access DB umwandeln kann, und welche DB für später geeignet wäre (eine ohne Installation von irgendwas!)? Zugriff soll über eine eigene Klasse erfolgen, die noch entwickelt werden wird und zu einem bestehenden Framework gehört, also nicht über bestehende Komponenten. Sollte also möglichst einfach handhabbar sein, da mir keine Komponente die Arbeit abnehmen soll.

[edit] Ich weiß (noch) nicht was in der DB drin ist, das muss das Portierungsprogramm auslesen, also welche Tabellen mit welchen Feldern. [/edit]

Mfg
FAlter

[Bernhard Geyer]

Definiere günstigers Format?
Definiere deine Anforderungen genauer (Größe/Kosten/Lizenzen/...). So wie es jetzt ausschaut würde das sonst das Wöchentliche "Ich empfehle Datenbank xyz"

[nahpets]

Hallo,

Access lesen sollte über Ado gehen.

Datenbank ohne Installation?

TDBF ist eine Komponente, die DBase und Co ohne BDE kann, wäre das was?

Stephan

[Elvis]

Ankieken von Jet-DBs geht zum Beispiel mit AnySQL
Öffnen im Program geht mit dem OLEDB Provider für Jet über ADO. (DP Suche sollte da genug bringen)
Als lokales DBMS kämen die üblichen Verdächtigen wie SQLite oder Firbird embedded (für exklusiven Zugriff), oder bevor ich es wieder vergesse: Für Delphi gäbe es da die kostenlose embedded von NexusDB.

Kein einziges davon ist als storage engine auch nur annähernd so schrecklich wie Jet.

[FAlter]

Hi,

ich wünsche mit eine schnelle Mailbenachrichtigung... die kam aber viel zu spät an!

Günstigeres Format als Access soll ich definieren? Naja, alles ungleich Access... sozusagen. Also schneller, einfacher, gut aber nicht notwendig wäre: kein * und ?, sondern % und _, außerdem ' statt " für Strings. Und es wäre ganz toll, wenn ich das gleiche Format dann auch noch für meine Haushaltsbuch nehmen könnte, das verwendet derzeit noch CSV, aber ich wills einfacher haben, da was an Funktionen zu erweitern.

Größe: derzeit eine .mdb < 2 MiB, aber stetig wachsend.

Lizenzen/Kosten: Muss nicht OpenSource sein, wäre aber cool, aber kostenlos auf jeden Fall, auch für kommerzielle Nutzung (auch wenn es vorerst nur privat genutzt wird, und wer weiß, wozu ich meine Klassen dann später noch nutzen möchte).

Der Zugriff sollte ohne irgendwelche Komponenten stattfinden, ich will es ja in was eigenes einbauen, und dann den Umweg über eine Komponente gehen ist ja suboptimal.

ODBC fällt weg, da es beizeiten evtl. ein Delphi für Win64 geben wird und ich das Programm damit hoffentlich nur neucompilieren muss, und guckt mal, was es da noch für 64-Bit-ODBC Treiber gibt. (Hoffentlich hab ich bis dahin genügend Geld übrig, mir das neue Delphi auch zu kaufen, z. Zt. könnte ich mir keins leisten, und einen neuen PC mit nem neuen Win brauch ich dazu ja auch.)

Steht ADO bei ner frischen Win-Installation (insbesondere XP, Vista und 2008) zur Verfügung? Ich hätte gerne, dass das Programm auch auf nem 2008er laufen kann, um die DB zu portieren. Oder dessen Nachfolger, wer weiß wanns nicht mehr ein rein privates Projekt sein wird, jedenfalls will ich das offen lassen... Wann auch immer, das steht noch in den Sternen. Vor allem, welche Version, da stehen ja dutzende zur Verfügung, bei Vista ist eine davon anders als bei XP. Und ich kann sie nicht direkt mit TD importiern. :( Das waren jedenfalls die Dinge die mir unklar waren. Ansonsten denke ich kann ich in meinen eigenen Aufzeichnungen nachsehen, in ner anderen Sprache (fragt lieber nicht :kotz: ) hab ich schonmal mit ADO auf Access zugegriffen.

Soweit zu den fehlenden Infos. Jetzt versuch ich erstmal zu gucken, was in der DB drin ist, um mir weiter nen Plan zu machen.

Ok, ich hab auf Vorschau statt absenden geklickt... Also AnySQL kanns mir schon mal anzeigen, jetzt weiß ich was drin ist.

Mfg
FAlter

[Bernhard Geyer]

Zitat:

Zitat von FAlter

Günstigeres Format als Access soll ich definieren? Naja, alles ungleich Access... sozusagen. Also schneller, einfacher, gut aber nicht notwendig wäre: kein * und ?, sondern % und _, außerdem ' statt " für Strings.

Diese Eigenheiten fallen beim Zugriff über ADO weg.

Zitat:

Zitat von FAlter

Größe: derzeit eine .mdb < 2 MiB, aber stetig wachsend.

Also "Spielzeug-"Datenbank.

Zitat:

Zitat von FAlter

Lizenzen/Kosten: Muss nicht OpenSource sein, wäre aber cool, aber kostenlos auf jeden Fall, auch für kommerzielle Nutzung (auch wenn es vorerst nur privat genutzt wird, und wer weiß, wozu ich meine Klassen dann später noch nutzen möchte).

Dann Fällt schon mal MySQL weg :-)

Zitat:

Zitat von FAlter

Der Zugriff sollte ohne irgendwelche Komponenten stattfinden, ich will es ja in was eigenes einbauen, und dann den Umweg über eine Komponente gehen ist ja suboptimal.

Wenn du meinst. Ich würde mir die vereinfach die eine Komponente (oder nur Zugriffsklasse) bietet nicht missen wollen.

Zitat:

Zitat von FAlter

Steht ADO bei ner frischen Win-Installation (insbesondere XP, Vista und 2008) zur Verfügung

Solange es keine Embeddes-Version ist kannst du über ADO darauf zugreifen. Bei Embedded-Versionen wird sie hin und wieder weggelassen und kann auch nicht über Diverse JET-Installer nachinstalliert werden.

Schau dir auch mal ZEOS an. Ist OpenSource und hat für diverse DB's (z.B. sqlite war für deine DB-Größe ganz passend ist) Zugriffsmöglichkeiten.

[FAlter]

Hi,

wo ist denn ADO? AFAIR heißt das "Microsoft ActiveX Data Objects Version ..." aber das finde ich nicht! Hab ich gar kein ADO auf meinem PC?

Oder hab ich da was falsch verstanden? In dieser :kotz: Sprache musste man da ne Typbibliothek importieren. Weiß ich noch ganz genau, vorher ging gar nichts.

@Komponente: Die Vereinfachungen mach ich ja in meiner eigenen Klasse, das geht dann ganz von SQL weg, damit ich bloß keine Fehler mehr mache.

@sqlite: Ich denke ich brauche diese:

Zitat:

sqlitedll-3_6_3.zip
(224.99 KiB) This is a DLL of the SQLite library without the TCL bindings. The only external dependency is MSVCRT.DLL.

Und diese :stupid:

Zitat:

sqlite_docs_3_6_3.zip
(1.71 MiB) This ZIP archive contains most of the static HTML files that comprise this website, including all of the SQL Syntax and the C/C++ interface specs and other miscellaneous documentation.

[edit] Gibts sone Unit auch für sqlite, wo man nur die Header von C übersetzt hat uns sonst nix? [/edit]

Mfg
FAlter

[Bernhard Geyer]

Zitat:

Zitat von FAlter

wo ist denn ADO? AFAIR heißt das "Microsoft ActiveX Data Objects Version ..." aber das finde ich nicht! Hab ich gar kein ADO auf meinem PC?
Oder hab ich da was falsch verstanden? In dieser :kotz: Sprache musste man da ne Typbibliothek importieren. Weiß ich noch ganz genau, vorher ging gar nichts.

Hat Codegear schon gemacht. Liegt bei den Turbo unter der Reiterseit dbGo bzw. ADOExpress.

Zitat:

Zitat von FAlter

@Komponente: Die Vereinfachungen mach ich ja in meiner eigenen Klasse, das geht dann ganz von SQL weg, damit ich bloß keine Fehler mehr mache.

Eine Datenbank und dann kein SQL. Das ist dann wie Fußball ohne Ball.

Zitat:

Zitat von FAlter

@sqlite: Ich denke ich brauche diese..

In der Art. Letztendlich reicht dir eine DLL da die MSVCRT.DLL in jedem aktuellen Windows schon dabei ist.

[FAlter]

Zitat:

Zitat von Bernhard Geyer

Hat Codegear schon gemacht. Liegt bei den Turbo unter der Reiterseit dbGo bzw. ADOExpress.

Naja, ich wollte eigentlich direkt auf das ActiveX-Objekt zugreifen und eben nicht wieder über nen Umweg. Aber OK, ich mach mich mal auf die Suche.

:arrow: Hmm, es gibt ne ADODB200.pas und ne ADODBXP.pas. Heißt das die sind unter beiden OSsen inkompatibel? Ist die XP-Variante wenigstens Vistakompatibel/2008-kompatibel?

Zitat:

Eine Datenbank und dann kein SQL. Das ist dann wie Fußball ohne Ball.

Nö, das ist nur absolut sicher gegen SQL-Injection, weil man nix vergessen kann, und kompatibel zu irgendwelchen DB-Ähnlichen Gebilden, die kein SQL verstehen.

Zitat:

In der Art. Letztendlich reicht dir eine DLL da die MSVCRT.DLL in jedem aktuellen Windows schon dabei ist.

Ok, jetzt muss ich nur noch die Unit zur DLL-Einbindung schreiben oder finden...

Mfg
FAlter

[Bernhard Geyer]

Zitat:

Zitat von FAlter

:arrow: Hmm, es gibt ne ADODB200.pas und ne ADODBXP.pas. Heißt das die sind unter beiden OSsen inkompatibel? Ist die XP-Variante wenigstens Vistakompatibel/2008-kompatibel?

Nee. Bedeutet nur ab welcher OS-Version die Schnittstellen verfügbar sind. Mit einer 2000er kannst du locker unter Vista arbeiten.

Zitat:

Nö, das ist nur absolut sicher gegen SQL-Injection, weil man nix vergessen kann,

Einfach alles über parametrisierte Abfragen machen und gut ist.

Zitat:

und kompatibel zu irgendwelchen DB-Ähnlichen Gebilden, die kein SQL verstehen.

Und die wären? Über ADO stellt MS dirverse Infos bereit die keine DB sind aber per SQL abfragbar sind.

Zitat:

Ok, jetzt muss ich nur noch die Unit zur DLL-Einbindung schreiben oder finden...

Wie wäre es z.B. mit ZEOS. Einfach den dortigen DLL-Header verwenden wenn du unbedingt keine Komponenten willst.

[Elvis]

Felix, du hast wohl ein wenig heiß geduscht heute früh. Und damit meine ich irgendwas weit über 60°C über einen Zeitraum von mehr als 10 Minuten immer schön auf'n Kopf.

IOW: So wie du dir das denkst ist das Blödsinn. ;-)
Du wirst keine C-compatible API nutzen um mit der DB zu reden, das wäre ja total meschugge, wenn man sich die schönen Kapselungen ansieht. Zeos käme zum Beispiel mit SQLite klar, Zeos nutzt ogar einen SQL Präprozessor um die Unterschiede etwas platt zu bügeln.

Du wirst mit SQL auf deine DBs zugreifen, denn andere Optionen hast du nicht. Zum Konvertieren reicht dir ein "SELECT * FROM Xyz" auf der Jet-Seite.
Und da du anhand der Metadaten eine Tabelle in SQLite geriert hast, kannst du auch gleich ein INSERT Statement erzeugen, für diese Tabelle.

Wie Bernhard schon schrieb, immer schön Parameter nehmen und keine Werte in das SQL reinfriemeln.
Das gibt a) keine SQL injektions (was eh BLÖDSINN ist, da die DBs lokal vorliegen!!!) und b) erlaubt es dir das Statement "vorkompiliert" wiederholt auszuführen.
Du musst ja für jeden Datensatz aus Jet nur noch die Parameter ändern, aber das Insert-SQL bleibt ja das gleiche. Damit ersparst du es SQLite für jeden Datensatz das Parsing des Statements und die Berechtigungsprüfungen, etc.

[FAlter]

Hi,

Zitat:

Zitat von Bernhard Geyer

Wie wäre es z.B. mit ZEOS. Einfach den dortigen DLL-Header verwenden wenn du unbedingt keine Komponenten willst.

Da müsste ich so viel ändern, dann kann ich auch gleich selbst was schreiben. Sorry, aber ich will eine Unit, und nicht noch zwei Units mehr und zwei Includes (und wer weiß, das diese zwei Units noch voraussetzen).

Zitat:

Zitat von Elvis

Felix, du hast wohl ein wenig heiß geduscht heute früh. Und damit meine ich irgendwas weit über 60°C über einen Zeitraum von mehr als 10 Minuten immer schön auf'n Kopf.

Definitiv nicht, ich dusche morgends nicht, keine Zeit und zu müde.

Zitat:

wenn man sich die schönen Kapselungen ansieht.

Genau dass will ich ja machen, eine schöne Kapselung. Die entsteht immer nebenbei, wenn ich sie brauche... Und das ist a) kein neues Projekt, ich habe schon zwei andere Programme, die an diesem Datenbankkapselungs-Projekt hängen und b) weil ich Lust dazu habe. Und die wird mir keiner nehmen! Warum wollt ihr mich um den Spaß bringen? Delphi ist für mich derzeit ausschließlich Freizeit, arbeiten tue ich mit was anderem. Versteht doch einfach mal, ich habe beschlossen es so zu tun, weil ich es so will, weil ich Spaß daran habe.

Zitat:

Du wirst mit SQL auf deine DBs zugreifen, denn andere Optionen hast du nicht.

Intern schon, aber letztlich merke ich nix davon.

Zitat:

(was eh BLÖDSINN ist, da die DBs lokal vorliegen!!!)

Was macht das für einen Unterschied? Ob lokal oder nicht, wenn der User was eingibt, sollte das nicht (auch nicht versehentlich) zu SQL-Injections führen. Angenommen ein User gibt irgendwo

{code]Und dann stand da '--- Fertig! ---' auf dem Bildschirm.[/code]

Der unwissende User gibt das ein, Plötzlich ist die SQL-Anweisung Fehlerhaft, denn was nach dem -- kommt ist ein Kommentar. Und der String wurde ja durch das ' schon beendet.

SQL-Injections sind IMMER ein Problem, sie müssen nicht Absicht und nicht nur über Netzwerke geschehen.

Und nun Schluss für heute, es wird spät, und ich muss noch heiß duschen und mein Gehirn verbrennen...

Mfg
FAlter

[Bernhard Geyer]

Zitat:

Zitat von FAlter

Zitat:

Zitat von Bernhard Geyer

Wie wäre es z.B. mit ZEOS. Einfach den dortigen DLL-Header verwenden wenn du unbedingt keine Komponenten willst.

Da müsste ich so viel ändern, dann kann ich auch gleich selbst was schreiben. Sorry, aber ich will eine Unit, und nicht noch zwei Units mehr und zwei Includes (und wer weiß, das diese zwei Units noch voraussetzen).

Hast du überhaupt schon in die ZEOS bezüglich DB-DLL-Interface-Units reingeschaut?

Zitat:

Zitat von FAlter

Genau dass will ich ja machen, eine schöne Kapselung. Die entsteht immer nebenbei, wenn ich sie brauche...
...
Intern schon, aber letztlich merke ich nix davon.

Ok, Es geht dann um eine Art Abstraktion wo du auf externer Ebene auf SQL verzichtest (Bzw. auf andere Weise DB-Neutral definierst wie es z.B. bei ECO auch der Fall ist)

Zitat:

Zitat von FAlter

Zitat:

(was eh BLÖDSINN ist, da die DBs lokal vorliegen!!!)

Was macht das für einen Unterschied? Ob lokal oder nicht, wenn der User was eingibt, sollte das nicht (auch nicht versehentlich) zu SQL-Injections führen. ...
SQL-Injections sind IMMER ein Problem, sie müssen nicht Absicht und nicht nur über Netzwerke geschehen.

Könnte mir bei lokaler DB folgenen Angriffsfall vorsehen: Und zwar bei einer gut Passwort geschützten DB über SQL-Injection an Passwort/Verschlüsselung zu kommen. Hier wird es aber einfacher sein mit SoftICE, Debugger oder mittels "Spion-DLL" an die Zugangsdaten zu kommen

Zitat:

Zitat von FAlter

Und nun Schluss für heute, es wird spät, und ich muss noch heiß duschen und mein Gehirn verbrennen...

Viel Spaß beim Duschen

[Elvis]

Zitat:

Zitat von FAlter

Zitat:

Du wirst mit SQL auf deine DBs zugreifen, denn andere Optionen hast du nicht.

Intern schon, aber letztlich merke ich nix davon.

Für das was du hier vorhast (Daten von X nach Y pumpen) brauchst du nur

• select a,b,c,d from abc
• create table def(a sometype, b sometype,c sometype,d sometype)
• insert into def(a,b,c,d) values(:a,:b,:c,:d)

Zitat:

Zitat:

(was eh BLÖDSINN ist, da die DBs lokal vorliegen!!!)

Was macht das für einen Unterschied?
...
SQL-Injections sind IMMER ein Problem, sie müssen nicht Absicht und nicht nur über Netzwerke geschehen.

Der Unterschied ist, dass lokale DBs immer ungeschützt sind.
Aber wie ich als "a)" bereits sagte, Parameter in dem Insert-Statement verhindern SQL Injections. Die Werte kommen als Variablen rein und der Parser hat nie etwas mit den Inhalten der Variablen zu tun.
SQL Injections sollte es seit Jahren eigentlich nur by diesen schrecklichen mysql_BLABLA PHP Krempel geben.

Überall sonst hat man Parameter zur Verfügung und sollte die auch immer benutzen Denn wer Werte in SQLs reinfriemelt frisst auch kleine Kinder! :shock:

[Bernhard Geyer]

Zitat:

Zitat von Elvis

SQL Injections sollte es seit Jahren eigentlich nur by diesen schrecklichen mysql_BLABLA PHP Krempel geben.

Oder ASP.NET. .NET kann zwar Wunderbar mit parametrisierte Abfragen arbeiten, aber wer in seiner Doku primär SQL-Injection-Anfällige Beispiele bringt ist selbst schuld.