Zugriff auf ACCDB Datenbank

[Alfonso]

Hi,

Unser Delphi Programm nutzt zur Zeit eine Access97 MDB Datenbank. Da wir jedoch die Daten verschlüsseln wollen, soll jetzt auf das ACCDB Format gewechselt werden.
Leider erweist sich das als ein größeres Problem, als einfach nur die Dateiendung und den Provider in Delphi zu tauschen.

Was ich bisher rausbekommen habe:

• Der Treiber ist nicht mehr bestandteil von Windows, so wie es bei MDB war. Man muss den Treiber separat installieren
• Es gibt ein Treiber für 32 Bit und eins für 64bit. Sie dürfen nicht parallel installiert werden, auch nicht parallel zu einer vorhandenen Office Installation (32Bit treiber mit 64Bit Office verboten). Downloadman
• Angeblich muss man mit einem 64Bit Office die accdb erstellen, da man sonst nicht unter 64Bit Windows entwickeln kann

Frage an die Experten unter euch, die so eine Migration schon mal gemacht haben: Könnte ich die obigen Aussagen bestätigen? Wie seid ihr vorgegangen? Kann man bei Innosetup erkennen, welches office installiert ist umd das richtige Installationsprogramm zu starten? Kann man in Innosetup erkennen, ob überhaupt ein Treiber installiert ist? Wie habt ihr den Zugriff in Delphi realisiert - Über TADOConnection? Welche Providerstring habt ihr benutzt?

Ich habe leider noch nicht geschaft mich zu verbinden, da ich noch nicht die Treiber installiert habe (will erstmal klarheit haben).

Gruß und danke
Alfonso

[Bernhard Geyer]

Deine Probleme sind genau der Grund wieso man bei einer Lösung ohne Installation nie hätte auf MS Access setzen dürfen.
Für MS ist die Access-Engine (also Stand-Alone-Lösung) mehr oder minder nur noch eine lästige Altlast. Du kannst davon ausgehen das es in die nächsten Jahre nicht einfacher wird diese zu verteilen.

Kannst du evtl. auf eine ander embedded DB wechseln (Ich weiß - wird viel Aufwand sein).

[jobo]

Ich würde mich Bernhard Geyer anschließen.
Als Lösung wäre wahrscheinlich ein "Schwenk" auf SQL Server das kleinste Übel.

Was mich etwas stutzig macht an der Frage "..da wir die Daten verschlüsseln wollen.."
Das klingt sehr pauschal und Rechenschaft muss Du dazu natürlich nicht ablegen. Aber interessant (wegen des möglicherweise resultierenden Aufwands) ist schon, was eigentlich erreicht werden soll.

[Alfonso]

Hallo, danke für eure Antworten und Vorschläge Access zu verlassen. Ein Schwenk auf eine andere Datenbank steht momentan nicht zur Diskussion.
Ich will bei Access bleiben und theoretisch müsste es auch gehen.
@jobo: Wenn man in Access ein Passwort über die Datenbank legt, werden die Daten automatisch verschlüsselt abgelegt.

Wer hat Erfahrung mit ACCDB und Delphi?

[jobo]

Zitat:

Zitat von Alfonso (Beitrag 1402754)

@jobo: Wenn man in Access ein Passwort über die Datenbank legt, werden die Daten automatisch verschlüsselt abgelegt.

Ja, geschenkt, ich meinte den Aufwand, den Du nun gerade damit hast, überhaupt die Umgebung dafür zu schaffen.

[KodeZwerg]

*sicherheitsbedenken entfernt*

[Aviator]

Zitat:

Zitat von KodeZwerg (Beitrag 1402770)

Ich glaube nicht dass das so ist
Schau mal hier wie Sicher Access ist.

Ich glaube du solltest dir mal angewöhnen alles durchlesen und nicht immer bei jedem kleinen Stichwort irgendeinen nutzlosen Link in den Raum werfen. Das was du geschrieben hast hat rein gar nichts mit dem Vorhaben des TE zu tun. :roll: :!:

[KodeZwerg]

Sind Sicherheitrisiken auszublenden korrekter? Ok, dann Entschuldige ich mich und werde meinen Beitrag entfernen.

[Alfonso]

Hallo KodeZwerg,

