At 03:18 PM 4/01/2005 -0500, you wrote:

>Adrian Wreyford wrote:
>
> > I can store Jpeg images using Jason's IB_JpegImage, but don't think this is
> > the way to go.

IB_JpegImage isn't about storage, it's about interpretation and display on
the client side. The server doesn't care what's in a binary blob.

> >
> > Reason:
> >
> > No control over the size of the image file that the end user will be trying
> > to store in the blob file.
> >
> > I can resize the images, and also compress to a certain degree to limit
> this
> > factor, but still going to overload the database with large amounts of
> image
> > data.

Your real decision is whether you store the images inside the database or
whether you store them in the filesystem and use the database to store the
physical links to the images. Data-aware "containers" like ib_jpegimage
are relevant to the former case, not the latter. If your application pulls
image files from the filesystem, there are plenty of non-data-aware classes
around to choose from.

>Probably not. Databases can get very big with no particular problems,
>especially if the data is in blobs. It does present a problem with
>backup, because the normal databases backup utility, gbak, doesn't
>support incremental backup. Version 2 introduces a new, physical backup
>mechanism that does incremental backups.
>
> > I have read somewhere that Firebird can store to files, and not the .FDB.
>
>Yes, but it's not what you want. People who choose not to store images
>in the database usually write out files through their application and
>store file names in the database.

True.

>Ann H :: That won't work at all with IBO -

Not even slightly true. It's a perfectly normal thing to do in IBO
applications. It's also a perfectly normal thing to do in IBO applications
to make *either* blob-based or file-based images available on demand.

>Ann H :: well it might if you used some smoke, mirrors, and UDF's, but I
>don't
>recommend it.

I wouldn't recommend smoke, mirrors and UDFs for storing file names in the
database. Strings, yes. Filesystem pointers, yes. Duct tape not required.

If you go for the off-line storage option, I do recommend a very well
thought out filesystem structure and application configuration design, so
that you can write a portable application, i.e. one that won't break if you
redeploy it, store the images on CD or memory stick, or whatever.

./heLen