469,648 Members | 1,523 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,648 developers. It's quick & easy.

Browser Issue

I have written the following code as a test, (yes I know it is a
resource hog). Basically it pulls all images out of a MySQL table.

<?php
$conn = mysql_connect(host, user, pass);
mysql_select_db(testuser, $conn);

$query = "SELECT * FROM gallery";
$result = mysql_query($query, $conn);

echo "<table width=\"50%\" align=\"center\">";
while($row = mysql_fetch_array($result))
{
echo "<tr>";
echo "<td>$row[NAME] <br> $row[DESC] </td>";
echo "<td><IMG SRC=\"data:image/jpeg;base64," .
base64_encode($row[IMG]) . "\"></td>";
}
echo "</table>";
mysql_close($conn);
?>

Now I don't know where my problem is, but, when viewed with firefox, the
images load correctly, however when viewed with Internet explorer, the
images do not load.

You can see a example of the script in action at
http://codegurus.org/~mwalker/test.php

Does anyone know why the images will not show up in IE correctly?
Apr 13 '06 #1
19 1494
Materialised in news:4a************@individual.net wrote:

[...]
echo "<td><IMG SRC=\"data:image/jpeg;base64," .
base64_encode($row[IMG]) . "\"></td>"; [...]
Now I don't know where my problem is, but, when viewed with firefox, the
images load correctly, however when viewed with Internet explorer, the
images do not load.

You can see a example of the script in action at
http://codegurus.org/~mwalker/test.php

Does anyone know why the images will not show up in IE correctly?


AFAIK IE doesn't recognize <img> tags with inline source. No wonder you only
see it working in Firefox (and probabily Opera, too).

--
ColdShine

"Experience is a hard teacher: she gives the test first, the lesson
afterwards." - Vernon Sanders law
Apr 13 '06 #2
ColdShine wrote:
Materialised in news:4a************@individual.net wrote:

[...]
echo "<td><IMG SRC=\"data:image/jpeg;base64," .
base64_encode($row[IMG]) . "\"></td>";

[...]
Now I don't know where my problem is, but, when viewed with firefox, the
images load correctly, however when viewed with Internet explorer, the
images do not load.

You can see a example of the script in action at
http://codegurus.org/~mwalker/test.php

Does anyone know why the images will not show up in IE correctly?


AFAIK IE doesn't recognize <img> tags with inline source. No wonder you only
see it working in Firefox (and probabily Opera, too).

Thanks for your reply.
Do you know of any work arounds?
Apr 13 '06 #3
Save the image to a file. Not sure why the images are not in a file
anyway. Never could understand putting the images in a db.

Apr 13 '06 #4
fletch wrote:
Save the image to a file. Not sure why the images are not in a file
anyway. Never could understand putting the images in a db.

As I previously said, I have my reasons for storing the image to a database.
The main one is for secondary back up purposes.
Apr 13 '06 #5
> As I previously said, I have my reasons for storing the image to a database.

Not in this thread.

You _must_ have files that need backing up as well? Do you know of
rsync?

It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.

Apr 13 '06 #6
fletch wrote:
As I previously said, I have my reasons for storing the image to a database.


Not in this thread.

You _must_ have files that need backing up as well? Do you know of
rsync?

It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.

The client specifies the backup medium, mine is not to question why. lol
Apr 13 '06 #7
Ah one of _those_ clients. I have a few of them. Urgh. Like the one who
wanted a web based test which was to be delivered on CDRom and run on
only one laptop. My Javascript skills improved a lot though.

Apr 13 '06 #8
Materialised wrote:
ColdShine wrote:
Materialised in news:4a************@individual.net wrote:

[...]
echo "<td><IMG SRC=\"data:image/jpeg;base64," .
base64_encode($row[IMG]) . "\"></td>";


[...]
Now I don't know where my problem is, but, when viewed with firefox, the
images load correctly, however when viewed with Internet explorer, the
images do not load.

You can see a example of the script in action at
http://codegurus.org/~mwalker/test.php

Does anyone know why the images will not show up in IE correctly?

AFAIK IE doesn't recognize <img> tags with inline source. No wonder
you only see it working in Firefox (and probabily Opera, too).

Thanks for your reply.
Do you know of any work arounds?


What you need to do is create a PHP file to fetch the image, i.e. similar to:

getpic.php:
<?
if ($_GET['pid']) {
(connect to database and fetch row into $data)
header('Content: image/jpeg');
echo $data;
}

Then call it with

<img src="getpic.php?id=1">


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Apr 13 '06 #9
fletch wrote:
As I previously said, I have my reasons for storing the image to a database.

Not in this thread.

You _must_ have files that need backing up as well? Do you know of
rsync?

It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.


