[AccessD] OLEDB vs ODBC

MartyConnelly martyconnelly at shaw.ca
Thu Apr 28 21:13:26 CDT 2005


Have you considered converting your tiff's or jpeg's  to compressed pdf 
or djvu format
both maintain the text portion as a secondary layer.
That would reduce their size by a factor of 10.
Even a bi-tonal tiff of a book page would be a 100K, a photo would 3 or 
4 times that

Francisco Tapia wrote:

>yup that's exactly what I ment..
>
>On 4/28/05, Jim DeMarco <Jdemarco at hudsonhealthplan.org> wrote:
>  
>
>>We had security issues as well since we're scanning personal documentation 
>>(birth certs, ssn's, etc.) which is how we came to store the docs as BLOBs 
>>also.
>>
>>I didn't write the app but was heavily involved in the architecture. We 
>>used a consulting firm to create a scanning component that saves scanned 
>>docs to the BLOB. Until yesterday I was of the belief that we we not storing 
>>the entire BLOB but now it seems we are. I'm assuming that by "entire BLOB" 
>>you mean TIFF (or whatever file format you choose) header and extraneous 
>>data. The consultant had tested the component and assured us that each BLOB 
>>would max at approx. 20K but using the DATALENGTH function James Barash sent 
>>me I see that they are quite a bit larger than expected.
>>
>>Is that what you meant?
>>
>>Jim D.
>>
>>-----Original Message-----
>>From: accessd-bounces at databaseadvisors.com
>>[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Francisco
>>Tapia
>>Sent: Thursday, April 28, 2005 2:15 PM
>>To: Access Developers discussion and problem solving
>>Subject: Re: [AccessD] OLEDB vs ODBC
>>
>>I don't know...
>>
>>While on this topic.... one of the department managers wants to begin
>>archiving photo's with calls received in our customer support center. the 
>>FE
>>is an Access ADP, and generally i'm against storing images inside DBs and 
>>would rather "upload" the image to a location on the server and serve it up 
>>via Access but I'd need to restrict the folder for uploading so that users 
>>couldn't use that as their personal drive either...
>>
>>what method are you using Jim or do you Upload the entire BLOB into the 
>>db?
>>
>>On 4/28/05, Jim DeMarco <Jdemarco at hudsonhealthplan.org> wrote:
>>    
>>
>>>Here's a good one for you. M$ has long been telling us to use OLEDB via 
>>>ADO to access our SQL data. We've been doing just that and in researching 
>>>      
>>>
>>an
>>    
>>
>>>issue where some BLOB image data is pegging our server CPUs when 
>>>      
>>>
>>uploading
>>    
>>
>>>via remote network connections I found a KB article that mentions that 
>>>      
>>>
>>there
>>    
>>
>>>is a bug in the way OLEDB handles large amounts of BLOB data and that 
>>>      
>>>
>>the > ODBC drivers should be used instead.
>>    
>>
>>>My question: Our application (thankfully) uses an n-tier architecture 
>>>      
>>>
>>and > all the data access is done via centralized components. I know using 
>>ODBC
>>    
>>
>>>will require modding the connect string. Once we've got a connection to 
>>>      
>>>
>>the
>>    
>>
>>>database via ODBC will our existing ADO OLEDB code break? AFAIK we're 
>>>      
>>>
>>using
>>    
>>
>>>connection objects, recordsets and command objects. Is there a lot of 
>>>      
>>>
>>SQL > specificity in the way we would access these objects using OLEDB?
>>    
>>
>>>TIA
>>>
>>>Jim DeMarco
>>>Director of Application Development
>>>Hudson Health Plan
>>>
>>>
>>>
>>>      
>>>
>>***********************************************************************************
>>    
>>
>>>"This electronic message is intended to be for the use only of the named 
>>>recipient, and may contain information from Hudson Health Plan (HHP) that 
>>>      
>>>
>>is
>>    
>>
>>>confidential or privileged. If you are not the intended recipient, you 
>>>      
>>>
>>are
>>    
>>
>>>hereby notified that any disclosure, copying, distribution or use of the 
>>>contents of this message is strictly prohibited. If you have received this
>>>message in error or are not the named recipient, please notify us
>>>immediately, either by contacting the sender at the electronic mail 
>>>      
>>>
>>address
>>    
>>
>>>noted above or calling HHP at (914) 631-1611. If you are not the 
>>>      
>>>
>>intended > recipient, please do not forward this email to anyone, and delete 
>>and
>>    
>>
>>>destroy all copies of this message. Thank You".
>>>
>>>
>>>      
>>>
>>***********************************************************************************
>>    
>>
>>>--
>>>AccessD mailing list
>>>AccessD at databaseadvisors.com
>>>http://databaseadvisors.com/mailman/listinfo/accessd
>>>Website: http://www.databaseadvisors.com
>>>
>>>      
>>>
>>--
>>-Francisco
>>http://pcthis.blogspot.com |PC news with out the jargon!
>>http://sqlthis.blogspot.com | Tsql and More...
>>--
>>AccessD mailing list
>>AccessD at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/accessd
>>Website: http://www.databaseadvisors.com
>>
>>
>>***********************************************************************************
>>"This electronic message is intended to be for the use only of the named 
>>recipient, and may contain information from Hudson Health Plan (HHP) that is 
>>confidential or privileged. If you are not the intended recipient, you are 
>>hereby notified that any disclosure, copying, distribution or use of the 
>>contents of this message is strictly prohibited. If you have received this 
>>message in error or are not the named recipient, please notify us 
>>immediately, either by contacting the sender at the electronic mail address 
>>noted above or calling HHP at (914) 631-1611. If you are not the intended 
>>recipient, please do not forward this email to anyone, and delete and 
>>destroy all copies of this message. Thank You".
>>
>>***********************************************************************************
>>
>>--
>>AccessD mailing list
>>AccessD at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/accessd
>>Website: http://www.databaseadvisors.com
>>
>>    
>>
>
>
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada






More information about the AccessD mailing list