am writing a project but am having problem in convert images to byte array and storing in a database and retrieving the byte array from the database and displaying the image using java can you help please

maybe if u can be specific and mention the exact problem u r having, i might be able 2 make suggestions. also what rdbms r u using?

I think it's a good idea not to store images in a database. Why not just store the filename in the database?

i really don't think u have enough info about the app 2 know it's a bad idea 2 store images in a db.

I dont usually store images in db too, I store path names, well researching for you, will get back

i really don't think u have enough info about the app 2 know it's a bad idea 2 store images in a db.

Let's hope he gives us further details about his application, but it's a reasonable assumption

it is advantageous 2 store a file as an object in cases where u want 2 perform SQL operations involving the file such as selecting all records fitting a filter like the size of the file or containing a particular string/pattern, or even enforcing a constraint. it will be tedious if the file is stored on the file system. it might also provide some form of security as no likely dangerous files are introduced to the file system.

cyberbob:

am writing a project but am having problem in convert images to byte array and storing in a database and retrieving the byte array from the database and displaying the image using java can you help please

Which db are you using you might be trying to store more than the maximum allowed byte size in the blob

google.com

logica:

it is advantageous 2 store a file as an object in cases where you want to perform SQL operations involving the file

SQL operations don't work on files.  They work on tables and fields.

such as selecting all records fitting a filter like the size of the file

You can store the file size in the database, so you can SELECT size FROM files WHERE name="topsecret.doc"

or containing a particular string/pattern

If your data is pure text, this makes some sense.  But let's face it, the .txt files are not very common and can usually be broken down into a more structured form.  Common file types include .doc, .zip, .pdf, .jpg, .gif, .wmv, .avi are binary files, and you can't search them without converting them to text first.

or even enforcing a constraint.

This is vague.  The devil is in the details! 

it might also provide some form of security as no likely dangerous files are introduced to the file system.

Come on.  This is a very long shot. If a file is that dangerous I don't want it in my database either.

You have tried, but in real life files (especially images) should be stored in a special folder on disk.

"SQL operations don't work on files.  They work on tables and fields"

sql operations do work on files stored as BLOBs which is a field in the intended table isn't it? and what essentially is a BLOB if not just a sequence of bytes? u can perform string operations on these. i don't get your point here, as you seem to agree with the point i raised.

File size
i already thot about storing the file size in the db, but that is still replication of detail/duplicity. u r storing the same information about the same entity 2ce, as opposed to a file stored as a BLOB, where the size of the file is simply the length of the BLOB - LEN(imagine_file).

Contraint
the size of file allowed for example. i know u will say this can be enforced before trying to store the file, but the database enforcement is more difficult to get around.

Security
a file stored in a db is benign and not likely to cause any harm (it is simply a sequence of bytes like i said earlier). now imagine a hypothetical exploit with images for instance (not sure if any have been discovered, but i can bet they do exist). an image file that has been modified to take advantage of this hypothetical exploit cannot do much if stored in a db table, than if stored in the file system where it is possible to perform an execute operation or some other trigger condition/operation might occur. that u don't want it in ur db is not the issue here after all it would have made its way 2 ur file system anyway, but there in the db it is harmless.

Just to add some web info to this very interesting debate (bold emphasis mine):

Should I store images in the database or the filesystem?
I *strongly* recommend storing the file in the filesystem and its LOCATION in the database, though there are several components out there that make storing images in a database really easy. My preference is ASPUpload from Persits Software. You can see how simple the code is by looking at AspUpload.com - User Manual. Chapter 4.

You can also handle this type of task without a component, but it's a lot more code. There are good examples available at ASP 101 and StarDeveloper.

Here are the arguments for each methodology.

