Mirtheil,

Thank you for your response. Sorry that I wasn't navigating the proper channels. I'm not entirely sure what version of PSQL they are using. Thank you for the info on the RAM. The behavior that is slowing down efficiency is when going into DBA Classic for a host of different searches from inventory reports(Specific part inquiries) to work order inquiries. The facility has a total of 35 terminals for accessing DBA and uses 25 regularly(Not sure if that information would be helpful to you).

If anything would you suggest having a professional come in and take a look at the system so that a proper assessment can be made?

Thanks for your help,


Benjamin

The easiest way to tell the version of Btrieve/PSQL being used is to look at the Version resource in the Properties page for NTDBSMGR.EXE, W3ODBCEI.DLL, W3ODBCCI.DLL, and/or WBTRV32.DLL.
Just to clarify, the performance problem you are seeing is occurring when searching for information (like parts or work orders). Is that correct? Also, what is the exact behavior? For example, does it take 3 minutes to search for a work order or part inquiry?
25 - 35 users should not be taxing the engine very much. I know of sites running 1000 or more users without any problem.
The first thing I would suggest would be to narrow down the problem. Specifically, is this a problem with the application, network, or Btrieve/PSQL? To eliminate the application, you should try the same (or similar operations) using the Btrieve Function Executor. For example, if you open a file, read 10 records, and close the file in DBA, then you should try the same in the Function Executor. Does it take the same amount of time? If so, then the application is not the cause. To test the network, run the Pervasive System Analyzer network tests (not Btrieve or relational tests). Check the performance of the test to see if it is slow or fast.