upload images in mysql

Going forward (and probably not directly related to your issues here) you should consider storing the images in the server file system, not in the data base tables.  There are a host of reasons for this, but for now just trust that the right thing to have in the DB is a pointer to the image file, and not the image itself.

HTH, ~Ray

Just to be proactive, ther max size I referred to before is set by the max_allowed_packet variable on the MySQL server.

Your query didn't indicate that you were storing the image data inside the database itself, but if you are, then you should definitely listen to Ray's advice. While MySQL is -capable- of storing image data in the database, it's usually far better to store the files on the server and just store a "reference" to that file in the database.

@Race,

I must disagree in several ways.

> beceause of host space problems.
Databases still take up space, and most hosts will still count the used space against your total space. Plus, base64-encoding the file only makes it larger (usually anywhere from 20% to 30% larger). If you don't believe me, try taking any file on your system and take note of its size. Then in PHP, do something like this:

<?php
print strlen(base64_encode(file_get_contents("/path/to/file")));
?>

The resulting number should be about 30% larger than the original number of bytes. So if the problem is space, then converting a 3 megabyte image might make it into a 4 megabyte string (wasting 1 megabyte), and then you're still saving it on a database that almost always (in shared hosting environments) lives on your same server.

Regarding your methods, you may want to re-think how you handle your own storage problem there. The way you have done it will not perform well with high traffic. I'll explain:

When you store the image data into the database, then in order to access it (and then display it), then you need to query the database for it, right? You have to do it each time that image is requested (unless you have a caching mechanism, but it sounds like you're trying to get around a different problem). When you pull data out of the database with a query, it's still a process of copying/transferring data from the database into the memory that PHP can access.

So if you think about it, every time a 3-megabyte  image is accessed from the database, you are downloading 4 megabytes of Base64 data (pieces at a time, which is even slower), then you are running a process to decode 4 megabytes of Base64 data (which can be very CPU intensive for that file size), and THEN sending 3 more megabytes of the final data to the visitor.

That is REALLY bad in terms of resource usage. You're using up a LOT of memory, a LOT of CPU, and a LOT of bandwidth, and you're not really gaining anything.

Imagine if you had a nice, big painting of your family. You could store it in your living room, where it's convenient to view. What you are doing is the equivalent of cutting up your painting into a bunch of pieces, then putting each piece into its own locked box and storing the boxes in your basement. Every time someone comes over and wants to see your family portrait, you have to go to the basement (the database), open all the boxes (the fields containing your data), and paste the painting back together carefully so it looks perfect (combining the fields and base64-decoding), and THEN show it to your visitor (the visitor downloading the image from their browser).

You're claiming you're doing this because you have no space in your house, but in reality, the basement is probably still part of your house. It's not like you have a basement that has unlimited space - it's just a different part of your house space (your hosting space), and all the different lock boxes actually take up a little more room than the original painting did, so you're losing more space, and you're doing a lot more work to show the painting than what really needs to be done.

Disk space is the cheapest part of web hosting today - if you tell us what host you are using where they do not count database space and have some really low limit with disk space, I'm 110% sure that I could probably recommend a better host at the same price (unless you're getting this for free or are on some $1/month host that gives you no support or anything).

It doesn't matter if your file is small or large, there are very, very few times where storing a file into a database is ever useful. I have done it a few times on projects where I thought it would be easier for one way or another (e.g. portability so I could move the database), but every single time I've done it, I have regretted it later and seen that storing it on the filesystem would have been much better and faster (ESPECIALLY with smaller files, since those can be cached more easily by the web server and thus delivered to the visitor EXTREMELY fast).

That said, please do not take this as criticism of YOU. This is all meant to be constructive criticism, and I am trying to steer you away from a mistake that MANY people have made.

And, while I don't want to encourage the use of MySQL to store image data, I should point out that there IS an appropriate way to store it without base64-encoding and without splitting it into small strings. The BLOB fields (e.g. BLOB, LONGBLOB, etc...) can hold raw data. By using hex-encoding, you can tell the database to store the raw data as-is:

$data = file_get_contents("myfile.jpg");
$arrData = unpack("H*hex", $data);
$hex = "0x" . $arrData["hex"];

INSERT INTO (blobfield) VALUES ($hex);

Of course, this way is still limited by the max_allowed_packet setting in MySQL, so if you absolutely MUST use this method, then you would have to get your host to increase that setting to something that would be larger than the file size you're uploading (if you're uploading 4-megabyte files, then have it increased to 6 megabytes, just in case you come across a a slightly-larger file - it won't hurt to have a slightly-larger limit )

i agreed its not a great solution and i do not used that system for images but for files (*.zip *.pdf, ...).
The reason i did this is beceause i have only 50MB on disk space on my host and no database limit or badwith limit, so this was the only method to solve it.
But you are right about the base64 encoding, that part is not nessecary, i could also splitted the blob into several parts, and save some database disk space so.

50 megabytes of disk space? That is REALLY low by today's standards. Who is your host?

Priorweb from belgium http://www.priorweb.be/hosting/web/economy
but it's quite old already, have it now for 7 years or something and they never changed it.

Wow! 75 euros, too. You should really look for a different host. I'm not familiar with Belgium-specific hosts, but given the exchange rate ($112 US), that's ALMOST like paying for this plan on a month-to-month basis:

http://www.jaguarpc.com/shared-hosting/

(paying in advance would make it cheaper than the 75 euros you're paying now). And that one gives you unlimited disk space.

I'm not saying you should go with JaguarPC, but it should definitely illustrate that there are some better hosts out there for the same price or cheaper.
...