[b]Keep images on the filesystem, and the location and other data in the database

   1. if there is any chance that you will migrate to a different database platform, your current BLOB format might be incompatible with, or at least a pain to convert to, the new format -- since, like web browsers, each vendor has implemented things with their own slant.
       
   2. when your database really goes south, to the point where even the backup is useless, you still have the files on the filesystem (though their usefulness is questionable, depending on how much related data was kept in the database). Which is arguably better than losing all of your data *and* all of your files.
       
   3. having the images in the file system allows you to access the images from many different standard applications (FTP, web browser, etc) without having to write application code to pull the data out of the database, since you can't just 'SELECT image FROM table' and have the image appear in Enterprise Manager or Query Analyzer.
       
   4. with some databases, e.g. Access and MSDE, the data inside is limited to 2 GB (SQL Server Express 2005, as of July 2004, is planned to support 4 GB), whereas the file system is only restricted by the size of the volume. Also, most hosts charge a premium for SQL Server storage space, so in that case it would be cheaper to store them in the file system.
       
   5. in SQL Server 7.0, when a table has an IMAGE or TEXT column, a page is reserved for every row, whether or not that column has any data,  so if you don't have an image for each record, there is potential to have a lot of wasted space. There are workarounds to this, of course, such as splitting the image data into its own table with a foreign key to the main table. SQL Server 2000 *can* combine multiple images < 8kb on one page (but typically, high-volume sites with plenty of images are not focusing on file sizes < 8kb anyway). Also, in SQL Server 2000, if your images are less than 8kb, you can use the text in row option by running the following code:
       
      EXEC sp_TableOption N'TableName', 'TEXT IN ROW', 'ON'
       
      Of course you will have to be careful with this option if you have other TEXT / IMAGE columns in the table.
       
   6. performance wise, including an <IMG SRC> tag generated by the database and pointing to a file that already exists is going to be faster than pulling the file out of the database, generating a temp file on the web server, and streaming that to the user. Also, table scans take more resources when there is an image datatype as opposed to a varchar that simply holds a 'pointer' to the file's location.
       
   7. can be quite complicated extracting images, say from an Access database, since it adds OLE header info to the file (see KB #175261). With SQL Server it's not so bad; see KB #173308 for an example that works right out of the box, KB #258038 for a VB example using ADODB.Stream, and KB #194975 for samples that use ADO's GetChunk and AppendChunk methods.
       
   8. The number of KB articles involving BLOB/IMAGE columns in SQL Server is astounding. Here is a brief subset:  [/b]

          KB #152805, KB #162032, KB #164972, KB #170296, KB #171369, KB #177067, KB #177114, KB #187966, KB #192489, KB #193640, KB #195530, KB #195539, KB #197043, KB #198487, KB #207396, KB #217102, KB #223758, KB #230044, KB #244962, KB #254253, KB #252948, KB #255632, KB #257767, KB #263553, KB #271344, KB #272220, KB #276041, KB #280684, KB #286257, KB #298835, KB #308775, KB #317670, KB #324432, KB #834604, KB #888494, KB #890759, KB #895203

      So, this should give you some idea of the number of problems associated with using the IMAGE datatype.

Keep the images and associated data in the database

   1. you can protect your images better with SQL Server and file system security, as opposed to simply file system.
       
   2. it can be challenging to keep database and filesystem in sync with each other - if the record is deleted in SQL Server (e.g. through an ad hoc query, or a rollback) how does the file system portion of the application know to also delete the image in the file system? One approach is to use extended stored procedures in SQL Server to encompass the file system operations into the database transactions, however this can become as complex, or more so, than storing the BLOB directly in the database - which gives you greater transactional control and consistency.

The above culled from here: http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html

great points xanadu.

but here is a good read:

http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45

Application designers often face the question of whether to store large objects in a filesystem or in a database. Often this decision is made for application design simplicity. Sometimes, performance measurements are also used.
This paper looks at the question of fragmentation – one of the operational issues that can affect the performance and/or manageability of the system as deployed long term. As expected from the common wisdom, objects smaller than 256K are best stored in a database while objects larger than 1M are best stored in the filesystem. Between 256K and 1M, the read:write ratio and rate of object overwrite or replacement are important factors.
We used the notion of “storage age” or number of object overwrites as way of normalizing wall clock time. Storage age allows our results or similar such results to be applied across a number of read:write ratios and object replacement rates.

u will also find a link to a PDF file detailing the tests: ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf

from the foregoing, on the issue of fragmentation it seems it is best 2 store images as blobs except of course the images we r dealing with here r ultra-high resolution and therefore extremely huge.

u know this discussion just led me to the discovery of Firebird. has anybody tried it? it apparently stores files as blobs much faster than the file can be stored on the file-system. not sure how it compares overall to MySQL but it's also open-source.

For the past 2 weeks or so that i have been toying with image upload, this debate has left me more confused than any other webdesign decision I had to make.

I fancy saving to file and writing details to database but please people,

When I update a file from a form, will the new file DELETE the old one in the process or will it just add one more file in the directory?

i believe that's a detail left 4 u 2 implement in ur code in the procedure that writes the file.

@logica,
why not help with the implementation of that procedure.

sorry i don't have the time, but it's easy enough:

i believe java allows u 2 check the existence of a file in the file-system: http://www.roseindia.net/java/beginners/file-directory-exists.shtml . so, in the same procedure (method) that u use in writing the file to the file-system, it could be done using a loop that if the file or copies of it already exist, u simply rename new copies of a file sequentially e.g if the file in question has the name "somefile.doc", new copies of the file can be called "somefile01.doc", "somefile02.doc", etc. i'm sorry if all i said is of no use 2 u.

hmmm,

upon all the big grammar, theories and arguments, this thread never finish. You sure say d poster still dey follow una so?

Okay, back to my ROM (Read Only Mode, aka fly on the wall) mode

First of all,if you re building an application in jsr 316 where images can be handled by the Icon interface,you wouldn't need a byte []array.but if its web based,u would need a byte array.an ejb class should persist the image in bytes to the db,to retrieve it on view you wil require a servlet using the image Id from the page request to get the image in byte array and the servletoutputstream object will be written to be viewed. You should understand dat this is a deserializing /serializing process,