<?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: Optimizing Peachtree Performance, Part 1</title>
	<atom:link href="http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/feed/" rel="self" type="application/rss+xml" />
	<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/</link>
	<description>Fruitful commentary on Peachtree Accounting from TriStar Data Systems</description>
	<lastBuildDate>Thu, 08 Dec 2011 17:16:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Timothy Seibert</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-62</link>
		<dc:creator>Timothy Seibert</dc:creator>
		<pubDate>Fri, 29 Oct 2010 15:20:31 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-62</guid>
		<description>Thank you for the quick Reply I will get right on that.</description>
		<content:encoded><![CDATA[<p>Thank you for the quick Reply I will get right on that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tristar</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-61</link>
		<dc:creator>tristar</dc:creator>
		<pubDate>Fri, 29 Oct 2010 15:02:52 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-61</guid>
		<description>Part 2 never got published because Peachtree went to Pervasive 10 when they rolled out Peachtree 2010 (and now Peachtree 2011), which is a different beast entirely from Pervasive 9.x. The Old Version 9.x tricks don&#039;t seem to work with the 10.x engine, and my tech buddies have not yet figured out an acceptable tuning protocol for this version of Pervasive that adds any significant performance boost to Peachtree.

Having said that, I can tell you that the single biggest performance killer in Peachtree is the size of your JrnlRow.DAT file. If you go to Help &#124; Customer Support and Service &#124; File Statistics, you can check both the number of records and the file size for each Peachtree table. If your Journal Row file exceeds about 200,000 records, you will notice significant performance bottlenecks. The solution to this is to do a purge. Many users think that these old records are automatically purged when year end closing is performed, but they are not. They hang around forever until they are removed via the purge process. There is a whole set of &quot;lore&quot; associated with best practices for performing purges on large databases, which you will want to be aware of before starting this process.

And based on your post, if I am correctly inferring that you may have 7 users hitting your server via terminal services, you are WAY under spec with only 4 Gb of RAM. If you were running Peachtree 2011 on Server 2008 (which works just fine) I would recommend 1 Gb RAM per user, PLUS 4-8 Gb for the server itself. Sounds like that box should have about 16 Gb RAM to run efficiently.</description>
		<content:encoded><![CDATA[<p>Part 2 never got published because Peachtree went to Pervasive 10 when they rolled out Peachtree 2010 (and now Peachtree 2011), which is a different beast entirely from Pervasive 9.x. The Old Version 9.x tricks don&#8217;t seem to work with the 10.x engine, and my tech buddies have not yet figured out an acceptable tuning protocol for this version of Pervasive that adds any significant performance boost to Peachtree.</p>
<p>Having said that, I can tell you that the single biggest performance killer in Peachtree is the size of your JrnlRow.DAT file. If you go to Help | Customer Support and Service | File Statistics, you can check both the number of records and the file size for each Peachtree table. If your Journal Row file exceeds about 200,000 records, you will notice significant performance bottlenecks. The solution to this is to do a purge. Many users think that these old records are automatically purged when year end closing is performed, but they are not. They hang around forever until they are removed via the purge process. There is a whole set of &#8220;lore&#8221; associated with best practices for performing purges on large databases, which you will want to be aware of before starting this process.</p>
<p>And based on your post, if I am correctly inferring that you may have 7 users hitting your server via terminal services, you are WAY under spec with only 4 Gb of RAM. If you were running Peachtree 2011 on Server 2008 (which works just fine) I would recommend 1 Gb RAM per user, PLUS 4-8 Gb for the server itself. Sounds like that box should have about 16 Gb RAM to run efficiently.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tristar</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-60</link>
		<dc:creator>tristar</dc:creator>
		<pubDate>Fri, 29 Oct 2010 14:52:08 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-60</guid>
		<description>Not if the new computer is running Vista or Windows 7. Time to upgrade that ancient Peachtree license!</description>
		<content:encoded><![CDATA[<p>Not if the new computer is running Vista or Windows 7. Time to upgrade that ancient Peachtree license!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Timothy Seibert</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-59</link>
		<dc:creator>Timothy Seibert</dc:creator>
		<pubDate>Fri, 29 Oct 2010 14:43:49 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-59</guid>
		<description>Where&#039;s Part 2?
I&#039;ve covered everything written here, and I still have some unhappy bookkeepers who want to know why peachtree is so slow.</description>
		<content:encoded><![CDATA[<p>Where&#8217;s Part 2?<br />
I&#8217;ve covered everything written here, and I still have some unhappy bookkeepers who want to know why peachtree is so slow.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joan</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-56</link>
		<dc:creator>Joan</dc:creator>
		<pubDate>Mon, 26 Jul 2010 23:08:56 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-56</guid>
		<description>I have Peachtree complete accounting 2005. Will my program work on a new computer with dual processor?</description>
		<content:encoded><![CDATA[<p>I have Peachtree complete accounting 2005. Will my program work on a new computer with dual processor?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Bayard</title>
		<link>http://tristardatasystems.com/Peachtree/blog/index.php/2009/08/optimizing-peachtree-performance/comment-page-1/#comment-50</link>
		<dc:creator>Greg Bayard</dc:creator>
		<pubDate>Sun, 20 Dec 2009 18:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://tristardatasystems.com/Peachtree/blog/?p=83#comment-50</guid>
		<description>We are running Peachtree Quantum 2009 and the performance has always been barely acceptable.  Generally we have users RDP to the server for large reports.  I&#039;d love to hear about your suggestions for optimizing the Pervasive SQL engine.  While I agree we have a lot of users for Peachtree (~7) and a lot of inventory items (10,000+), we have other applications that use MySQL for the back end and contain far more than 10x the amount of data yet process per item reports 10x faster.  We run a gigabit network and computers average 350Mbps reading from the server (which is a RAID 5 array with Windows Server 2008 32 bit and 4GB RAM), so I doubt the network/server hardware is the problem.  I&#039;d run more RAM and 64 bit Server 2008, but I keep hearing about bad Peachtree behavior in that environment.  We would upgrade to 2010, but other businesses we know who have complain about similar performance issues.</description>
		<content:encoded><![CDATA[<p>We are running Peachtree Quantum 2009 and the performance has always been barely acceptable.  Generally we have users RDP to the server for large reports.  I&#8217;d love to hear about your suggestions for optimizing the Pervasive SQL engine.  While I agree we have a lot of users for Peachtree (~7) and a lot of inventory items (10,000+), we have other applications that use MySQL for the back end and contain far more than 10x the amount of data yet process per item reports 10x faster.  We run a gigabit network and computers average 350Mbps reading from the server (which is a RAID 5 array with Windows Server 2008 32 bit and 4GB RAM), so I doubt the network/server hardware is the problem.  I&#8217;d run more RAM and 64 bit Server 2008, but I keep hearing about bad Peachtree behavior in that environment.  We would upgrade to 2010, but other businesses we know who have complain about similar performance issues.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

