✔ MS-Access-DB ohne ODBC einbinden?

[Asterix-Ac]

Hallo zusammen,

zu Cosmo & Norbert : Also, wenn ich mich jetzt ( oder jetzt bald ) in die Materie einarbeiten soll, dann so einfach wie möglich. Wenn es nicht anders geht, dann auch XML, aber vorher nicht. Hatte letztes Jahr schonmal das Vergnügen in XML reinzuriechen. Aber es bleibt ja nicht bei XML.... da kommt ja noch DTD, XSL und XSLT hinterher und das ist mir für eine DB zu häftig. Wenn ich mal viiiiiiiiiiel Zeit habe, dann können wir gerne darüber reden
Grundsätzlich habe ich nichts gegen XML aber die Zeit schon.

zu Norbert : Die Seite kannte ich noch nicht ... danke Dir.
Meine Projekte sind bisher immer ohne DB ausgekommen und nun geht es los 'schwitz'

Asterix

 

[Norbert Eder]

Lol, XSLT hat mit einer "fuzzi XML-DB" nix zu tun. Du willst die Daten zu 99,9% nicht transformieren. Genausowenig brauchst vorerst anderes. Also nicht gleich komplizierter machen als es tatsächlich ist.

Ähm und Access is keine Datenbank Das ist ein Krampf, das wars dann auch schon wieder. Wenns gratis und gut sein soll, dann greif auf die MSDE zurück, die ist im Endeffekt der MS-SQL-Server mit ein paar Einschränkungen, funktioniert für kleinere Projekte aber super und ist gratis.

Ausserdem kannst da per ADO.NET (SqlClient, SqlCommand etc.) ganz gut drauf zugreifen. Die MSDE muss dabei halt installiert werden.

 

[Asterix-Ac]

Hallo Norbert,

zu XML : also wie gesagt, ich hab' da nur mal reingeschaut und das ist ein Jahr her. Also, kaum Ahnung mehr

zu Access : da kann ich Dir nur beipflichten. Was anderes ist das auch nicht Hatte oft genug das Vergnügen

Die MSDE ist sicher gut, ich verwende sie auch. Aber für DAU's (Dümmste Anzunehmende User) sind 2 Installationen zu viel
Die Applikation soll einfach gehalten werden. Deswegen habe ich mich für die Firebird-Variante entschieden, die einfach in das vorhandene Projekt mit eingebunden werden kann. Schau auf den Post von Alex.
Ich weiß nicht, wie Du darüber denkst, aber ich finde, sowas ist einfach genial.

Marcus

Nachtrag : Ausserdem hat der Firebird den Datentyp BLOB, den ich in der MSDE schwer vermisse.

 

[Norbert Eder]

Nun, meine Meinung dazu:

Du machst ein Setup in dem einfach die MSDE und deine Anwendung isntalliert werden. Damit ist es einfach für den Anwender und für dich auch nicht unbedingt mehr Aufwand.

Die Firebird hat Blob und MSDE nicht:
Das ist natürlich ein Argument für die Firebird. Merke: Blobs solltest am besten erst gar nicht angreifen. Warum? Vermutlich würdest Blobs zum Speichern von Dateiinhalten verwenden. Dateien gehören ins Filesystem und nicht in eine DB. Ist nur langsam und bläht dir deine Datenbank auf.

 

[Asterix-Ac]

Hallo Norbert,

entschuldige bitte, aber ich bin nicht unbedingt ein Freund von den Studio-Installationen. Die ziehen immer nur Murks hinter sich her (oft genug probiert). Ich bevorzuge Setup-Factory 6.
Dort hat der Anwender schon das dotnet als Setup im Setup, falls es nicht installiert ist - und dann noch die MSDE? Das ist zu viel des Guten
(Setup-Factory 7 hat dotnet auch als runtime drinne - automatische Installation)

Zu den Blobs : Mal angenommen, Du möchtest Mails speichern, die auch Anhänge haben könnten. Weißt Du wie groß die werden? Nö. Da alles Base64 kodiert ist, ist es praktisch. Speichere die ganze Mail, wie sie ist, in einem Blob. Da gehört nichts in ein Filesystem. Oder hast Du Microsoft Outlook schonmal was aus der pst ins Dateisystem auslagern sehen? Ich nicht. Dafür hat MS den MAPI-Connector.

