SqlLite Datenquelle im VS hinzufügen

Hallo,

ich möchte ein Programm schreiben, das eine lokale Datenbank verwendet. Ich wollte dies zuerst über Serialization lösen, aber da die Daten wahrscheinlich doch umfangreicher werden, fällt das raus.

Jetzt dachte ich daran das ganze mit dem EF und einer SQLite-Datenbank umzusetzen. Nun habe ich über den Nuget Package Manager "System.Data.SQLite" installiert.

Ich dachte Nuget richtet mir das alles so ein, dass ich eine SQLite-Datenquelle auswählen kann. (siehe Bild) Leider fehlt der Eintrag.

Meine Frage: Wie kann ich SQLite an dieser Stelle hinzufügen?

Hallo stuffle,

Du kannst die Datenbank ohne den Assistenten einrichten und öffnen.

Ich selbst habe den Assistenten zur Datenbankgenerierung noch nie benutzt.

Grüße Bernd

Falls Du mit einer Express-Edition von VS arbeitest, bleibt Dir sowieso gar nichts anderes übrig:

Zitat von: FAQs zu System.Data.SQLite
(4) What versions of Visual Studio are supported?
... The design-time components are no longer supported for the Express editions due to licensing restrictions.

Ob (für Professional- und bessere Versionen) die Design-Komponenten in den NuGet-Paketen mit enthalten sind oder ob man da die Downloads von system.data.sqlite.org braucht, wird mir beim Durchlesen der Beschreibungen nicht klar.

Aber selbstverständlich hat BerndFfm damit recht, dass das alles bestenfalls Komfort, aber keineswegs nötig ist.

Danke für die schnellen Antworten!

@BerndFfm: Aber wie? 😃 Macht man das in der App.config unter "<connectionStrings>"? Dort gibt es einen Unterpunkt "provider=System.Data.SqlServerCe.3.5".
Muss ich nur diesen in System.Data.SqlLite ändern? Ich stehe da voll auf dem Schlauch...

@bb1898: Ich habe die Ultimate-Version. Ich habe auch schon von der Seite system.data.sqlite.org die Installationsdateien runtergeladen und installiert. Vllt habe ich da ja auch Fehler gemacht.

Aber wenn das alles unnötig ist und man das per Hand machen kann, dann reicht mir das auch. Ich brauche nur ein paar Informationen, an welchen Stellen ich etwas anpassen muss.

Aber wie? System.Data.SQLite
Der Rest ist dann das übliche. Connection, DataAdapter, Command....

System.Data.SQLite exe Download

Hier der Link, der mit VS2010 funktioniert, falls jmd das gleiche Problem hat. Habe es eben nochmal probiert und jetzt geht es.

Ich habe jetzt aber folgendes Problem: Die Datei, in der die Daten reingeschrieben werden sollen, bleibt leer.

Grund: Es existieren noch keine Tabellen in der Datei. Dazu muss ich ja das T-SQL-Skript ausführen, welches mir das Entity-Framework für das Model liefert.

1. Ich weiß nicht, wo ich dieses T-SQL-Skript ausführen soll.
2. Würde ich das Model viel lieber so einstellen wollen, dass nicht vorhandene Tabellen automatisch erstellt werden. Ich kann ja später auch nicht jedes mal vom Anwender meines Programmes erwarten, dass er die Datenbank-Datei erstellt und anschließend das T-SQL-Skript ausführt. Gibt es die Möglichkeit einer automatischen Tabellen-Erstellung?

Edit: Hab nochmal ein wenig gelesen...es ist wohl unumgänglich, dieses T-SQL-Skript / DDL-Skript auszuführen, weil dadurch ein Schema für die Datenbank in der Datei erzeugt wird. Das heißt man muss diese "Vorgefertigte Datenbankdatei" auf die das Skript angewendet wurde irgendwie als "Vorlage" für den Anwender mitliefern. Also wenn eine neue Datenbankdatei benötigt wird, dann muss diese "Vorlage" vom Programm kopiert werden. Anschließend kann mit der Kopie gearbeitet werden.

In SQLite erstellst Du Tabellen praktisch auf die gleiche weise wie in anderen Datenbanken.
Mit der Datenbankdatei verbinden und einfach Tabellen erstellen.
Hier eine Übersicht von Befehlen die von SQLite verstanden werden.

Vielleicht hilft es wenn Du dir erst mal in Ruhe die SQLite Seite etwas durchstöberst. Das sollte an sich die meisten deiner Fragen beantworten.

Super danke für diese Übersicht. Ist auf jeden Fall nützlich.
Ich hab mir das aber anders gedacht. Ich wollte ja das Model mit EF erstellen. Und mit diesem Model alle Datenbankzugriffe durchführen, OHNE SQL-Befehle zu verwenden.

hmmm, ich werfe jetzt einfach ORM (object-relational mapper) (z. B. NHibernate (FluentNHibernate noch dazu)) als Stichwort in den Raum.

hmmm, ich werfe jetzt einfach ORM (object-relational mapper) (z. B. NHibernate (FluentNHibernate noch dazu)) als Stichwort in den Raum.

