![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Sun, Jun 7 2009 9:40 AM | Permanent Link |
"John Taylor" | 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 |
Sun, Jun 7 2009 11:08 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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] |
Sun, Jun 7 2009 11:17 AM | Permanent Link |
"John Taylor" | 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] > |
Sun, Jun 7 2009 11:38 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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] |
Sun, Jun 7 2009 1:02 PM | Permanent Link |
"John Taylor" | 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] |
Mon, Jun 8 2009 3:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |