FAQ (Häufig gestellte Fragen) zu LINQ to SQL
Aktualisiert: November 2007
In den folgenden Abschnitten werden einige allgemeine Probleme behandelt, die bei der Implementierung von LINQ auftreten können.
Weitere Probleme werden in Problembehandlung (LINQ to SQL) behandelt.
Es kann keine Verbindung hergestellt werden
F. Es kann keine Verbindung mit der Datenbank hergestellt werden.
A. 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 mit exemplarischen Vorgehensweisen (LINQ to SQL).
Änderungen an der Datenbank sind nicht vorhanden
F. Änderungen an den Daten in der Datenbank sind nicht mehr vorhanden, nachdem die Anwendung erneut ausgeführt wurde.
A. Stellen Sie sicher, dass Sie SubmitChanges aufrufen, um Ergebnisse in der Datenbank zu speichern.
Wie lange kann die Datenbankverbindung geöffnet bleiben?
F. Wie lange bleibt die Datenbankverbindung geöffnet?
A. 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<TSource> auf die Abfrage an. In gängigen Szenarien, 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 MARS (Multiple Active Result Sets).
Ausführen von Aktualisierungen ohne Abfrage
F. Können Tabellendaten aktualisiert werden, ohne zuerst eine Datenbankabfrage auszuführen?
A. Obwohl LINQ to SQL keine mengenbasierten Aktualisierungsbefehle bereitstellt, können Sie mithilfe einer der folgenden Techniken ohne vorherige Abfrage eine Aktualisierung 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 die Aktualisierung auswirken. Fügen Sie das Objekt anschließend mithilfe von Attach an DataContext an, und ändern Sie das gewünschte Feld.
Unerwartete Abfrageergebnisse
F. Eine Abfrage gibt unerwartete Ergebnisse zurück. Wie kann der Fehler festgestellt werden?
A. 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 Debuggingunterstützung (LINQ to SQL).
Gespeicherte Prozedur gibt unerwartete Ergebnisse zurück
F. 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.
A. 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 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 Operationen durch Verwenden gespeicherter Prozeduren (LINQ to SQL).
Serialisierungsfehler
F. Beim Versuch, eine Serialisierung auszuführen, wird folgender Fehler ausgegeben: "Typ 'System.Data.Linq.ChangeTracker+StandardChangeTracker' ... ist nicht als serialisierbar gekennzeichnet."
A. Die Codegenerierung in LINQ to SQL bietet Unterstützung für die DataContractSerializer-Serialisierung. XmlObjectSerializer oder BinaryFormatter wird nicht unterstützt. Weitere Informationen finden Sie unter Serialisierung (LINQ to SQL).
Mehrere DBML-Dateien
F. Bei Verwendung mehrerer DBML-Dateien, die einige Tabellen gemeinsam nutzen, wird ein Compilerfehler ausgegeben.
A. Legen Sie die Context Namespace-Eigenschaft und die Entity Namespace-Eigenschaft von O/R-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 Aktualisierungsvorgängen explizit festgelegt werden
F. 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.
A. LINQ to SQL behandelt diese Situation bei ID- (automatisch inkrementierten), ROWGUID- (von der Datenbank generierte GUID) und Zeitstempelspalten automatisch. In anderen Fällen sollten Sie die Eigenschaften IsDbGenerated=true und AutoSync=Always/OnInsert/OnUpdate manuell festlegen.
Mehrere DataLoadOptions
F. Können zusätzliche Ladeoptionen angegeben werden, ohne die erste zu überschreiben?
A. 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
F. Beim Ziehen von Tabellen aus einer SQL Server Compact 3.5-Datenbank wird ein Fehler ausgegeben.
A. Obwohl SQL Server Compact 3.5 von der LINQ to SQL-Laufzeit unterstützt wird, bietet O/R-Designer keine entsprechende Unterstützung. In dieser Situation müssen Sie eigene Entitätsklassen erstellen und die entsprechenden Attribute hinzufügen.
Fehler in Vererbungsbeziehungen
F. Wenn die Vererbungsform aus der Toolbox in O/R-Designer zum Verbinden von zwei Entitäten verwendet wird, treten Fehler auf.
A. Es reicht nicht aus, die Beziehung zu erstellen. Sie müssen Informationen wie Unterscheidungsspalte, Basisklassen-Diskriminatorwert und Diskriminatorwert der abgeleiteten Klasse angeben.
Anbietermodell
F. Ist ein öffentliches Anbietermodell verfügbar?
A. 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
F. Wie wird LINQ to SQL vor SQL-Injection-Angriffen geschützt?
A. 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
F. Wie können Setter aus einigen Eigenschaften entfernt werden, wenn ein Objektmodell aus einer DBML-Datei erstellt wird?
A. Führen Sie für dieses erweiterte Szenario die folgenden Schritte aus:
Ändern Sie in der DBML-Datei die Eigenschaft, indem Sie das IsReadOnly-Flag in True ändern.
Fügen Sie eine partielle Klasse hinzu. Erstellen Sie einen Konstruktor mit Parametern für die schreibgeschützten Member.
Überprüfen Sie den UpdateCheck-Standardwert (Never), um zu bestimmen, ob dieses der richtige Wert für die Anwendung ist.
.gif "Warnhinweis")
Vorsicht:Wenn Sie O/R-Designer in Visual Studio verwenden, können Ihre Änderungen überschrieben werden.
APTCA
F. Ist System.Data.Linq für die Verwendung durch teilweise vertrauenswürdigen Code markiert?
A. 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 LINQ to SQL-Assembly gewährt werden.
Zuordnen von Daten aus mehreren Tabellen
F. Die Daten in einer Entität stammen aus mehreren Tabellen. Wie werden sie zugeordnet?
A. 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.
.gif "Hinweis") 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
F. Gibt es ein Konstrukt, das das DataContext-Pooling unterstützt?
A. 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
F. 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.
A. Dieses Verhalten ist vorgesehen. LINQ to SQL gibt weiterhin dieselben Instanzen/Werte zurück, die in der ersten Instanz angezeigt wurden. Wenn Sie Aktualisierungen 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 Aktualisierungsversuch zu wiederholen. Weitere Informationen finden Sie unter Gewusst wie: Verwalten von Änderungskonflikten (LINQ to SQL).
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
F. Beim Versuch, SubmitChanges im schreibgeschützten Modus aufzurufen, tritt ein Fehler auf.
A. Im schreibgeschützten Modus ist der Kontext nicht mehr in der Lage, Änderungen nachzuverfolgen.
Siehe auch
Aufgaben
Problembehandlung (LINQ to SQL)