>If you use ALLOCATE then the BLOB (when less than or equal to ALLOCATE 
>size) will be stored in the same base record, and one I0 operation will
get both.

Great to know. I assume that that also means that the blob field will
take that amount of space in the record even if it's smaller than the
allocate size, right? And I assume that space is included in the max 32K
record size, right?

>Allocating a 2GB buffer can be more resource intensive than allocating
a 100K buffer... 

Yup. But are you saying you allocate the space and then look at the
actual size?

>I would suggest trying to define the BLOB column as up to 16MB rather
than 2GB 
>when you really don't need it any larger.

16M is a "magic" number on the iSeries. Was that just a number you
picked, or do you do one thing when the max size is < an extent and
another when it's > 16M? 

I guess my issue is, if I don't know the max size, why limit myself.
It's not _likely_ that my blobs would be > a couple meg, but in my case
I'm storing RTF documents, and if the user inserts a couple of images in
a word doc and then converts to RTF it can get big fast!

Also, Can I modify the max size with an alter table, and if so, how ugly
is that? If I put a max of 15M but discover I need to go to 30M after I
have a million rows, have I created a nightmere for myself?

The other obvious solution is to store the RTF file in the IFS and store
a link (datalink, or just a varchar w/the path) in the database.

Thanks,
-Walden


------------
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.