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