Bearbeiten

Freigeben über


Häufig gestellte Fragen

In den folgenden Abschnitten werden einige allgemeine Probleme behandelt, die bei der Implementierung von LINQ auftreten können.

Weitere Probleme werden in Problembehandlung behandelt.

Es kann keine Verbindung hergestellt werden

Es kann keine Verbindung mit meiner Datenbank hergestellt werden.

Stellen Sie sicher, dass Ihre Verbindungszeichenfolge richtig ist und dass die SQL Server-Instanz ausgeführt wird. Beachten Sie auch, dass für LINQ to SQL das Named Pipes-Protokoll aktiviert sein muss. Weitere Informationen finden Sie unter Lernen durch exemplarische Vorgehensweisen.

Änderungen an der Datenbank sind nicht vorhanden

Änderungen an den Daten in der Datenbank sind nicht mehr vorhanden, nachdem meine Anwendung erneut ausgeführt wurde.

Stellen Sie sicher, dass Sie SubmitChanges aufrufen, um Ergebnisse in der Datenbank zu speichern.

Wie lange kann die Datenbankverbindung geöffnet bleiben?

Wie lange bleibt meine Datenbankverbindung geöffnet?

Eine Verbindung bleibt normalerweise geöffnet, bis Sie die Abfrageergebnisse verwenden. Wenn Sie erwarten, dass die Verarbeitung sämtlicher Ergebnisse länger dauert und nichts dagegen spricht, die Ergebnisse zwischenzuspeichern, wenden Sie ToList auf die Abfrage an. In gängigen Szenarios, in denen jedes Objekt nur einmal verarbeitet wird, ist das Streamingmodell sowohl in DataReader als auch in LINQ to SQL die bevorzugte Lösung.

Die genauen Details der Verbindungsnutzung hängen von folgenden Faktoren ab:

  • Verbindungsstatus, wenn DataContext mit einem Verbindungsobjekt erstellt wird.

  • Verbindungszeichenfolgen-Einstellungen (z. B. Aktivieren von MARS (Multiple Active Result Sets)). Weitere Informationen finden Sie unter Multiple Active Result Sets (MARS).

Ausführen von Updates ohne Abfrage

Können Tabellendaten aktualisiert werden, ohne zuerst eine Datenbankabfrage auszuführen?

Obwohl LINQ to SQL keine mengenbasierten Updatebefehle bereitstellt, können Sie mithilfe einer der folgenden Techniken ohne vorherige Abfrage ein Update ausführen:

  • Verwenden Sie ExecuteCommand, um SQL-Code zu senden.

  • Erstellen Sie eine neue Instanz des Objekts, und initialisieren Sie alle aktuellen Werte (Felder), die sich auf das Update auswirken. Fügen Sie das Objekt anschließend mithilfe von DataContext an Attach an, und ändern Sie das gewünschte Feld.

Unerwartete Abfrageergebnisse

Meine Abfrage gibt unerwartete Ergebnisse zurück. Wie kann der Fehler festgestellt werden?

LINQ to SQL stellt mehrere Tools zum Überprüfen des generierten SQL-Codes bereit. Eines der wichtigsten Tools ist Log. Weitere Informationen finden Sie unter Debugunterstützung.

Gespeicherte Prozedur gibt unerwartete Ergebnisse zurück

Der Rückgabewert einer gespeicherten Prozedur wird durch „MAX()“ berechnet. Wenn die gespeicherte Prozedur auf die O/R-Designer-Oberfläche gezogen wird, ist der Rückgabewert nicht richtig.

LINQ to SQL bietet zwei Möglichkeiten, von der Datenbank generierte Werte mithilfe gespeicherter Prozeduren zurückzugeben:

  • Durch Benennen des Ausgabeergebnisses.

  • Durch explizites Festlegen eines Ausgabeparameters.

Im Folgenden ein Beispiel für eine fehlerhafte Ausgabe. Da die Ergebnisse von LINQ to SQL nicht zugeordnet werden können, wird immer 0 (null) zurückgegeben:

create procedure proc2

as

begin

select max(i) from t where name like 'hello'

end

Im Folgenden ein Beispiel für eine richtige Ausgabe, bei der ein Ausgabeparameter verwendet wird:

create procedure proc2

@result int OUTPUT

as

select @result = MAX(i) from t where name like 'hello'

go

Im Folgenden ein Beispiel für eine richtige Ausgabe, bei der das Ausgabeergebnis benannt wird:

create procedure proc2

as

begin

select nax(i) AS MaxResult from t where name like 'hello'

end

