We've been using DBIsam 3.30 for years not to store tif files in a
BLOB field in out database.  These tif files may be only one page
or may be say 40 or 50 pages.  

We're moving on the DBISam 4. for the next release.

I'm tempted to simply store a fully qualified filename in the database
and store the tif file to disk rather than use BLOBs to store the tif's

Anyone got opinions pro or con about this design ?

I realize the dangers of the file being deleted out of program control
but I'm also thinking about data corruption and what happens to the
BLOB file which means all images are lost.

Opinions anyone ?

Thanks

JT

John


I wouldn't worry to much about the blob file getting corrupted 1. its very rare and 2. even if it does happen the worst is you'll loose a few tiffs not the whole file. As compensation for that minor risk backing up becomes a bit simpler.

I'd look more at how you intend to use them and which is best for your program design.

Final point. If you do store in the table make sure you check out what is the best blobblocksize for you.

Roy Lambert [Team Elevate]

That's the way we've always done it using BLOB's it hasn't been any problem
to speak of
in the past save a few incidents of data corruption.  Right On ! about the
blocksize

A downside of storing to files is that if the user needs or wants to move
the app and data to
a new computer or move the data to a different drive, I can see a lot of
headaches involved there !

JT


"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:04DAAC1E-FAB9-4C29-8E38-D0474EC1A96B@news.elevatesoft.com...
> John
>
>
> I wouldn't worry to much about the blob file getting corrupted 1. its very
> rare and 2. even if it does happen the worst is you'll loose a few tiffs
> not the whole file. As compensation for that minor risk backing up becomes
> a bit simpler.
>
> I'd look more at how you intend to use them and which is best for your
> program design.
>
> Final point. If you do store in the table make sure you check out what is
> the best blobblocksize for you.
>
> Roy Lambert [Team Elevate]
>

John

>A downside of storing to files is that if the user needs or wants to move
>the app and data to
>a new computer or move the data to a different drive, I can see a lot of
>headaches involved there !

Fully agree. I followed the Eudora model for emails where the attachments are stored as files. Good in some respects but moving items between mail boxes, deleting them etc all cause problems especially when a document is open when its moved or deleted. I also have a sophisticated chunk of code to allow for users moving the app to a different PC, from standalone to networked etc.

Roy Lambert [Team Elevate]

Yep !  I'm sticking with BLOBs


JT

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:755B0C6B-5DD8-487E-AB06-A7775FF629E0@news.elevatesoft.com...
> John
>
>>A downside of storing to files is that if the user needs or wants to move
>>the app and data to
>>a new computer or move the data to a different drive, I can see a lot of
>>headaches involved there !
>
> Fully agree. I followed the Eudora model for emails where the attachments
> are stored as files. Good in some respects but moving items between mail
> boxes, deleting them etc all cause problems especially when a document is
> open when its moved or deleted. I also have a sophisticated chunk of code
> to allow for users moving the app to a different PC, from standalone to
> networked etc.
>
> Roy Lambert [Team Elevate]

John,

<< Opinions anyone ? >>

Go with the BLOBs.  4.28 has more stable BLOB handling code than earlier
versions (similar to ElevateDB), so it will minimize any chance of BLOB
corruption.

--
Tim Young
Elevate Software
www.elevatesoft.com