Hi,

ich habe eine SQL CE 3.5-Datenbank. Ich verwende sie mit Linq-To-SQL. Diese liegt in einem AppData-Unterordner (auf den ich Zugriff habe). Funktioniert wunderbar.
Jetzt gibt es da aber ein Problem:
Anscheinend will SQLCE nicht, dass es aus einem Netzwerkpfad geladen wird (genauer: DFS). In einer Umgebung, in der AppData-Ornder auf ein DFS umgeleitet wird, gibt es folgende Exception bei DataContext.CreateDatabase():

Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: SQL Network Interfaces, error: 26 - Fehler beim Bestimmen des angegebenen Servers/der angegebenen Instanz)

Source der Exception: .Net SqlClient Data Provider

Der Zielordner der Databasefile existiert, sowie Zugriff mit den Standardrechten ist möglich.

Nun denke ich mir, dass es wohl nicht so schlau ist, die DB in AppData zu packen, denn es kommt sicherlich öfters vor, dass die Anwendungsdaten gerne mal (in ein DFS?) umgeleitet werden.

Wohin soll sie aber sonst? In den Programme-Ordner könnte man es wohl nicht packen, denn dann wären sicher wieder Administratorenrechte nötig, um in den eigenen Programme-Ordner zu schreiben bzw. Daten hinzuzufügen/zu ändern.

Jemand eine Idee zur Lösung der Exception oder für einen neuen Speicherort?


nikeee

Hi,

diese Datenbank soll für jeden Benutzer automatisch nach dem ersten Programmstart angelegt werden, da dort für jedem Benutzer spezifische Dinge dokumentiert werden. Diese Anwendung bleibt also nicht nur bei mir, sondern wird auf viele andere Umgebungen skaliert. Von daher wäre es gut, wenn es auch keine Probleme mit DFS-Freigaben hätte.

"C:\myApp" wäre keine schöne Lösung dafür. Der User muss dazu explizit die Zugriffsrechte auf den Ordner vergeben. Außerdem geht dann die Multiuser-Fähigkeit verloren.

Es muss keine Netzwerklösung sein. Es sollte dateibasiert und architekturunabhängig (sprich: "AnyCPU") sein. Der User sollte nicht extra einen SQL-Server dafür installieren.
Ich möchte einfach nur für jeden (Windows-)Benutzer eine eigene Datenbank anlegen, in der z.B. diverse Statistiken festgehalten werden. Da scheint mir ein datebasiertes Format am geeignetsten - oder nicht?

Mit SQLite habe ich nicht so schöne Erfahrungen gemacht, denn AFAIK sind die SQLite-Assemblys immer noch nicht AnyCPU bzw. nur x86/x64 separat.
Ich meide es grundsätzlich, "verschiedenbittig" kompilierte Versionen meiner Anwendung herauszubringen. Am Ende soltle eine AnyCPU-Version rauskommen, also keine x86-Version, die auf 64-Bit Rechnern im Subsystem läuft oder eine, die explizit für 64-Bit kompiliert ist.

Warum ich mich für SQLCE entschieden habe? Weil es im Framework mitgeliefert wird, und ich aus dem oben genannten Grund die Anwendung als AnyCPU verteilen kann.

Gibt es denn wirklich nichts anderes?

Kagurame schrieb:

Naja, wenn es benutzerspezifische Daten sind, die für jeden User einzeln gelten, warum dann DFS? Reicht es dann nicht unter eigene Dateien bzw. AppData?

In der Umgebung ist es so, dass AppData auf ein DFS umgeleitet wird. Daran ist nichts zu ruckeln. Also %appdata% führt auf eine DFS-Netzwerkfreigabe. Das ist ja, wie oben schon erwähnt, nicht immer der Fall (eig. nur in größeren Netzwerken). Die Anwendung sollte dadurch aber nicht inkompatibel werden. Bei "normalen", lokalen Anwendungsdaten, wie es oft bei Home-Systemen der Fall ist, funktioniert es einwandfrei.
Wenn jemand aber das Programm ausführt, und die Ordner auf eine Netzwerkfreigabe umgeleitet werden (das kann ich ja nicht wissen), dann kommt es an der Stelle anscheinend zu Inkompatibilitätsproblemen.

Kagurame schrieb:

Dann solltest du in dem Fall (soltest du sowieso bei einer Datenbank) den Speicherort der Datenbank konfigurierbar machen, was aber dennoch nicht ausschließt, das die DB im Netzwerk landet.

