At 08:24 AM 6/01/2005 +0200, you wrote:

>Dear Helen
>
>Helen: "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."
>
>
>Ann: ">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."
>
>Well it would appear that both file and DB storage are O.K.
>
>I like the idea of having everything in one place. So I'm going to leave it
>in the Database in blobs
>
>A few more questions:
>1). Should I be limiting the size of the jpeg image the end user is storing?

Only if you have a reason to.

>2). Should I use a negative Sub-Type for the Blob, or BLOB SUB_TYPE 0?

AFAICT, this has no bearing at all on your architectural decision. The
server itself doesn't care what you store in blob sub_type 0.

>3). Would you recommend I store these blobs in the same database as all my
>other data, or in a second database? (Probably doesn't matter).

Again, this is a question of need and volume and relates to things like
whether you want to back up the blobs every time you back up the other data
and whether you are comfortable with having no data link connecting the
regular data to the blob data. It makes programming more complex than
putting everything under one roof, but IBO can handle two simultaneous
connections and two-phase commits fine.

>4). I use the IB_JPEGIMAGE to display and store the data.
>.. to get the Jpg file In above, one can drag and drop, or create a viewer,
>that resizes, downgrades quality etc to reduce the size, to acceptable
>limit, then assign to Jason's component, then store as with any other data
>aware component.

Repeat, IB_JpegImage is a client-side container. There is no specialised
blob class in the IBO constellation for jpegs. IBO will stream the bits
back and forth between IB_ColumnBinary and the database, just as it does
with bmp data, Word files or whatever. The TIB_JpegImage component (which
is Thomas Steinmaurer's creation, btw) does the magic to organise and
display the stream as a jpeg image.

>5). What I will do to speed up browsing, is add a toggle under my program
>preferences to display or not display images, thus the server does not have
>to pass the BLOB data, speeding up scrolling quite substantially, and I
>tried this, and it works well .. comment please?

Unless your application is explicitly extracting one row at a time,
on-demand fetching of blobs is the only way to travel with blobs. Even in
the one-row scenario, it's not crazy to make blob-on-demand a user option.

./heLen