Sure - there are very good reasons for keeping images in the database. I also
do it when appropriate.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Apr 13 '06 #10
> Sure - there are very good reasons for keeping images in the database. I also
do it when appropriate.


You can't leave it there! What are they!

Apr 13 '06 #11
fletch wrote:
Sure - there are very good reasons for keeping images in the database. I also
do it when appropriate.

You can't leave it there! What are they!


Sure I can! :-)

Right off the top of my head - right now I'm working on a catalog of products to
display. Products come and go regularly; additionally sometimes we get a new
image for an item, so those also are dynamic. And all is updated through web pages.

Keeping the image in the database with the rest of the data prevents broken
links because files are erased, makes it easier to update a picture in the
database and automatically deletes the picture when the product is deleted.

Plus the database is much more dynamic than the rest of the site. The database
will be backed up daily, while the rest of the site only about once a month.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Apr 13 '06 #12
Storing images in a database can be quite appropriate if the record and
the image are considered a single entity.

This way your application doesn't need to bother with storing the
images on the filesystem, and for example deleting them when you delete
or update the record. You also are sure your images don't get deleted
from the filesystem while they are still being referenced in a database
record.

So even if you trade in some DB performance for this design, in some
cases it still can be justified.

fletch wrote:
Sure - there are very good reasons for keeping images in the database. I also
do it when appropriate.


You can't leave it there! What are they!


Apr 13 '06 #13
On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.


What about situations where there are multiple front-end web servers
connecting to multiple database servers.

You don't really want to allow users to upload images (profiles, forums,
etc) in to a folder on one of the machines (whichever one of the farm they
happen to connect to for the upload process) and then have to sync between
every server to every other server every few minutes.

Of course, shared storage (NFS etc) is another way of getting the same
goal, but multiple DBs may be more fault tolerant.

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

Apr 13 '06 #14
d
"Gerry Vandermaesen" <ge****************@gmail.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...
Storing images in a database can be quite appropriate if the record and
the image are considered a single entity.

This way your application doesn't need to bother with storing the
images on the filesystem, and for example deleting them when you delete
or update the record. You also are sure your images don't get deleted
from the filesystem while they are still being referenced in a database
record.
So it's a case of slowing down the user's experience because the coder was
too lazy to figure out how to link files to database records accurately? :)
So even if you trade in some DB performance for this design, in some
cases it still can be justified.
I've not yet heard a good reason ;)
fletch wrote:
> Sure - there are very good reasons for keeping images in the database.
> I also
> do it when appropriate.


You can't leave it there! What are they!

Apr 13 '06 #15
d
"Andy Jeffries" <ne**@andyjeffries.co.uk> wrote in message
news:pa****************************@andyjeffries.c o.uk...
On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.
What about situations where there are multiple front-end web servers
connecting to multiple database servers.

You don't really want to allow users to upload images (profiles, forums,
etc) in to a folder on one of the machines (whichever one of the farm they
happen to connect to for the upload process) and then have to sync between
every server to every other server every few minutes.

Of course, shared storage (NFS etc) is another way of getting the same
goal, but multiple DBs may be more fault tolerant.


Shared storage is the answer in that situation - storing images in a
database has such a massive overhead, not to mention cumbersome file access.
It might be easier from the coder's point-of-view, but that doesn't mean
squat to a project :)
Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

Apr 13 '06 #16
d wrote:
"Andy Jeffries" <ne**@andyjeffries.co.uk> wrote in message
news:pa****************************@andyjeffries.c o.uk...
On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.


What about situations where there are multiple front-end web servers
connecting to multiple database servers.

You don't really want to allow users to upload images (profiles, forums,
etc) in to a folder on one of the machines (whichever one of the farm they
happen to connect to for the upload process) and then have to sync between
every server to every other server every few minutes.

Of course, shared storage (NFS etc) is another way of getting the same
goal, but multiple DBs may be more fault tolerant.

Shared storage is the answer in that situation - storing images in a
database has such a massive overhead, not to mention cumbersome file access.
It might be easier from the coder's point-of-view, but that doesn't mean
squat to a project :)

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos



I disagree here. Storing images in the database does not have to be "massive
overhead". If they are in their own table (with just id and image, for
instance), there is no overhead when accessing other information. As for
accessing the image itself, when the table is indexed the database can go
straight to the data block containing the start of the image and read from
there. Overhead is not significantly different than what the OS has to do in
searching a directory to get to the file.

Sure, it's a little more overhead. But not that much. And sharing disks or
directories (I assume you mean that vs. memory - which only works on a single
server) can be problematic, also. For instance - storing images with the
equivalent of an autoincrement field. The server has to get a directory
listing, find the next unused number and write the file. No problem here - but
what if two servers want to do it at the same time? Whichever one goes second
will have to detect the file already exists on open, and get a new directory
listing. A database will handle these situations.

