×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

(OP)
We are running ACCPAC 5.3 on Pervasive.SQL v8.6 Workgroup. There are twenty company databases and users are complaining that printing PO requisitions takes ages (approx. 5 min) on some databases while it's faster on other databases. Both apps and data reside on the Server.

I have heard of cases where people suggest that I might need to rebuild the slow databases. I posted this issue in this forum because I don't know if it is ACCPAC or Pervasive problem.

I came across a closed thread (thread318-1257565) which I thought was close enough to my problem.  

Any suggestions on how to optimise the printing?

Rgds,
SeisaT


RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Where the problem lies depends on what's actually slow.   If you can read those Pervasive data files through other means and it is fast, and the problem only occurs when printing, then the problem may be in ACCPAC.  
I have never used ACCPAC so I can't tell you how it does things.  
- In terms of Pervasive, I would verify that MKDE tracing is disabled.
- Have you recently defragmented the disk where the data resides?  
- Usually a rebuild of the Pervasive won't help unless there's corruption.  Corruption usually doesn't cause slow performance though.  
- What's different about the databases? Are the slow ones significantly bigger than the fast ones?  

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
http://www.mirtheil.com

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

(OP)
Thank you for your prompt response.

The databases that are slow are bigger than the fast ones because the companies/projects are busier.

Can you give me a clue on how to disable the MKDE tracing?

The data is on the Server running Win 2000 Server, and we haven't run the defrag

I presume the other means of accessing the data you're referring to would be through the Control Centre by directly opening the tables. I will try to access it if thats what you mean and will let you know.

Rgds,
SeisaT

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

How much bigger are the files?  

Quote:

Can you give me a clue on how to disable the MKDE tracing?
The Tracing is set at the server level.  Here's a link to the docs with the setting: [url]http://www.pervasive.com/library/docs/psql/900/advops/advops-06-4.html#wp68848[/url].


Quote:

I presume the other means of accessing the data you're referring to would be through the Control Centre by directly opening the tables. I will try to access it if thats what you mean and will let you know.
Yes, the COntrol Center would be a good test.

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
http://www.mirtheil.com

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

SeisaT -

If a Pervasive Rebuild doesn't fix it, then it's time to move to MSSQL, Oracle, or DB2.  Pervasive's relational engine just can't match the others.

Jay Converse
IT Director
Systemlink, Inc.

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Jay,
Without knowing what's really happening, making a blanket statement like that isn't very helpful.  A rebuild normally won't affect performance.  Granted, if ACCPAC hasn't optimized their queries in the Pervasive engine then no amount of tweaking will help.  

To really help in this case, there needs to be more information.  Specifically, what's the actual query that's being performed.  I know nothing about ACCPAC but it's always possible the problem is in the application not the database.  

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
http://www.mirtheil.com

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

(OP)
Mirtheil,
I tend to agree with Jay here. In fact, I did convert the database in question to MS.SQL and the result is phenomenal. Although I am not a guru of any of the two databases (Pervasive.SWL & MS.SQL),I believe it's a Pervasive issue. One cannot afford to waste time (and time is money in this business) troubleshooting beyond the norm to get to the bottom of the matter. If MS.SQL has resolved this problem withouth any tweaking on the ACCPAC queries, then I also vote for MS.SQL.

But thanks all the same. Pervasive has to get its act together.

Rgds,
SeisaT




RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Mirtheil -

I've been using Pervasive since it was Btrieve on Netware 3, and Accpac since 1989, so my "blanket" statement comes from experience.  Pervasive is great for inserting transactions, but lousy for big reports.  I did a conversion a few weeks ago from Pervasive to Oracle, and on tables over 2 Gb, report time went from 45 minutes to 1 minute.

Jay Converse
IT Director
Systemlink, Inc.

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Jay,
You've got me beat, I've only been developing and supporting Pervasive since 1995.  
I'll admit that the SQL engine with Pervasive isn't the best but I know of a lot of companies that use it successfully and some have even replaced SQL Server.  

Your comment about moving from PSQL to Oracle is interesting but I'm curious, how much more does Oracle (or SQL Server) cost to operate?  Granted, the only queries I've seen on a 2 GB table that took over 45 minutes were one that weren't optimized.  Even a simple "SELECT * FROM TABLE" shouldn't take that long with any database.  

In your experience, how long do the ACCPAC queries take outside the application (through ODBC Test or PCC)?  Are they the same speed?  Have you done any Pervasive work outside the ACCPAC database structure?  

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
http://www.mirtheil.com

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Definitely the cost is higher, but this was a government account where cost doesn't matter.  Their setup had grown from 5 users to 50 users in the last 2 years, and Pervasive just couldn't handle the multi-million row tables and joins any more.  Cross-tabs could take days to complete.  We had even started dumping the data into MSAccess to get reports out.

Don't get me wrong, I like Pervasive, and it's my choice for small to medium-sized businesses.  But it just doesn't scale up like the big boys.

Jay Converse
IT Director
Systemlink, Inc.

RE: Printing too slow Pervasive.SQL v8.6/ACCPAC 5.3

Greetings!  I have been using Btrieve since 1988; and it’s a great database engine for data entry -- but painfully slow even when using Btrieve DDF and not ODBC.

  I have always had to DTS the Pervasive tables to MS Access/MS SQL to facilitate Crystal Reporting.  Trust me -- it’s a win/win for client reporting needs.  The customer experiences not performance hits on their production database and the Crystal Reports(R) comes from a 'reporting' database with the utmost of efficiency.  

  Like Jay, my reports now run in minutes as opposed to several hours!  Trust me -- it’s the best way especially if you have tens of tables joined.

Thanks

James Keep, PMP
Crystal Reports(tm) Certified Consultant 8.5 (CRCC)
Authorized Crystal Engineer (ACE)
CMRC
Crystal Decisions Business Partner
Montreal, Qc, Canada
www.cmrc.qc.ca

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close