Vanliga frågor och svar

Kontrollera att din anslutningssträng är korrekt och att SQL Server-instansen körs. Observera också att LINQ till SQL kräver att protokollet Namngivna pipes är aktiverat. Mer information finns i Learning by Walkthroughs (Utbildning efter genomgång).

Kontrollera att du anropar SubmitChanges för att spara resultat i databasen.

En anslutning förblir vanligtvis öppen tills du använder frågeresultatet. Om du förväntar dig att det tar tid att bearbeta alla resultat och inte motsätter dig cachelagring av resultaten, gäller ToList du för frågan. I vanliga scenarier där varje objekt endast bearbetas en gång är strömningsmodellen överlägsen både och DataReader LINQ till SQL.

Den exakta informationen om anslutningsanvändningen beror på följande:

• Anslut ionsstatus om DataContext är konstruerad med ett anslutningsobjekt.

• Anslut ionssträngsinställningar (till exempel aktivering av flera aktiva resultatuppsättningar (MARS). Mer information finns i Flera aktiva resultatuppsättningar (MARS).

Även om LINQ till SQL inte har uppsättningsbaserade uppdateringskommandon kan du använda någon av följande tekniker för att uppdatera utan att först fråga:

• Använd ExecuteCommand för att skicka SQL-kod.

• Skapa en ny instans av objektet och initiera alla aktuella värden (fält) som påverkar uppdateringen. Koppla sedan objektet till DataContext med hjälp Attach av och ändra det fält som du vill ändra.

LINQ till SQL innehåller flera verktyg för att inspektera DEN SQL-kod som genereras. En av de viktigaste är Log. Mer information finns i Felsökningssupport.

LINQ till SQL ger två sätt att returnera databasgenererade värden genom lagrade procedurer:

• Genom att namnge utdataresultatet.

• Genom att uttryckligen ange en utdataparameter.

Följande är ett exempel på felaktiga utdata. Eftersom LINQ till SQL inte kan mappa resultaten returneras alltid 0:

create procedure proc2

as

begin

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

end

Följande är ett exempel på korrekta utdata med hjälp av en utdataparameter:

create procedure proc2

@result int OUTPUT

as

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

go

Följande är ett exempel på korrekta utdata genom att namnge utdataresultatet:

create procedure proc2

as

begin

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

end

Mer information finns i Anpassa åtgärder med hjälp av lagrade procedurer.

Kodgenerering i LINQ till SQL stöder DataContractSerializer serialisering. Det stöder XmlSerializer inte eller BinaryFormatter. Mer information finns i Serialisering.

Ange egenskaperna Kontextnamnområde och Entitetsnamnområde från Objektrelationsdesignern till ett distinkt värde för varje DBML-fil. Den här metoden eliminerar kollisionen mellan namn och namnområde.

LINQ till SQL hanterar den här situationen automatiskt för identitetskolumner (automatisk inkrement) och rowguidcol (databasgenererat GUID) och tidsstämpelkolumner. I andra fall bör du ange IsDbGeneratedtrue=ochAlways=OnUpdateAutoSync/OnInsert/egenskaper manuellt.

Ja. Den första skrivs inte över, som i följande exempel:

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

Object Relational Designer stöder inte SQL Server Compact 3.5, även om LINQ till SQL-körningen gör det. I den här situationen måste du skapa egna entitetsklasser och lägga till lämpliga attribut.

Det räcker inte att skapa relationen. Du måste ange information som den diskriminerande kolumnen, basklassdiskriminatorvärdet och det härledda klassdiskrimineringsvärdet.

Ingen offentlig providermodell är tillgänglig. För närvarande har LINQ till SQL endast stöd för SQL Server och SQL Server Compact 3.5.

SQL-inmatning har varit en betydande risk för traditionella SQL-frågor som bildas genom att sammanfoga användarindata. LINQ till SQL undviker sådan inmatning med hjälp SqlParameter av i frågor. Användarindata omvandlas till parametervärden. Den här metoden förhindrar att skadliga kommandon används från kundindata.

Utför följande steg för det här avancerade scenariot:

1. Ändra egenskapen i .dbml-filen genom att ändra IsReadOnly flaggan till True.

2. Lägg till en partiell klass. Skapa en konstruktor med parametrar för de skrivskyddade medlemmarna.

3. Granska standardvärdet UpdateCheck (Never) för att avgöra om det är rätt värde för ditt program.

   Varning

   Om du använder Objektrelationsdesignern i Visual Studio kan dina ändringar skrivas över.

Ja, System.Data.Linq.dll sammansättning finns bland de .NET Framework-sammansättningar som har markerats med AllowPartiallyTrustedCallersAttribute attributet . Utan den här märkningen är sammansättningar i .NET Framework endast avsedda för användning med fullständigt betrodd kod.

Huvudscenariot i LINQ till SQL för att tillåta delvis betrodda anropare är att göra det möjligt att komma åt LINQ till SQL-sammansättningen från webbprogram, där förtroendekonfigurationen är Medel.

Du kan skapa en vy i en databas och mappa entiteten till vyn. LINQ till SQL genererar samma SQL för vyer som för tabeller.

Försök inte återanvända instanser av DataContext. Var DataContext och en upprätthåller tillstånd (inklusive en identitetscache) för en viss redigerings-/frågesession. Om du vill hämta nya instanser baserat på databasens aktuella tillstånd använder du en ny DataContext.

Du kan fortfarande använda underliggande ADO.NET anslutningspooler. Mer information finns i SQL Server Anslut ion Pooling (ADO.NET).

Detta beteende är av design. LINQ till SQL fortsätter att returnera samma instanser/värden som du såg i den första instansen. När du gör uppdateringar använder du optimistisk samtidighet. De ursprungliga data används för att kontrollera det aktuella databastillståndet för att bekräfta att de i själva verket fortfarande är oförändrade. Om den har ändrats uppstår en konflikt och ditt program måste lösa det. Ett alternativ för ditt program är att återställa det ursprungliga tillståndet till det aktuella databastillståndet och försöka uppdatera igen. Mer information finns i Så här hanterar du ändringskonflikter.

Du kan också ställa in ObjectTrackingEnabled på false, vilket inaktiverar cachelagring och ändringsspårning. Du kan sedan hämta de senaste värdena varje gång du frågar.

Skrivskyddat läge inaktiverar möjligheten för kontexten att spåra ändringar.

Se även

• Referens
• Felsökning
• Säkerhet i LINQ till SQL