Sicher hast Du recht, dass das die DB etwas aufbläht, aber besser so, als sich ständig die Sachen von Verzeichnissen zusammenzusuchen.
Ich habe in der Firebird-Doku gelesen, dass das Dateisystem keinen Zugriff auf die DB hat, wenn das DB-File geöffnet ist. Großer Vorteil gegenüber Dateien im Dateisystem, die von DAU's behandelt werden können.

Marcus.

 

[Norbert Eder]

Hallo Norbert,

entschuldige bitte, aber ich bin nicht unbedingt ein Freund von den Studio-Installationen. Die ziehen immer nur Murks hinter sich her (oft genug probiert). Ich bevorzuge Setup-Factory 6.
Dort hat der Anwender schon das dotnet als Setup im Setup, falls es nicht installiert ist - und dann noch die MSDE? Das ist zu viel des Guten
(Setup-Factory 7 hat dotnet auch als runtime drinne - automatische Installation)

Wo entsteht da "Murks"? Mit dem Setup-Project kann ich genauso alles installieren was ich will und da ist nichts zuviel des Guten. Ob ich da jetzt die Installation des Frameworks (bzw. die Überprüfung ob es bereits installiert ist) reinknall, oder ein weiteres Setup ist vollkommen egal.

Zu den Blobs : Mal angenommen, Du möchtest Mails speichern, die auch Anhänge haben könnten. Weißt Du wie groß die werden? Nö. Da alles Base64 kodiert ist, ist es praktisch. Speichere die ganze Mail, wie sie ist, in einem Blob. Da gehört nichts in ein Filesystem. Oder hast Du Microsoft Outlook schonmal was aus der pst ins Dateisystem auslagern sehen? Ich nicht. Dafür hat MS den MAPI-Connector.

Das Argument mit MS Outlook ist spitze. Outlook als Maß aller Dinge herzunehmen ist ein kleiner aber feiner Fehler. Nimm dir die wirklich sauberen Implementierungen als Vorbild, nicht Wald-und-Wiesen-Solutions.

Base64 bläht dir deine Daten um 33% auf. D.h. du verschwendest mehr Platz als es unbedingt notwendig wäre. Ich bestreite nicht, dass BLOBs praktisch sind, aber die Lösung mit Blobs ist eindeutig nicht sauber und vor allem nicht die beste. Ja, ich weiß wie groß Anhänge werden können, deswegen würde ich auch nie auf die Idee kommen mir das in eine DB knallen zu wollen.

Annahme: Attachment hat 30 MB, dann speicherst du mal so locker eben 40 MB an Daten in deine DB und hast hier aber nur dein Attachment, die Randdaten mal aussen vor gelassen. Im Filesystem hab ich 30 MB. Ersparnis: 40 MB. Wenn ich jetzt Angst habe, ich kann keine Volltextsuche mehr machen (unter der Vorraussetzung, dass ich die Filetypen der Attachments auch "lesen"), dann kann ich diese immer noch extern indizieren und ablagen, was ihmo meist schneller ist, als das über die DB zu regeln.

Sicher hast Du recht, dass das die DB etwas aufbläht, aber besser so, als sich ständig die Sachen von Verzeichnissen zusammenzusuchen.

Wo ist hier das Problem. Das File aus dem Filesystem nachzuladen ist EINE einzige Zeile Sourcecode mehr. Dafür ersparst du dir ne Menge Speicherplatz in deiner DB, was natürlich deine DB schneller macht. Bei 10.000 Mails in deiner DB macht das dann vermutlich pro Zugriff einige Sekunden aus. Was dir dann sicherlich auf den Hammer gehen wird.

Ich habe in der Firebird-Doku gelesen, dass das Dateisystem keinen Zugriff auf die DB hat, wenn das DB-File geöffnet ist. Großer Vorteil gegenüber Dateien im Dateisystem, die von DAU's behandelt werden können.

Der DAU schießt sich sowieso den gesamten Rechner ab und somit sind sowieso alle Daten verloren. Also was bringt es dann diese in die DB zu schreiben? Davon abgesehen legt jeder saubere und brauchbare Mailclient die Attachments ausserhalb der verwendeten DB ab.