All in all, if you don't use a database you're just moving the required code to
the program instead of letting the database handle it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Apr 13 '06 #17
d
"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:pY******************************@comcast.com. ..
d wrote:
"Andy Jeffries" <ne**@andyjeffries.co.uk> wrote in message
news:pa****************************@andyjeffries.c o.uk...
On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:

It is much more efficient to let the webserver deliver images directly,
and as I see it, there is no _good_ reason not to go that route.

What about situations where there are multiple front-end web servers
connecting to multiple database servers.

You don't really want to allow users to upload images (profiles, forums,
etc) in to a folder on one of the machines (whichever one of the farm
they
happen to connect to for the upload process) and then have to sync
between
every server to every other server every few minutes.

Of course, shared storage (NFS etc) is another way of getting the same
goal, but multiple DBs may be more fault tolerant.

Shared storage is the answer in that situation - storing images in a
database has such a massive overhead, not to mention cumbersome file
access. It might be easier from the coder's point-of-view, but that
doesn't mean squat to a project :)

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos



I disagree here. Storing images in the database does not have to be
"massive overhead". If they are in their own table (with just id and
image, for instance), there is no overhead when accessing other
information. As for accessing the image itself, when the table is indexed
the database can go straight to the data block containing the start of the
image and read from there. Overhead is not significantly different than
what the OS has to do in searching a directory to get to the file.

Sure, it's a little more overhead. But not that much. And sharing disks
or directories (I assume you mean that vs. memory - which only works on a
single server) can be problematic, also. For instance - storing images
with the equivalent of an autoincrement field. The server has to get a
directory listing, find the next unused number and write the file. No
problem here - but what if two servers want to do it at the same time?
Whichever one goes second will have to detect the file already exists on
open, and get a new directory listing. A database will handle these
situations.

All in all, if you don't use a database you're just moving the required
code to the program instead of letting the database handle it.


I'd put it that you're moving the work to a different database - the
filesystem, which is built for exactly this kind of thing :)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Apr 13 '06 #18
if you use an OpenVMS cluster as your web-server farm - this is a moot
problem as they natively share - concurrently - the disk devices.

Apr 13 '06 #19
d wrote:
"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:pY******************************@comcast.com. ..
d wrote:
"Andy Jeffries" <ne**@andyjeffries.co.uk> wrote in message
news:pa****************************@andyjeffrie s.co.uk...
On Thu, 13 Apr 2006 01:42:45 -0700, fletch wrote:
>It is much more efficient to let the webserver deliver images directly,
>and as I see it, there is no _good_ reason not to go that route.

What about situations where there are multiple front-end web servers
connecting to multiple database servers.

You don't really want to allow users to upload images (profiles, forums,
etc) in to a folder on one of the machines (whichever one of the farm
they
happen to connect to for the upload process) and then have to sync
between
every server to every other server every few minutes.

Of course, shared storage (NFS etc) is another way of getting the same
goal, but multiple DBs may be more fault tolerant.
Shared storage is the answer in that situation - storing images in a
database has such a massive overhead, not to mention cumbersome file
access. It might be easier from the coder's point-of-view, but that
doesn't mean squat to a project :)

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

I disagree here. Storing images in the database does not have to be
"massive overhead". If they are in their own table (with just id and
image, for instance), there is no overhead when accessing other
information. As for accessing the image itself, when the table is indexed
the database can go straight to the data block containing the start of the
image and read from there. Overhead is not significantly different than
what the OS has to do in searching a directory to get to the file.

Sure, it's a little more overhead. But not that much. And sharing disks
or directories (I assume you mean that vs. memory - which only works on a
single server) can be problematic, also. For instance - storing images
with the equivalent of an autoincrement field. The server has to get a
directory listing, find the next unused number and write the file. No
problem here - but what if two servers want to do it at the same time?
Whichever one goes second will have to detect the file already exists on
open, and get a new directory listing. A database will handle these
situations.

All in all, if you don't use a database you're just moving the required
code to the program instead of letting the database handle it.

I'd put it that you're moving the work to a different database - the
filesystem, which is built for exactly this kind of thing :)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================



Yep, I'm moving the work to a different database - the RDB, which is built for
exactly this kind of thing!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Apr 13 '06 #20

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

115 posts views Thread by J | last post: by
1 post views Thread by Nathan DeBardeleben | last post: by
3 posts views Thread by Rob | last post: by
3 posts views Thread by Ben | last post: by
15 posts views Thread by David Thielen | last post: by
14 posts views Thread by askMe | last post: by
5 posts views Thread by ns21 | last post: by
4 posts views Thread by =?Utf-8?B?TmFkYXYgUG9wcGxld2VsbA==?= | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.