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

Also bis jetzt hat noch keiner geantwortet.
Ich wollte mich nochmal in Erinnerung mit der Frage bringen.

Hi,
warum willst Du es den ohne die Sachen einbinden?
BisDann

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

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

Zitat von AsterixAoH

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.
Was zur ADODB

Zitat von broetchen

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 :

Zitat von broetchen

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

Hättest Du den Thread gelesen, würdest Du was zur ADODB erfahren (ab 4. Post)
und dort auch Links finden.

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

Zitat von cosmochaosmaker

Zitat:
Zitat von broetchen
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?

Hat Norbert schon recht gut beantwortet
Wird sich nicht wirklich machen lassen, da Microsoft kaum die Access-Datenstruktur herausgeben wird.

@Asterix:
Was für Daten willst du abspeichern?

mfg broetchen

Zitat von broetchen

Hat Norbert schon recht gut beantwortet
Wird sich nicht wirklich machen lassen, da Microsoft kaum die Access-Datenstruktur herausgeben wird.

Genau das hab ich mich auch gefragt.

Zitat von AsterixAoH

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.)

Das minimalistischste was ich mir darunter vorstellen könnte währe XML
Aber warum versuchst Du die Welt neu zu erfinden wo es doch so viele verschiedene DB provider gibt?
Und ich find die ADODB (lassen wir mal deine Vorgaben ausser acht) kommt einem schon sehr entgegen,
da sie wie gesagt ne menge DBs ohne große Vorraussetzungen lesen und scheiben kann.
Die OleDB hingegen kenn ich nicht und kann daher auch nichts weiter dazu beitragen.

Ich würd den Vorschlag vom Norbert beherrzigen und mir mal genauer Gedanken,
bezüglich der Vorgaben machen. Sie könnten die Umsetztung der Problemlösung,
signifikant beeinflussen.

MfG, cosmo

Zitat von AsterixAoH

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.)

Hi.

du könntest auch auf eine Firebird Datenbank zurückgreifen.
Kannst als Server betreiben, oder in deine Applikation einbetten.

Ich spiele mich gerade mit dieser Datenbank ein wenig herum, und bin sehr zufrieden mit ihr. Vorallem weil sie Stored Procedures unterstützt..

dotnetfirebird.org

Firebird Can Be Easily Embedded
Die download-Links stimmen auf der Seiten nicht, einfach links im Menü auf Download klicken. Den Server musst du nicht installieren, es reicht wenn du den DataProvider hast, und die Embedded-DLL.

MfG,
Alex

Hallo zusammen,

zu broetchen :

Zitat von broetchen

Was für Daten willst du abspeichern?

u.a. sollen Mails gespeichert werden.

zu cosmo :

Zitat von cosmochaosmaker

Das minimalistischste was ich mir darunter vorstellen könnte währe XML

Das ich nicht gleich darauf gekommen bin
Aber auch ein wenig zu häftig.

zu Alex :

Zitat von Alexander Schuc

du könntest auch auf eine Firebird Datenbank zurückgreifen.
Kannst als Server betreiben, oder in deine Applikation einbetten.

Genau sowas habe ich gesucht. Keine Installation einer DB o. ä. erforderlich. Muss mich jetzt erstmal damit beschäftigen, aber das scheint es zu sein.
Also hat unser Brainstorming (richtig geschrieben?) doch was gebracht. Einer weiß immer was.
Dank' Dir Alex. Und den anderen Leuten natürlich auch

Die Firebird-DB scheint eine Weiterentwicklung von MySQL zu sein. Sie hat viele Features davon.

Asterix

Zitat von AsterixAoH

Die Firebird-DB scheint eine Weiterentwicklung von MySQL zu sein. Sie hat viele Features davon.

Bitte.

Firebird ist ein Abkömmling von Borlands Interbase und hat mit MySql nichts zu tun.
Das es viele der Funktionen hat, liegt daran das es SQL Standards gibt.
Firebird hält sich an SQL 92 und kann Teile von SQL 99.

Wenn du Probleme zu Firebird hast, mach einfach nen Thread dazu auf. Von einem User weisst nun ja, das er auch Firebird benutzt.
Bevor du was schreibst, durchsuch aber einfach mal diese Seite. Dort steht einiges.