I am happy to say the problem is fixed... It turns out that one table lost an index somehow and when I recreated the index all the speed is back,
(Thanks to Steve for your suggestions and pointing out that "Although it wasn't so critical in single-user, it appears that it's absolutely CRITICAL in multi-user to carefully consider what should be INDEXed.") Has anyone tested speed vs the types of indexes? For example will you get better speed with a primary key vs a single column index? Unique key vs Primary? Foreign key vs single column? Thanks to all for suggestions, Regards, GARY I have a client that has been using Rbase 6.5++ latest version, for a while now and recently they have been adding rows to a database (Presently they have about 28,000 rows). the added rows are parts list that they are adding and recently put 3 or 4 people on for data entry. They are seeing a very large time delay with the added people - from a few seconds to in some cases a few minutes with 3-4 people. Does anyone have any suggestions on tuning the system to improve the speed? The current setting are: Regards, Gary L. Winzeler Command Response, Inc A Consulting Company <http://www.commandresponse.com> email <mailto:[EMAIL PROTECTED]> Telephone 408-847-4800 Fax 408-847-4097 Cellular 408-483-7739 ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