Im Endeffekt musst es sowieso so machen, wie du es für richtig erachtest. Wenn du nicht auf mich hören willst, dann tu es nicht, aber irgendwann wirst du dir denken: "Autsch, er hatte doch recht ... ".

 

[Asterix-Ac]

Hallo Norbert,

Ob ich da jetzt die Installation des Frameworks (bzw. die Überprüfung ob es bereits installiert ist) reinknall, oder ein weiteres Setup ist vollkommen egal.

also ich arbeite mit dem Studio 2002 und ich habe es bis heute noch nicht geschafft, dort eine andere Softwareinstallation zu integrieren als das dotnet selber.
Die Setup-Factory kann auch nur exe's mit einkompilieren, aber der Vorteil liegt darin, dass durch die eigene Programmsprache das Setup sehr fein gesteuert werden kann. Solltest Dir mal anschauen. Ist von Indigorose .

Das Argument mit MS Outlook ist spitze. Outlook als Maß aller Dinge herzunehmen ist ein kleiner aber feiner Fehler. Nimm dir die wirklich sauberen Implementierungen als Vorbild, nicht Wald-und-Wiesen-Solutions.

*lol* Nein. MS Outlook ist nicht das Mass aller Dinge, aber die Technik, die dahinter steckt, begeistert mich im gewissem Sinne. Wäre es gut programmiert, hätte Outlook gut werden können. Alles in einer DB anstatt alles überall verstreut zu haben, wie es viele Clients haben. Das kotzt mich an. Möchte man eine Datensicherung machen, haste garantiert die Hälfte vergessen zu sichern. Bei Outlook nicht. Eine Datei. Alles drin, alles drum, alles dran. Fertig. Die Einfachheit begeistert mich, komplex, und doch einfach.

Base64 : Ich weiß nicht... Alles was bei mir ankommt ist Base64. Nenn' mir ein Format, wie man die Daten da 'rein bekommen würde.

Davon abgesehen legt jeder saubere und brauchbare Mailclient die Attachments ausserhalb der verwendeten DB ab.

OK... dann nenn' mir mal 1-2(gute). Also Foxmail macht das nicht und der ist gut.

Im Endeffekt musst es sowieso so machen, wie du es für richtig erachtest. Wenn du nicht auf mich hören willst, dann tu es nicht, aber irgendwann wirst du dir denken: "Autsch, er hatte doch recht ... ".

Also gut : Mir ist zwar gerade ein anderes Projekt dazwischengeworfen worden, aber wenn ich das nun mache und sehe, dass Du Recht hattest, werde ich Dich um Hilfe anbetteln

Marcus

 

[Norbert Eder]

Hallo Norbert,
also ich arbeite mit dem Studio 2002 und ich habe es bis heute noch nicht geschafft, dort eine andere Softwareinstallation zu integrieren als das dotnet selber.
Die Setup-Factory kann auch nur exe's mit einkompilieren, aber der Vorteil liegt darin, dass durch die eigene Programmsprache das Setup sehr fein gesteuert werden kann. Solltest Dir mal anschauen. Ist von Indigorose .

Dann arbeitest auch noch mit Framework 1.0. Solltest eventuell auf 2003 umsteigen. Und wie gesagt, andere Setups reinzupacken ist kein Problem. Haben wir selber so.

*lol* Nein. MS Outlook ist nicht das Mass aller Dinge, aber die Technik, die dahinter steckt, begeistert mich im gewissem Sinne. Wäre es gut programmiert, hätte Outlook gut werden können. Alles in einer DB anstatt alles überall verstreut zu haben, wie es viele Clients haben. Das kotzt mich an. Möchte man eine Datensicherung machen, haste garantiert die Hälfte vergessen zu sichern. Bei Outlook nicht. Eine Datei. Alles drin, alles drum, alles dran. Fertig. Die Einfachheit begeistert mich, komplex, und doch einfach.

Naja, es soll ja auch nicht bedeuten, dass man die Daten wirklich vollkommen verstreut. Aber es kann ja wohl kein Problem sein, wenn man ein Anwendungsverzeichnis hat, in dem alle Daten gesammelt werden.

Base64 : Ich weiß nicht... Alles was bei mir ankommt ist Base64. Nenn' mir ein Format, wie man die Daten da 'rein bekommen würde.

