Access DB Portieren ohne Access installiert zu haben

[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 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 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 von FAlter:

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 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 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 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 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!

[Bernhard Geyer]

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.