Häufig gestellte Fragen

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.

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

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).

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.

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.

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.

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).

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.

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.

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);

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.

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

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

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.

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.

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.

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.

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).

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.

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

Siehe auch

• Referenz
• Problembehandlung
• Sicherheit in LINQ to SQL