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.
