database capabilities

[billc]

Does anyone know which btrieve version is PT2002 running on and how many transactions (ballpark figures)can it take per month before it really slow down ?

Regards,
billc

[Marka]

BillC

I do not know off the top of my head which version of Btrieve Peachtree runs but I would think that since Peachtree is not that advanced in the way of record keeping I would think that speed of database reading/writing would be more up to the speed of your system than Btrieve's capability at this point.

I could be wrong but I think my logic holds true here.

Mark

[Robert Walraven]

PT2002 AKA V9 uses the same old V6.15 Btrieve that it has used for a long time. (BTW, this version is considered obsolete by Pervasive.) I suspect there would be no noticable improvement in performance if they updated to the latest version.

The speed of Peachtree as a function of how much you use it per month is a nebulous thing to try to measure - it depends on many different factors. I think the correct answer to your question is "the number of transactions per accounting period that it takes for you see a significant degradation in performance doing whatever it is you do with Peachtree, measured by whatever method you choose, running on the hardware and Windows version of your choice, with Peachtree scattered around your network in whatever fashion you prefer."

[Jacky Tse]

If you're using Peachtree over a network, of course the network performance, including the server and disk performance will affect.

But still the prime factor is as Robert said the number of transactions. Pay attention to the size of the journal data file, you can check the size from the Help menu choose "File statistics." Check the number of records and size of Jrnl Header and Row. Our experience is if the size grows larger than 5Mb, performance starts degradation obviously.

However, no scientific figure is available in this moment.

[billc]

I guess one way is to work backwards ie. enter a sales transaction or GL journal with a couple of line items, save it and observe how many Kbytes it consumes, divide by Jacky's 5Mb observation and finally divide by 24 periods...it's very subjective...but I think its a start and ...better than nothing.


Thank you all,
Billc

[Robert Walraven]

While the speed of Peachtree access degrades continuously as journal records are added, there are other factors that can significantly affect performance. As Jacky mentioned, running on a network is a big one. Another factor how much stuff your system can cache and what you have running - once you get over the caching threshold performance takes a big jump downward. Another big problem is a badly fragmented system - this can slow your entire system down tremendously and also cause the probability of errors in Peachtree to soar.

Starting with V8 Peachtree normalized its journal data so the new JrnlHdr and JrnlRow have fixed size records. However, the number of entries in the JrnlRow file per journal transaction can vary a lot. Payroll records typically have 65 entries. Sales Journal records will have typically 3*number of detail lines + 1 + number of tax authorities, so the amount of space a Sales Journal record uses is highly variable.

We have customers who have sent us Peachtree databases that are over 100 MB and they seem to be living with the performance issue, so again I say the point at which you feel performance is no longer acceptable is whatever you feel it is for your configuration and useage.

[riscniaga]

hi,

i have a client with the following:

peachtree complete 7.0
7 concurrent users on network with xeon server
100+ transactions per day
3 very active companies with 50mb each (3 years cummulative data)

performance is ok, when using new client computers (pentium 500 with 32mb ram and above) - when using older client computers, it will occassionally crash after more than 4 hours of continuous use.

their reason for continuing to use peachtree - simple to use, affordable, and more reliable than those in that range (e.g. myob)

my advise for companies with more than 5 users and more than 100 transactions per day - get an accounting system with an sql database which is scalable and reliable.