Jim DeMarco
Jdemarco at hudsonhealthplan.org
Thu Apr 28 14:42:24 CDT 2005
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". ***********************************************************************************