Weitere Informationen finden Sie unter Anpassen von Vorgängen durch Verwendung von gespeicherten Prozeduren.

Serialisierungsfehler

Beim Versuch, eine Serialisierung auszuführen, wird folgender Fehler ausgegeben: "Typ 'System.Data.Linq.ChangeTracker+StandardChangeTracker' ... ist nicht als serialisierbar gekennzeichnet."

Die Codegenerierung in LINQ to SQL unterstützt die DataContractSerializer-Serialisierung. XmlSerializer oder BinaryFormatter wird nicht unterstützt. Weitere Informationen finden Sie unter Serialization (Serialisierung).

Mehrere DBML-Dateien

Bei Verwendung mehrerer DBML-Dateien, die einige Tabellen gemeinsam nutzen, wird ein Compilerfehler ausgegeben.

Legen Sie die Context Namespace-Eigenschaft und die Entity Namespace-Eigenschaft von Objektrelationaler Designer für jede DBML-Datei auf einen unterschiedlichen Wert fest. Durch diese Lösung werden Konflikte zwischen Namen und Namespace vermieden.

Vermeiden, dass von der Datenbank generierte Werte bei Einfüge- oder Updatevorgängen explizit festgelegt werden

Bei einer Datenbanktabelle mit einer DateCreated-Spalte wird die Spalte standardmäßig auf SQL „Getdate()“ festgelegt. Beim Versuch, mit LINQ to SQL einen neuen Datensatz einzufügen, wird der Wert auf NULL festgelegt. Erwartungsgemäß sollte der Wert auf den Datenbankstandard festgelegt werden.

LINQ to SQL behandelt diese Situation bei ID- (automatisch inkrementierten), ROWGUID- (von der Datenbank generierte GUID) und Timestamp-Spalten automatisch. In anderen Fällen sollten Sie die Eigenschaften IsDbGenerated=true und AutoSync=Always/OnInsert/OnUpdate manuell festlegen.

Mehrere DataLoadOptions

Können zusätzliche Ladeoptionen angegeben werden, ohne die erste zu überschreiben?

Ja. Die erste Option wird nicht überschrieben, wie im folgenden Beispiel veranschaulicht:

Dim dlo As New DataLoadOptions()
dlo.LoadWith(Of Order)(Function(o As Order) o.Customer)
dlo.LoadWith(Of Order)(Function(o As Order) o.OrderDetails)
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Order>(o => o.Customer);
dlo.LoadWith<Order>(o => o.OrderDetails);

Fehler bei der Verwendung von SQL Compact 3.5

Beim Ziehen von Tabellen aus einer SQL Server Compact 3.5-Datenbank wird ein Fehler ausgegeben.

Objektrelationaler Designer unterstützt SQL Server Compact 3.5 nicht, obwohl dies bei der LINQ to SQL-Runtime der Fall ist. In dieser Situation müssen Sie eigene Entitätsklassen erstellen und die entsprechenden Attribute hinzufügen.

Fehler in Vererbungsbeziehungen

Wenn die Vererbungsform aus der Toolbox in Objektrelationaler Designer zum Verbinden von zwei Entitäten verwendet wird, treten Fehler auf.

Es reicht nicht aus, die Beziehung zu erstellen. Sie müssen Informationen wie Unterscheidungsspalte, Basisklassen-Diskriminatorwert und Diskriminatorwert der abgeleiteten Klasse angeben.

Anbietermodell

Ist ein öffentliches Anbietermodell verfügbar?

Es ist kein öffentliches Anbietermodell verfügbar. Derzeit unterstützt LINQ to SQL nur SQL Server und SQL Server Compact 3.5.

SQL-Injection-Angriffe

Wie wird LINQ to SQL vor SQL-Injection-Angriffen geschützt?

In herkömmlichen SQL-Abfragen, die durch die Verkettung der Benutzereingabe erzeugt wurden, stellte die SQL-Injection ein bedeutendes Risiko dar. In LINQ to SQL werden solche Einfügungen durch die Verwendung von SqlParameter in Abfragen vermieden. Die Benutzereingabe wird in Parameterwerte umgewandelt. Auf diese Weise wird verhindert, dass böswillige Befehle aus Kundeneingaben verwendet werden.

Ändern des Schreibschutzflags in DBML-Dateien

Wie können Setter aus einigen Eigenschaften entfernt werden, wenn ein Objektmodell aus einer DBML-Datei erstellt wird?

