mboost-dp1
Asp.net billede fra mssql tabel
Har siddet og lavet lidt kode til at gemme et billede og en thumbnail af billedet i en mssql tabel. udfra dette tutorial. Det er da også lykkedes mig at få billedet hentet ud af tabellen og vist det på en side hvor content type er sat til Image/JPEG. Dog kun i .NET 3.5. Da det webhotel jeg anvender kun understøtter .NET 2.0 lavede jeg det om til 2.0 og her er det så tingene begynder at gå galt. Jeg har søgt lidt på nettet og de løsninger jeg kan finde ser ikke ud til at fungere! her er min kode:
fejlen jeg får er "Det angivne argument lå uden for det gyldige værdiområde. Parameternavn: offset", og kommer ved linien Response.BinaryWrite(dr.item(2)) dr.item(2) i mssql tabellen er et felt som hedder billede og typen er image.. har svært ved at se hvad jeg gør galt, så håber på lidt hjælp på forhånd tak!
Private Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load
Response.ContentType = "Image/JPEG"
Dim Conn As SqlConnection = New SqlConnection(Resource.ConnectionString)
Dim Cmd As SqlCommand = Conn.CreateCommand
Try
Conn.Open()
Cmd.CommandText = "SELECT * FROM Images WHERE ID=@ID"
Cmd.Parameters.AddWithValue("@ID", "69a79896-6a20-4aa1-9827-0460f69bf094")
Dim dr As SqlDataReader = Cmd.ExecuteReader
While dr.Read
Response.BinaryWrite(dr.Item(2))
End While
Catch ex As Exception
Response.Write(ex.Message)
Finally
If Conn.State = Data.ConnectionState.Open Then Conn.Close()
End Try
End Sub
fejlen jeg får er "Det angivne argument lå uden for det gyldige værdiområde. Parameternavn: offset", og kommer ved linien Response.BinaryWrite(dr.item(2)) dr.item(2) i mssql tabellen er et felt som hedder billede og typen er image.. har svært ved at se hvad jeg gør galt, så håber på lidt hjælp på forhånd tak!
prøver jeg lige, hvordan kan jeg bruge ExecuteScalar, i den sammenhæng, er aldrig lykkedes mig at få det til at funke hehe?
Jeg har lige et par kommentarer, der dog ikke knytter sig direkte til dit problem.
Har du en god grund til at ville gemme billeder i din database? Filsystemet er langt bedre til at håndtere den slags, ligesom det gør fx backup særdeles lettere.
Du kan sagtens afvikle .NET 3.5 på dit webhotel. Det er nemlig kun udvidelser til .NET 2.0, så det kræver blot, at du uploader de relevante filer (System.Core.dll, System.Data.Linq.dll og hvad du ellers bruger; den bør selv brokke sig).
Filerne finder du i C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 og skal blot placeres i din /bin-mappe.
1 skrev:Har siddet og lavet lidt kode til at gemme et billede og en thumbnail af billedet i en mssql tabel.
Har du en god grund til at ville gemme billeder i din database? Filsystemet er langt bedre til at håndtere den slags, ligesom det gør fx backup særdeles lettere.
1 skrev:Dog kun i .NET 3.5. Da det webhotel jeg anvender kun understøtter .NET 2.0 lavede jeg det om til 2.0
Du kan sagtens afvikle .NET 3.5 på dit webhotel. Det er nemlig kun udvidelser til .NET 2.0, så det kræver blot, at du uploader de relevante filer (System.Core.dll, System.Data.Linq.dll og hvad du ellers bruger; den bør selv brokke sig).
Filerne finder du i C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 og skal blot placeres i din /bin-mappe.
Har du en god grund til at ville gemme billeder i din database? Filsystemet er langt bedre til at håndtere den slags, ligesom det gør fx backup særdeles lettere.
nej ikke andet end jeg umiddelbart ville mene at det var en nemmere måde at gøre det på hvis det virkede. Altså i stedet for at have en sql tabel der holder styr på data fra nogle mapper, så ligger det bare direkte i sql tabellen sammen info om billederne.
så lykkedes det sku, viste sig at fejlen lå i koden til at gemme billederne i databasen!! tak for hjælpen alle sammen :)
7 skrev:Har du en god grund til at ville gemme billeder i din database? Filsystemet er langt bedre til at håndtere den slags, ligesom det gør fx backup særdeles lettere.
Den med at fil systemet er bedre til at gemmer filer er efter min bedste overbevisning en myte som baserer sig på fakta tilbage fra Access 2.0 & 95 tiden.
Det børe være åbenlyst at det er langt nemmere at lave en samlet backup fremfor at lave to forskellige backups.
7 skrev:Du kan sagtens afvikle .NET 3.5 på dit webhotel. Det er nemlig kun udvidelser til .NET 2.0, så det kræver blot, at du uploader de relevante filer (System.Core.dll, System.Data.Linq.dll og hvad du ellers bruger; den bør selv brokke sig).
Filerne finder du i C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 og skal blot placeres i din /bin-mappe.
Compileren vil stadig være den der kom med 2.0, så al kode skal
compiles ikke noget App_Code og src ref.
Og så er der SP1 roderiet.
Måske ikke umuligt, men man skal nok have lidt styr på tingene inden man kaster sig ud i det hack.
12 skrev:Den med at fil systemet er bedre til at gemmer filer er efter min bedste overbevisning en myte som baserer sig på fakta tilbage fra Access 2.0 & 95 tiden.
Der er mange argumenter for ikke at bruge databasen til filer. Primært at den ikke er beregnet til det, og du ikke har nogle åbenlyse fordele af at gemme filer i forbindelse med din metadata, hvis du bare kan designe en god arkitektur.
Andre argumenter er dog pladsforbruget, der alt andet lige og typisk bliver større, når du pakker et lag udover. Det vigtigste argument er dog nok ydelse, idet du får et væsentligt spild, hvis du ikke kan lade din server håndtere filer direkte, men skal initialisere en databaseforbindelse, vælge objektet og returnere det. Selvfølgelig kan det optimeres, men jeg er ret sikker på, at fx Flickr gemmer filer fysisk. Det er simpelthen tåbeligt andet. Filsystemet er optimeret til den proces.
12 skrev:Det børe være åbenlyst at det er langt nemmere at lave en samlet backup fremfor at lave to forskellige backups.
Hvis du kun måler backup i, hvor let det er at konfigurere, har du ret. Det er bare sjældent tilfældet. En backup skal jo også gerne være funktionel, hvis uheldet er ude, og det kan det være af flere årsager. Hvis du bare skal gendanne alt fra kopien, er din løsning også lettest, men hvis du skal ind og gendanne en specifik fil uden at berøre andre data, er det med værktøjer som fx Tivoli noget lettere, når filen er fysisk.
13 skrev:Compileren vil stadig være den der kom med 2.0, så al kode skal
compiles ikke noget App_Code og src ref.
Og så er der SP1 roderiet.
Måske ikke umuligt, men man skal nok have lidt styr på tingene inden man kaster sig ud i det hack.
Jeg er også stor fortaler for, at man ikke anvendes Web Site, når man kan anvende Web Application Project. Det er selvfølgelig en smagssag, hvordan man vægter fordele og ulemper, men det muliggør mit forslag. Det er i hvert fald ikke første gang, jeg anbefaler den løsning.
måske lidt off topic, men nogen der har en god idé til hvordan jeg får hentet noget data ud i en tabel så det kommer til at se sådan her ud:
<table>
<tr>
<td>data1</td>
<td>data2</td>
<td>data3</td>
<td>data4</td>
</tr>
<tr>
<td>data5</td>
<td>data6</td>
<td>tom</td>
<td>tom</td>
</tr>
</table>
har ingen idé om hvad jeg skal søge efter på google
<table>
<tr>
<td>data1</td>
<td>data2</td>
<td>data3</td>
<td>data4</td>
</tr>
<tr>
<td>data5</td>
<td>data6</td>
<td>tom</td>
<td>tom</td>
</tr>
</table>
har ingen idé om hvad jeg skal søge efter på google
#16
Ja har jeg styr på :)
mente bare der var en web control i visual studio der kunne udføre det samme noget nemmere
Ja har jeg styr på :)
mente bare der var en web control i visual studio der kunne udføre det samme noget nemmere
14 skrev:
Der er mange argumenter for ikke at bruge databasen til filer. Primært at den ikke er beregnet til det,
Databaser er beregnet til at hive data ud af. De fleste databaser understøtter LOB data typer op til ca. 2 GB.
Jeg gætter på at funktionaliteten er der med beregnethed på at blive brugt.
Har du overvejet hvorfor et firma som Oracle tilbyder et fil system implementeret ovenpå en database (Oracle CM SDK tidligere kaldet IFS) ?
MS forsøgte at lave det samme med WinFS. Omend det jo ikke blev til noget.
14 skrev:
og du ikke har nogle åbenlyse fordele af at gemme filer i forbindelse med din metadata,
Transactional integrity og nemmere administration er åbenlyse fordele.
14 skrev:
Andre argumenter er dog pladsforbruget, der alt andet lige og typisk bliver større, når du pakker et lag udover.
Umiddelbart finder jeg det ikke indlysende at:
BLOB overhead > fil ref + fil overhead
14 skrev:
Det vigtigste argument er dog nok ydelse, idet du får et væsentligt spild, hvis du ikke kan lade din server håndtere filer direkte, men skal initialisere en databaseforbindelse, vælge objektet og returnere det. Selvfølgelig kan det optimeres,
Det er jo det traditionelle argument mod filer i database. Jeg synes bare ikke at virkeligheden matcher.
Og det er faktisk dyrere at åbne en fil på disk end det er at låne en database connection fra connection pool !
14 skrev:
men jeg er ret sikker på, at fx Flickr gemmer filer fysisk. Det er simpelthen tåbeligt andet.
Jeg ved ikke hvad Flickr bruger. De bruger næppe en standard database. Da de må have flere PB data.
Jeg tror heller ikke at de gemmer filene i et enkelt fil system og path i en database. Det vil slet ikke skalere i den målestok.
Med stor sandsynlighed har de en custom løsning. Og så kan vi diskutere om den custom løsning er en database eller ej.
14 skrev:
Hvis du kun måler backup i, hvor let det er at konfigurere, har du ret. Det er bare sjældent tilfældet. En backup skal jo også gerne være funktionel, hvis uheldet er ude, og det kan det være af flere årsager. Hvis du bare skal gendanne alt fra kopien, er din løsning også lettest, men hvis du skal ind og gendanne en specifik fil uden at berøre andre data, er det med værktøjer som fx Tivoli noget lettere, når filen er fysisk.
Generelt har jeg ikke meget fidus til "vi har fundet en fejl og nu laver vi en restore af den del af data og så regner vi med at alle data er konsistente" filosofien.
arne_v: Nu hvor du er ved at kommentere på databaser kunne du måske svare på de sidste spørgsmål der kom til dig i den sidste tråd omhandlende billeder i databaser (Fordele og ulemper ved at gemme binær data i en database)?
#21
Jeg lavede også en test med 250 KB filer.
Resultatet var at alt tog lige lang tid. Tilsyneladende var overheadet ved alle løsninger minimalt i forhold til det at læse de 250 KB op og skovle dem ud.
Jeg ville meget gerne poste tallene. Men jeg gemte dem ikke dengang. Og af en eller anden grund kører testen ustabilt på min PC nu (jeg har opdateret både HW og SW siden). Og en test hvor et antal requests fejler er ikke så overbevisende.
Jeg lavede også en test med 250 KB filer.
Resultatet var at alt tog lige lang tid. Tilsyneladende var overheadet ved alle løsninger minimalt i forhold til det at læse de 250 KB op og skovle dem ud.
Jeg ville meget gerne poste tallene. Men jeg gemte dem ikke dengang. Og af en eller anden grund kører testen ustabilt på min PC nu (jeg har opdateret både HW og SW siden). Og en test hvor et antal requests fejler er ikke så overbevisende.
19 skrev:HTML er ikke designet til Visual Editing, du skal håndkode det!
Der findes rigtigt meget software, som genererer ufatteligt dårligt HTML. Men der findes altså også software, som genererer ganske pæn HTML. Måske ikke perfekt, men acceptabelt.
Hvilken kategori den nævnte software hører i, aner jeg så ikke.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund