Har en function som returnerar en datareader, problemet är att det verkar som koden efter "return" exekveras inte. Detta betyder att anslutningen inte stängs. Stänger jag anslutningen före "return" så stängsanslutningen men datareadern är tom. Jag tycker detta är väldigt ologiskt, kan nån förklara vad jag gör för fel. Tack på förhand.....

Public Shared Function getDataReader(ByVal strSQL As String) As System.Data.Odbc.OdbcDataReader
Dim dr As Odbc.OdbcDataReader
Dim MinConn As New OdbcConnection(ConfigurationSettings.AppSettings("DbString"))

MinConn.Open()

Dim cmd = New System.Data.Odbc.OdbcCommand(safeSQL(strSQL), MinConn)
dr = cmd.executereader()
dr.Read()

'----- Returnera datareader
Return dr

'----- Stäng förbindelsen till databasen
MinConn.Close()
dr.Close()
End Function

Return innebär "avsluta funktionen och returnera variabeln", alltså ingen kod efter return exekveras någonsin. Sen gäller det för Datareader att du kan inte stänga dess db-koppling innan den används, då fungerar den inte. Datareader går ut på att du har en öppen koppling mot DB när du läser datat, och när du är klar med att hämta ut datat, då stänger du Datareadern och kopplingen. Du ska alltså inte göra Close() i din getDataReader() funktion.

ok, det låter ju logiskt =) Ska jag göra en closeDataReader function eller kanske returnera än sträng istället för en datareader? Har du nån smart idé?

tack för svaret

Du kan ju lägga det i en sträng som du säger eller i ett dataset beroende på vad du hämtar ut från DB.

Hur brukar man skriva klasser för kontakt mot databasen, kan det inte vara smidigt att ha en klass som returnerar ett dataset och en som returnerar en datareader?

Denna klass returnerar ett dataset
<code>
public DataSet getRss()
{
DataSet dsRss = new DataSet();

SqlConnection conn = new SqlConnection(connectionString);
SqlCommand cmd = new SqlCommand("NAMNPÅPROCEDUREN", conn);
cmd.CommandType = CommandType.StoredProcedure;

SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
try
{
sqlDataAdapter.Fill(dsRss);
}
catch { }

finally
{
conn.Close();
}

return dsRss;

}
</code>
Det borde ju vara liknande att returnera en reader.

Jo men ett dataset kräver inte att connectionen är öppen, eller? Det knepiga blir väl att returnera en datareader som man inte kan stänga för att den skall kunna användas.

Jo, det är sant. Men varför returnera readern? Funkar inte nåt sånt här?
<code>
public string getNewsDetails(int _newsID)
{
newsID = _newsID;

SqlConnection conn = new SqlConnection(connectionString);
SqlCommand cmd = new SqlCommand("NAMNPÅPROCEDUREN", conn);
cmd.CommandType = CommandType.StoredProcedure;

cmd.Parameters.Add(new SqlParameter("@newsID", SqlDbType.Int, 4));
cmd.Parameters["@newsID"].Value = newsID;

try
{
conn.Open();
SqlDataReader reader = cmd.ExecuteReader();


if (reader.Read())
{
myNews = reader["news"].ToString();
return myNews;
}

reader.Close();
return "";
}

finally
{
conn.Close();
}
}
</code>

Eller varför inte returnera Dataset eller DataTabel eller DataRow beronde på hur mycket data vi pratar om?

Datareadern är det mest minnessnåla och därmed optimala sättet att läsa från en databas.
Om man har en Datalagerklass av något slag gör man ofta funktioner som returnerar Datareadern. Då är det upp till klienten/konsumenten av klassen att ombesörja att den stängs efter användning. Detta är bra, och rekommenderas av Microsofts Patterns & Practices.
(Detta gäller om man är InProc vilket man är i en IIS-applikation - annars om man har t.ex com+ komponenter då är dataset/egna dataklasser bättre)

Aha? så du menar alltså att man ska förutspråka datareaders framför dataset, datatable och datarow med IIS?

Jag har fått för mig att datareader kräver lite mer kod för att hantera den och det känns därmed mer riskabelt att hantera denne? Jag brukar lägga datan i dataset, datatabels och datarows istället, det känns lite som om man wrapar datareadern en nivå. Jag ser dessutom det som en fördel att man inte behöver oroa sig för att datareaders inte blir stängda då man oftast har en finnaly i alla databas anrops funktioner som gör just detta. Slutligen så är det väll en fördel då man kan ha strong types i samband med just dataset,datatabel och datarows?

<b>Aha? så du menar alltså att man ska förutspråka datareaders framför dataset, datatable och datarow med IIS?</b>

Det beror på. Jag gillar inte att förespråka ett sätt att lösa allt på, utan man får se det från fall till fall.
Men generellt när det gäller listor är datareaders att föredra pga prestanda.

<b>Jag har fått för mig att datareader kräver lite mer kod för att hantera den och det känns därmed mer riskabelt att hantera denne? </b>

Nja, en vanlig enkel hämtning och databinding till en webform innebär mindre kod.

<b>Jag brukar lägga datan i dataset, datatabels och datarows istället, det känns lite som om man wrapar datareadern en nivå. Jag ser dessutom det som en fördel att man inte behöver oroa sig för att datareaders inte blir stängda då man oftast har en finnaly i alla databas anrops funktioner som gör just detta. </b>

Jag brukar utgå från följande. När man hämtar EN post, alltså ganska lite data, använder man kanske Dataset, eller egen typad klass som håller datat. Men för att rendera en lista använder man readers. Om du ska visa en lista på 100 poster innebär detta att du i minnet smäller upp 100 rader i ett dataset som ögonblickligen kastas bort. Tänk på hur mycket mer GarbageCollector måste arbeta om du har hundratals användare online. Med en datareader undviker du detta. Datareadern streamar ju datat direkt från databasen ut till webbsidan. (du lär inte märka nån skillnad när du utvecklar lokalt men online med många användare kan det göra mycket).

<b>Slutligen så är det väll en fördel då man kan ha strong types i samband med just dataset,datatabel och datarows?</b>

Det är alltid bra. Men man kan t.ex. skapa en klass som ärver från Datareader och introducerar typade properties för åtkomst till Items, eller en wrapper. Mer kod - men mer effektivt.

Okay, men frågan man ställer sig då är om det är någon större minnes skildnad igentligen?

Jag förstår faktiskt inte alls detta. Varför ska man returnera en referens på en datareader när det är så pass viktigt att den stängs korrekt? Det känns ju mycket mer logiskt att låta DAL tahandom allt som har med databasen att göra och endast returnera datan(ingen referens direkt till databasen). Risken finns att man någonstans glömmer att stänga readern och då får man leta på alla möjliga ställen där denna datareader rör sig.

Ja Microsoft förutspråkar det, men varför? det måste finnas en anledning att krångla till det på detta vis? är minnes besparingen så pass stor kanske?

Sen slutligen, gäller detta verkligen även för 2.0 där man har en större fördel genom att typa dataset,datatabel eller datarows?

Jag läste nöjligen en artikel om hur man i 2.0 kunde skapa DAL(med hjälp av wizard) utan att skriva någon kod alls, där fanns mycket riktigt med retunering av typade datatabels men returnering av datareader existerade inte? då kan man undra varför om nu microsoft förutspråkar detta?

Sen en annan fördel med dataset/datatabel/datarow är att man kan efter man har hämntat ut data göra en ändring i denna struktur och sen updatera databasen enligt detta på ett väldigt smidigt vis i 2.0.

Det kan vara stor skillnad, beror på som sagt..

Microsoft rekomenderar i många fall Datareader.
Läs detta:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt12.asp
DataSet vs. DataReader

Så svårt är det väl inte att komm ihåg Close()? Har aldrigt haft problemet i.a.f...

Samma gäller för 2.0 jo.
Dataset fanns i 1.0 med så det är väl inget nytt.
Visst den nyare dataadapter wizarden är ju en klar förbättring men det innebär inte att Dataset har blivit optimalt att använda till allt.

Angående kodgenerering finns det bättre alternativ, CodeSmith eller MyGeneration.