Klar, dass die Mails Base64-Encoded ankommen. Aber wennst die Attachments speicherst, sinds nicht mehr Base64-Encoded und daher auch um einiges kleiner.

OK... dann nenn' mir mal 1-2(gute). Also Foxmail macht das nicht und der ist gut.

- Thunderbird
- The Bat!
- PocoMail
Willst noch ein paar?

Ach ja, und die guten Mailclients haben auch die Möglichkeit die Daten aus dem Client heraus zu sichern. Fürn Thunderbird gibts da meines Wissens ein Plugin und der The Bat! kann das von Haus aus.

Also gut : Mir ist zwar gerade ein anderes Projekt dazwischengeworfen worden, aber wenn ich das nun mache und sehe, dass Du Recht hattest, werde ich Dich um Hilfe anbetteln

Wie gesagt, es hat keinen Sinn dir etwas auf die Nase zu drücken, aber denk zumindest mal darüber nach. Persönliche Präferenzen sollten da hinten angestellt werden. Was macht designmäßig am meisten Sinn, was ist am saubersten und wie kann ihc es einfach erweitern.

Marcus

 

[Christian Kusmanow]

Nur mal so als kleiner Tip am Rande:
[thread=194699]Setup Projekt - Thread[/thread]
[thread=182703]Weitergabeprojekt / Installationspfad - Thread[/thread]

 

[Asterix-Ac]

Hallo zusammen,

ja, ich arbeite noch mit dem 1.0'er. Das 2002 arbeitet ja nicht mit dem 1.1'er zusammen. Und ein neues Studio zu kaufen ist mir zu teuer. Da warte ich bis das 2.0 und das 2005 aus der beta raus ist und sauge mir die kostenlose Variante. Konnte schonmal einen Blick erhaschen und muss sagen ... sehr gewöhnungsbedürftig. Aber mal abgesehen davon, alles was ich brauche, kann das 1.0 auch. Und wenn es etwas gibt, was es nicht kann, kann man sich externe Klassen selber schreiben oder aus dem Inet saugen.
OK, ich glaube Dir, dass Ihr das mit dem Setup's so macht. Ich mache das mit Setup-Factory.

Naja, es soll ja auch nicht bedeuten, dass man die Daten wirklich vollkommen verstreut. Aber es kann ja wohl kein Problem sein, wenn man ein Anwendungsverzeichnis hat, in dem alle Daten gesammelt werden.

Nein, ein Problem sehe ich da drinne sicher nicht. Ich habe mir das halt so toll vorgestellt. Eine Datei. Alles drin. Aber Deine Argumente überzeugen mich .. ich bin nun etwas von meiner Idee und Deinen Argumenten hin- und hergerissen.
Wenn man nun meine Idee verfolgte, könnte man die Daten nicht komprimieren und dann in die DB pumpen? Würde das was bringen?

Zitat von AsterixAoH
OK... dann nenn' mir mal 1-2(gute). Also Foxmail macht das nicht und der ist gut.

Also Thunderbird kenne ich(alter Mozilla-Fan) und The Bat! und PocoMail dem Namen nach.

Ach ja, und die guten Mailclients haben auch die Möglichkeit die Daten aus dem Client heraus zu sichern.

Für eine richrige Datensicherung ist das Quatsch. Wo willste denn die Daten hinsichern? und dann nochmal eine Sicherung mit einem anderen Programm ... alles Quatsch. Bei einer richtigen Datensicherung sicherst Du das ganze MailProgramm mit Anwenderverzeichnis. Das ist ein Durchlauf. Fertig.

Wie gesagt, es hat keinen Sinn dir etwas auf die Nase zu drücken, aber denk zumindest mal darüber nach. Persönliche Präferenzen sollten da hinten angestellt werden. Was macht designmäßig am meisten Sinn, was ist am saubersten und wie kann ihc es einfach erweitern.

Wie gesagt, ich bin zur Zeit zwischen meiner Idee und Deinem Vorschlag hin- und hergerissen und weiß noch nicht, wie ich es verwirklichen werde. Aber Du hast mir gute Richtungen aufgezeigt.

@ Cosmo : Danke. Inno Setup kannte ich schon. ist sehr gut. Habe aber noch nicht mit rumgespielt, da ich bis jetzt immer Setup-Factory benutzt habe, da ich die Sprache bereits kenne.

Marcus.