Before teaching others teach yourself

Normally this won't be a big WTF unless it was not in a tutorial article

here: http://www.dotnetcurry.com/ShowArticle.aspx?ID=129&AspxAutoDetectCookieSupport=1

So this article explains how to save image in DB using ASP.NET and how to show it back.

Here are the WTFs that I managed to count. Please let me know if I have missed something:

<asp:FileUpload ID="imgUpload" runat="server" />

...

FileUpload img = (FileUpload)imgUpload;

Why would anyone cast FileUpload to FileUpload?

Here is how we get the byte array for the file from the newly casted file upload:

Byte[] imgByte = null;
if (img.HasFile && img.PostedFile != null)
{
      //To create a PostedFile
      HttpPostedFile File = imgUpload.PostedFile;
      //Create byte Array with file len
      imgByte = new Byte[File.ContentLength];
      //force the control to load data in array
      File.InputStream.Read(imgByte, 0, File.ContentLength);
}

and file upload has FileBytes property which returns byte[] ...

So how do we show the image after we get a byte array from the database:

...
object img = cmd.ExecuteScalar();
try
{
    return new MemoryStream((byte[])img);
}
catch
{
    return null;
}
finally
{
    connection.Close();
}

...

Stream strm = ShowEmpImage(empno);
byte[] buffer = new byte[4096];
int byteSeq = strm.Read(buffer, 0, 4096);

while (byteSeq > 0)
{
    context.Response.OutputStream.Write(buffer, 0, byteSeq);
    byteSeq = strm.Read(buffer, 0, 4096);
}

So first we get the bytes then we pack them into a stream and unpack them into bytes again... cool! And what is a buffer needed for anyway.

I was quite annoyed because this article is supposed to teach others how to do this.

Someone_You_Know

@Stilgar said:

Normally this won't be a big WTF unless it was not in a tutorial article

This sentence caused a segmentation fault in my brain.

They also give you a script to create a table with no index or even a primary key.

Surprisingly enough, though, they *do* use parameterized SQL!

I'd make a joke pertaining to the fact that the domain name is dotnet[B]curry[/B], but it's just too easy.

MasterPlanSoftware

@Aaron said:

I'd make a joke pertaining to the fact that the domain name is dotnetcurry, but it's just too easy.

And you would probably summon tube rodent. It might already be too late.

ammoQ

@MasterPlanSoftware said:

And you would probably summon tube rodent. It might already be too late.

I think he's gone forever. *knocking on wood*

MasterPlanSoftware

@ammoQ said:

@MasterPlanSoftware said:
And you would probably summon tube rodent. It might already be too late.

I think he's gone forever. *knocking on wood*

Well that does it. You have doomed us all. Thanks a lot.

@Someone You Know said:

@Stilgar said:

Normally this won't be a big WTF unless it was not in a tutorial article

This sentence caused a segmentation fault in my brain.

Probably the code caused segmentation fault in MY brain so I messed up my English (which is not my first language... not that I am excused because of this)

alegr

@Stilgar said:

So first we get the bytes then we pack them into a stream and unpack them into bytes again... cool! And what is a buffer needed for anyway.

I was quite annoyed because this article is supposed to teach others how to do this.

Could it just be that memory stream has different properties than HTTP data stream? For example, it never fails, and allows random access, and its lifetime is not limited by any TCP timeouts? Maybe you don't understand some fine points?

Ragnax

@alegr said:

@Stilgar said:
So first we get the bytes then we pack them into a stream and unpack them into bytes again... cool! And what is a buffer needed for anyway.
I was quite annoyed because this article is supposed to teach others how to do this.
Could it just be that memory stream has different properties than HTTP data stream? For example, it never fails, and allows random access, and its lifetime is not limited by any TCP timeouts? Maybe you don't understand some fine points?

Actually, there's a very good use for using a buffer instead of directly passing in the entire memory stream to the output stream. The reason for it lies with the fact that asp.NET usually buffers the entire output stream in memory before starting to send it to the client browser. Using a buffer you can push bite-sized chunks into the output stream and flush those to the client browser manually, chunk by chunk.

Ofcourse, even though the concept of using a buffer isn't that bad, the implementation in this case is.

@alegr said:

Could it just be that memory stream has different properties than HTTP data stream? For example, it never fails, and allows random access, and its lifetime is not limited by any TCP timeouts? Maybe you don't understand some fine points

Even then wrapping the byte array in memory stream does not make sense. After all he already has the byte array. He could use the Response.OutputStream.Write(byte[] buffer, int offset, int count) method to do buffered write if it was so important. But judging by other stuff in the example he has no idea of things like TCP timeouts.