 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Developer</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/developer/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/developer/</link>
	<description></description>
	<lastBuildDate>Sun, 19 May 2013 03:14:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: papp</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/developer/#comment-50761</link>
		<dc:creator>papp</dc:creator>
		<pubDate>Mon, 03 Dec 2007 03:22:32 +0000</pubDate>
		<guid isPermaLink="false">#comment-50761</guid>
		<description><![CDATA[Access 2.0 was lean... and mean but broad distribution and security have made recent Access versions, not such an excellent medium for larger data formats. I am guessing if you have already gone production you are seeming massive increased use of drive space, even on NTFS-compressed. It all depends on how many shared access points you expect in use, and how much data, not just what you are inputting but how much can users change. This means you may want to store the scans in a separate server and use call-up links to the scans in the database. This will help tremedously to keep space and fragmentation down on the database itself.]]></description>
		<content:encoded><![CDATA[<p>Access 2.0 was lean&#8230; and mean but broad distribution and security have made recent Access versions, not such an excellent medium for larger data formats. I am guessing if you have already gone production you are seeming massive increased use of drive space, even on NTFS-compressed. It all depends on how many shared access points you expect in use, and how much data, not just what you are inputting but how much can users change. This means you may want to store the scans in a separate server and use call-up links to the scans in the database. This will help tremedously to keep space and fragmentation down on the database itself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: it1</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/developer/#comment-50594</link>
		<dc:creator>it1</dc:creator>
		<pubDate>Wed, 14 Nov 2007 08:58:41 +0000</pubDate>
		<guid isPermaLink="false">#comment-50594</guid>
		<description><![CDATA[Yes, I will import to a document format through OCR stored as a PDF file. All documents include pictures text and so forth and we need to store a soft copy of each for security reason.we have already developed the database but we then decided to store documents also.We actually need a simplest and less expensive way or maybe a command to use for storing scan data on database.]]></description>
		<content:encoded><![CDATA[<p>Yes, I will import to a document format through OCR stored as a PDF file. All documents include pictures text and so forth and we need to store a soft copy of each for security reason.we have already developed the database but we then decided to store documents also.We actually need a simplest and less expensive way or maybe a command to use for storing scan data on database.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 3/10 queries in 0.038 seconds using memcached
Object Caching 280/286 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-20 01:04:11 -->