Das möchte ich auch Vermeiden, denn die Datenbank soll ja beim (ersten) Programmstart angelegt (und auch initialisiert) werden.

Gibt es wirklich nix dafür? Am liebsten würde ich ja einfach die Exception loswerden, dann appdata ist IMO ja dafür da.

@ErfinderDesRades: Naja, UNC-/Netzwerkpfade kennzeichnen sich duch ein "\\" am Anfang. Außerdem gibt es sicherlich bei der URI-Klasse ein Property dafür.

Aber was willst du da modifizieren? Ich gebe nirgendswo einen ConnectionString an, wie es normalerweise üblich ist. Alles, was ich mache, ist eine Instanz eines DataContexts zu erstellen. Im Konstruktor wird dann der Pfad übergeben:
msdn.microsoft.com/de-de/library/bb350721.aspx
Dort übergibt man entweder den Pfad zur SQLCE-Datei oder einen ConnectionString. Könnte man also statt einem Pfad einen modfizierten ConnectionString übergeben?

Wenn man dann CreateDatabase() aufruft, gibt es die Exception, die ich oben geschildert habe.

Wenn ich wüsste, ob es ein Netzwerkpfad ist, oder nicht - was soll dann gemacht werden?

Ich gehe davon aus, dass der Pfad so bleibt. Ich probiere es mal kurz aus.
@ErfinderDesRades: Ja, wie vermutet bliebt der Pfad gleich. Also in etwa so:

Diese Methode möchte ich wirklich vermeiden. Das wäre dann ja schon eher Patchwork. ;)

Also gibt es keine Möglichkeit dafür?

Sehr schön. Dafür ist LocalAppData also da. :)

Es gibt dieses Verzeichnis zwar nicht auf Windows XP, aber ich glaube für diesen kleinen Benutzerkreis kann ich das auch auf dem normalen AppData lassen.

Ich werde es mal ausprobieren. :)

Ich habe es nun mit LocalAppdata ausprobiert. Der Pfad ist jetzt lokal, wie erwartet. Jedoch bekomme ich den gleichen Fehler.
Der Pfad sieht in etwa so aus:

Der Domänenbenutzer hat Vollzugriff auf das Verzeichnis. Außerdem existiert der Ordner Anwendungsname und der entsprechende Unterordner.

Fehler:

Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: SQL Network Interfaces, error: 26 - Fehler beim Bestimmen des angegebenen Servers/der angegebenen Instanz)

Edit:
Auch, wenn ich die DB auf dem Testrechner auf einen Pfad lege (z.B: C:\wat\db.mdf) gibt es diesen Fehler. Dabei hat der benutzer volle Rechte auf den Ornder.

Der Fehler ist trotzdem der gleiche. Was soll das? Ich verstehe es nicht. Mache ich irgendetwas grundsätzlich falsch?

Morgen,

vielen Dank für deine Antwort.

SoftDevIT schrieb:

Da der Zugriff auch lokal nicht funktioniert und die Fehlermeldung besagt, dass er den SQLServer nicht findet, scheint es KEIN Problem mit dem
Pfad zu sein, sondern ein generelles SQLServer/VB Problem zu sein.

Das ist ja das Einzige, was noch über bleibt.

SoftDevIT schrieb:

Versuche mal auf dem TestPC die notwendige Dot.Net x.y Version und eventuell die SqlCE Variante neu zu installieren. Wenn Du gar nicht weiter kommst, installiere Dir das VStudio dort und probiere, ob es dann läuft - VStudio installiert so, dass man auch mit SqlCE arbeiten kann.

Auf dem Testrechner ist bereits Visual Studio 2010 (SP1) und .NET 4.0 (Client Profile + Extended) installiert. SQL Server Compact 3.5 (SP2) ist auch installiert. Genau deshalb bin ich ja ratlos.

Beide PCs sind praktisch Entwicklungs-PCs. Einer davon befindet sich in einer Domäne und hat umgeleitete Ordnerpfade (wie hier beschrieben). Der andere PC ist praktisch nur ein Home-PC mit VS drauf. Der Quelltext ist beim Debuggen der gleiche, denn die Projekte werden auf beiden PCs über einen TFS aktuell gehalten. Beide PCs sind 64-Bit Windows 7-Rechner. Auf dem Home-PC funktioniert es; auf dem Domänen-PC alledings nicht.

Wie sieht es mit der UAC aus? Werden zum Anlegen einer Datenbank Adminrechte benötigt?

Ich werde noch mal schauen, ob ich noch eine fehlende Komponente finde.