Dafür wäre ja das Entity Framework da. Ich werfe mal "Code First" in den Raum und dazu einen Einstiegs-Link: Entity Framework Code First to a New Database. Das erlaubt die Erstellung der kompletten Datenbank im Code, bei Bedarf auch mit Daten für den Anfang.
Ich habe das selber noch nicht mit SQLite ausprobiert, sehe aber keinen Grund, weshalb es nicht funktionieren sollte. So weit ich sehen kann, ist NHibernate möglicherweise besser als Entity Framework, aber ganz bestimmt nicht besser dokumentiert. Vom Gegenteil lasse ich mich sehr gern überzeugen.

So weit ich sehen kann, ist NHibernate möglicherweise besser als Entity Framework, aber ganz bestimmt nicht besser dokumentiert. Vom Gegenteil lasse ich mich sehr gern überzeugen.

Mit solchen Aussagen wäre ich in beide Richtungen vorsichtig.
Beides hat seien Vor- und Nachteile; NHibernate stammt halt von Java ab und das merkt man auch; sowohl im Code wie auch in der Doku.

@bb1898: Ist es nicht egal, ob ich das Model im Code oder im Designer erstelle? Das Ergebnis ist doch das Gleiche oder?

Mein Problem ist nur folgendes: Wenn ich nun das Model habe, dann muss ich ja irgendwie eine Datei erzeugen, wo die Daten des Models gespeichert werden. Im VS ist das ja kein Problem. Bzw habe ich mir jetzt ein Tool besorgt, mit dem ich eine SQLite-Datei erstellen kann. Damit kann ich dann auch ohne Probleme mit dem Entity Framework arbeiten.

Nun ist die Sache aber, dass mein Programm nicht nur mit einer mitgelieferten Datenbank arbeiten soll. Auch nicht mit einer zentralen Datenbank. Man soll sich mehrere Dateien erstellen können, wo die Daten gespeichert werden. Wie es zum Beispiel bei Excel der Fall ist. Da speichert man ja auch nicht alle "Zelleninformationen" in einer Datei, sondern will für verschiedene Kontexte verschiede Dateien haben.

Ich glaube so ganz verstanden, wie eine Datenbank funktioniert, hast Du nicht, oder?

Generell ist es empfohlen Code First beim EF zu verwenden (statt Db First oder Model First).
Das liegt daran, dass die meisten Features nur bei Code First unterstützt werden; warum weiß kein Mensch. Ist halt so aus den verschiedenen Entwicklungssträngen entstanden, die so langsam wieder zusammen finden.

Erstell Dir also Deine Modelle alle im Code; man nennt sowas POCOs.
Das EF erstellt Dir die DB und die Tabellen, wenn sie noch nicht vorhanden sind. Und seit EF 5 wird auch eine Schema-Änderung durch CodeMigrations unterstützt; Deine Disziplin bei der Schema-Pflege vorausgesetzt.

Was auf keinen Fall funktioniert ist Dein Excel-Vorhaben; so ticken Datenbanken nicht (Gott sei Dank!) und von diesem Gedanken musst Du ganz schnell wieder weg kommen.

Ich vermute, dass Du auf eine Mandanten-Schicht hinaus willst: jeder Mandant hat die eine eigene Datenbank; das Schema ist aber jeweils identisch.
Wenn Du mehrere Dateien für den gleichen Kontext haben willst: das ist unüblich, riskant (Relationen funktionieren hier nicht) und wahrscheinlich geprägt von einem falschen Verständnis von Datenbanken.

Wenn es "nur" darum geht SQLite durch einen ORMapper zu benutzen würde ich auf jeden Fall SQLite-Net vorziehen.

Danke für den Hinweis mit Code First. Ich dachte dieses Code-First ist das, was im Hintergrund vom Designer passiert... damit muss ich mich nochmal beschäftigen...

Ich hab mich denke ich falsch ausgedrückt. Der Kontext soll schon nur von EINER Datei gespeist werden. ABER diese Datei soll geändert werden können; Sozusagen wählt man einen anderen "Pfad" zu der Datenbankdatei. Untereinander sollen diese Dateien natürliche keine Relationen aufweisen!

Hintergrund: Das Programm soll zum einen auf eine Datenbank zugreifen, an der mehrere Mitarbeiter arbeiten. Zum anderen sollen aber die Mitarbeiter auch bei sich lokal auf dem Rechner eine Datei erstellen können, in der die Daten bearbeiten werden können.

Du solltest Dich ganz ganz dringend mit den Grundlagen beschäftigen; ansonsten ist unsere Hilfe für die Katz.
Lokale Datenbankdateien sind in erster Linie nicht dafür gedacht, dass mehrere Anwendungen damit arbeiten. Dafür gibt es Datenbankserver, die sich auch um die Synchronisation etc kümmern.

Wenn Du dann noch ein lokales Caching haben willst, was Du beschreibst, sind wir auch schon deutlich über de n fortschrittliche Fähigkeiten. Und ich will Dir nicht zu Nahe treten aber ich fürchte das ist deeeutlich über Deinem aktuellen Wissensstand.
Befasse Dich also in erster Linie mit der Kommunikation zu einem zentralen Datenbankserver (MSSQL Express) und dann, wenns wirklich nötig ist, kannst Du lokale Synchronsation hinzufügen.
Aber das ist alles nicht "so mal kurz" erklärt oder gar umgesetzt....