Führen Sie für dieses erweiterte Szenario die folgenden Schritte aus:

  1. Ändern Sie in der DBML-Datei die Eigenschaft, indem Sie das IsReadOnly-Flag in True ändern.

  2. Fügen Sie eine partielle Klasse hinzu. Erstellen Sie einen Konstruktor mit Parametern für die schreibgeschützten Member.

  3. Überprüfen Sie den UpdateCheck-Standardwert (Never), um zu bestimmen, ob dieses der richtige Wert für die Anwendung ist.

    Achtung

    Wenn Sie Objektrelationaler Designer in Visual Studio verwenden, können Ihre Änderungen überschrieben werden.

APTCA

Ist System.Data.Linq für die Verwendung durch teilweise vertrauenswürdigen Code markiert?

Ja, die „System.Data.Linq.dll“-Assembly gehört zu den .NET Framework-Assemblys, die mit dem AllowPartiallyTrustedCallersAttribute-Attribut markiert sind. Assemblys in .NET Framework, die diese Markierung nicht aufweisen, sind nur für die Verwendung durch voll vertrauenswürdigen Code vorgesehen.

Das Hauptszenario zum Zulassen teilweise vertrauenswürdiger Aufrufe in LINQ to SQL sieht wie folgt aus: Webanwendungen, deren Vertrauenswürdigkeit mit einem mittleren Wert konfiguriert ist, muss der Zugriff auf die SQL-Assembly gewährt werden.

Zuordnen von Daten aus mehreren Tabellen

Die Daten in meiner Entität stammen aus mehreren Tabellen. Wie werden sie zugeordnet?

Sie können eine Ansicht in einer Datenbank erstellen und die Entität der Ansicht zuordnen. LINQ to SQL generiert für Ansichten dieselbe SQL wie für Tabellen.

Hinweis

Die Verwendung von Ansichten in diesem Szenario unterliegt Einschränkungen. Dieser Ansatz funktioniert am sichersten, wenn die für Table<TEntity> ausgeführten Vorgänge von der zugrunde liegenden Ansicht unterstützt werden. Nur Sie wissen, welche Vorgänge beabsichtigt sind. Beispiel: Die meisten Anwendungen sind schreibgeschützt, und eine weitere große Anzahl von Anwendungen führt Create/Update/Delete-Vorgänge für Ansichten ausschließlich unter Verwendung gespeicherter Prozeduren aus.

Verbindungspooling

Gibt es ein Konstrukt, das beim DataContext-Pooling hilfreich sein kann?

Sie sollten nicht versuchen, Instanzen von DataContext wiederzuverwenden. Jeder DataContext behält den Zustand (einschließlich eines Identitätscaches) für eine bestimmte Bearbeitungs-/Abfragesitzung bei. Um neue Instanzen auf Grundlage des aktuellen Zustands der Datenbank zu erhalten, verwenden Sie einen neuen DataContext.

Sie können weiterhin das zugrunde liegende Verbindungspooling von ADO.NET verwenden. Weitere Informationen finden Sie unter SQL Server-Verbindungspooling (ADO.NET).

Zweiter DataContext wird nicht aktualisiert

Zum Speichern von Werten in der Datenbank wurde eine Instanz von DataContext verwendet. Die aktualisierten Werte werden aber von einem zweiten DataContext in derselben Datenbank nicht angezeigt. Die zweite DataContext-Instanz scheint zwischengespeicherte Werte zurückzugeben.

Dieses Verhalten ist beabsichtigt. LINQ to SQL gibt weiterhin dieselben Instanzen/Werte zurück, die in der ersten Instanz angezeigt wurden. Wenn Sie Updates vornehmen, verwenden Sie vollständige Parallelität. Die ursprünglichen Daten werden verwendet, um den aktuellen Datenbankzustand zu überprüfen und zu bestätigen, dass der Zustand weiterhin unverändert ist. Wenn er sich geändert hat, tritt ein Konflikt auf, der von der Anwendung gelöst werden muss. Eine Möglichkeit für die Anwendung besteht darin, den ursprünglichen Zustand auf den aktuellen Datenbankzustand zurückzusetzen und den Updateversuch zu wiederholen. Weitere Informationen finden Sie unter Verwalten von Änderungskonflikten.

Sie können auch ObjectTrackingEnabled auf false festlegen, wodurch das Zwischenspeichern und Nachverfolgen von Änderungen deaktiviert wird. Anschließend können Sie bei jeder Abfrage die neuesten Werte abrufen.

SubmitChanges kann nicht im schreibgeschützten Modus aufgerufen werden

Beim Versuch, SubmitChanges im schreibgeschützten Modus aufzurufen, tritt ein Fehler auf.

Im schreibgeschützten Modus ist der Kontext nicht mehr in der Lage, Änderungen nachzuverfolgen.