dein Hinweis war in soweit richtig, als das genau der Grund ist, warum ich von MDB auf ACCDB will. Diese Tools zum entsperren von MDB Dateien funktionieren nicht mit ACCDB.

[KodeZwerg]

ot

Zitat:

Zitat von Alfonso (Beitrag 1402780)

Diese Tools zum entsperren funktionieren nicht mit ACCDB.

Bitte Verzeih das ich nochmal hier schreibe, an den TE, schau mal selber bei accdb password recovery nach, da finde ich viele ACCDB entsperr/zeige_PW Tools. Falls Sicherheit oben auf der Agenda steht, teste Dich da mal durch.

edit
Ps: Wenn es sich um Bruteforce handeln sollte, ignorier meine Bedenken!
/ot

[Bernhard Geyer]

Zitat:

Zitat von KodeZwerg (Beitrag 1402783)

ot

Zitat:

Zitat von Alfonso (Beitrag 1402780)

Diese Tools zum entsperren funktionieren nicht mit ACCDB.

Bitte Verzeih das ich nochmal hier schreibe, an den TE, schau mal selber bei accdb password recovery nach, da finde ich viele ACCDB entsperr/zeige_PW Tools. Falls Sicherheit oben auf der Agenda steht, teste Dich da mal durch.

So wie ich das sehe erfolgen die Angriffe als Brute Force attacke mit (gebräuchlichen) Passwortlisten.
Wenn man ein möglichst langes PW nimmt dürfte das PW-Knacken ziemlich lange benötigen.

[MichaelT]

Zu Innosetup. Einfach in der Registry nachsehen. (Google und du wirst fündig grad auch im Zusammenhang mit Innosetup).

Zu der Umstellung: Soviel ich mitbekommen habe, aber das ist lange her und betroffen war ich auch nicht*), arbeitet sofern überhaupt jemand während der Migration mit 'Komprimieren' und mit dem neuen Dateityp abspeichern.

*) Ich war davon nicht betroffen, da ich keinen kenne der Access hat und rein rechtlich ist (resp. war damals der Stand und warum soll es heute anders sein) eine Access Lizenz (nicht zwingend installiert) eine Voraussetzung usw...

Ich sah am Netz aber seit 2010 wieder mal Beispiele über

a) Mit dem richtigen Connect String verbinden startet die Migration oder ähnlich diesem
b) programmatisch bspw. in C++.

Ich persönlich habe nie mit *.mdb Dateien gearbeitet außerhalb von Access selbst. Die haben tatsächlich ihre Vorteile da die Engine SELECT * auf alles solange es nicht zuviel ist durchaus gut kann, aber dahinter ...

Ganz zu Beginn blieben ob der Instabilität der Shares (damals ... als Windows noch jung war) Sperrdateien hängen. Das hat mich sehr bald bewogen auf Alternativen (ala DBISAM oder so) umzusteigen und SQL Server oder LocalDB (Express, LocalDB) gab es nicht.

Die Entsprechung zum dem DAO und Jet Engine Zugriff auf Access Dateien wäre schon seit (gut/schwach) 10 Jahren in etwa ein lokaler SQL Server (Local DB). Ob der heute noch angedacht ist einfach mit Windows ausgeliefert zu werden ... wissen die Besucher in diesem Forum besser. Aber der wäre eher die exaktere Entsprechung.

Zitat:

Zitat von Alfonso (Beitrag 1402725)

Alfonso

[KodeZwerg]

ot

Zitat:

Zitat von Bernhard Geyer (Beitrag 1402786)

So wie ich das sehe erfolgen die Angriffe als Brute Force attacke mit (gebräuchlichen) Passwortlisten.

Danke fürs Lesen, ich hatte vorhin nicht wirklich Zeit mich damit zu Beschäftigen, dann ist er ja auf dem Besten Wege und brauch auch keine Bedenken haben was die Sicherheit betrifft, ich jedenfalls habe keine mehr, sehr gut, Danke!

Ps: Länge ist nicht ganz Ausschlaggebend, Zahlen/Buchstaben/Sonderzeichen Kombination das macht Sicherheit aus finde ich.
/ot

[mkinzler]

Zitat:

Ps: Länge ist nicht ganz Ausschlaggebend, Zahlen/Buchstaben/Sonderzeichen Kombination das macht Sicherheit aus finde ich.
/ot

Doch bei brute force Angriffen ist die Länge sehr wohl ausschlaggebend