MS-Access-DB ohne ODBC einbinden?

Asterix-Ac

Erfahrenes Mitglied
Hallo zusammen,

ich bin nicht besonders fitt im ADO.NET. Gibt es eine Möglichkeit eine Access-DB ohne Access und ohne ODBC einzubinden und als DB zu nutzen?

Asterix :confused:
 
Also bis jetzt hat noch keiner geantwortet.
Ich wollte mich nochmal in Erinnerung mit der Frage bringen.
 
Hi,

Das Programm muss auch ohne ODBC lauffähig sein - Solche Rechner gibt es heute auch noch :)
Und ODBC soll auch nicht installiert werden.

Sind Vorgaben, kann ich auch nicht ändern :(

Asterix :confused:
 
Du kannst OleDB nehmen, allerdings weiß ich nicht, ob das ohne installiertem Access läuft.

Wenn du es richtig hardcore machen willst, dann mach es auf Dateilevel und lies die Datei mittels Filezugriff aus ;-)

mfg broetchen
 
AsterixAoH hat gesagt.:
Das Programm muss auch ohne ODBC lauffähig sein - Solche Rechner gibt es heute auch noch
Und ODBC soll auch nicht installiert werden.
Ich bin mir nicht sicher, weil zu lange her,
aber die ADODB braucht meines erachtens kein ODBC und vor allem kein Access.
Ich hab aber bisher minimal auf WIN2000 damit gearbeitet.
[thread=179940]Was zur ADODB[/thread]
broetchen hat gesagt.:
Wenn du es richtig hardcore machen willst, dann mach es auf Dateilevel und lies die Datei mittels Filezugriff aus
Ähm, wie soll ich das jetzt verstehen, broetchen? Kannst das mal näher erörtern?

MfG, cosmo
 
Hallo zusammen,

danke erstmal für die Anregungen.

zu Cosmo : zu ADODE kann ich noch nicht viel sagen, müsste mich erst reinlesen ,aber der Link zum Thead habe ich nicht verstanden, außer das es um den SQL-Server ging.

zu broetchen :
broetchen hat gesagt.:
Wenn du es richtig hardcore machen willst, dann mach es auf Dateilevel und lies die Datei mittels Filezugriff aus ;-)
Erklär' mal ein wenig genauer. Das interessiert mich sehr. Ich bin ein Puurist. Mal schauen, ob ich das raffe :) Genau sowas suche ich -> per Filezugriff auslesen und dann per SQL wie eine Datenbank behandeln.

Asterix :confused:
 
Ich sehe hier ein wenig Aufklärungsbedarf.

Auf Access solltest per OleDb zugreifen und nicht via ODBC, zumal OleDb um einiges schneller ist.

Thema "Access auf Filesystem-Basis":
Hier wirst du dir schwer tun, an die Filedefinition zu kommen. Meines Wissens nach ist die für Access nicht offen, ausser eventuell für Access 2003, aber selbst das wäre kostenpflichtig. Und das wirst du vermutlich nicht wollen. Weiters vergibst du dir dann die Möglichkeit, da mit SQL darauf zuzugreifen. Nun, prinzipiell ginge es schon, aber du müsstest deinen eigenen Provider entwickeln und ich zweifle sehr stark daran, dass du hier das äquivalente Wissen der Microsoft-Entwickler aufbringst um dies zu so umzusetzen, dass du gegenüber der bestehenden Lösungen keinen Geschwindigkeits- bzw. Leistungsnachteil hast. Zusammenfassend: Schlag es dir aus dem Kopf.

Thema "Purist":
Schön, bringt dich aber nicht weiter. Puristen neigen dazu, das Rad zum 10.000sten Mal zu entwickeln. Mit welchem Effekt? Dass die meisten Räder nicht rund laufen. Ergo programmiertechnisches K.O.

Thema "ADO.NET" + Thema "nicht verstanden":
Du machst es dir selbst am einfachsten wenn du dich wirklich informierst. Du kennst ein Kürzel nicht? Oder ein Schlagwort? Nutze Google und schlag es nach. Damit musst du dir nicht alles erklären lassen und baust dir so einen guten Grund-"Wortschatz" auf. Zumal es vor allem auf dem Gebiet der ADO.NET sehr viel freie Literatur im Netz gibt.

Thema "Vorgaben":
Natürlich gibt es Vorgaben. Gewisse Vorgaben machen keinen Sinn. Unabhängig davon ist es sehr wichtig, dass du dich laufend informierst und lernst, lernst, lernst. Warum? Damit du erkennst wann welche Vorgaben unsinnig sind und wann sie sehr wohl sinn machen. Kannst du das nicht, musst du ständig mit Vorgaben arbeiten, die für das Programm/Produkt keinen Sinn machen und nur Einschränkungen mit sich bringen.
 
Hallo zusammen,

zu Cosmo : Du hast Recht. Ich hatte es nicht richtig durchgelesen, was ich nun nachgeholt habe. Das Aber das bringt mich in meinem eigentlichen Vorhaben nicht wirklich weiter. :(
Bin aber nun was schlauer ;)

zu Norbert : OK, Deine Argumente haben mich überzeugt und sind wirklich sinnvoll.
Aber wenn ich zu Microsoft rüberschiele und mir Outlook und die 'pst'-Dateien anschaue, können die das auch. und so eine Lösung suche ich auch. (Ein Programm installieren, aufrufen, läuft - ohne OLEDB, ODBC oder ADODB) Die haben MAPI(das war's doch?).

Meine Frage ist : Wie kann man eine Datenhaltung konstruieren, die ohne Provider auskommt und ASCII und Binärdaten in tabellenartiger Form aufnimmt? (ich meine, Dateianhänge von Mails sind ja eh' schon Base64 kodiert, also in ASCII gewandelt.)

Bin da ziemlich ratlos.

Asterix :confused:
 
Zurück