Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Borland BDE
- Thread starter roscok
- Start date
Phil,
In a word: don't!
The only thing you *should* do is turn LOCAL SHARE on and make certain that everyone's using the same .NET file.
Instead, focus on optimizing your workstation's use of Windows itself and your use of Paradox:
1. Make sure you have plenty of free disk space.
2. Make sure you have an appropriate amount of RAM for the version of Windows you're using.
3. Make sure your database is efficiently designed and that you're accessing it properly.
For example:
a. SenFilter (and setGenFilter) is slow; setRange is fast. Of course, setRange is more limited with wildcards and requires you to have an index. Still, the speed improvements outweigh the design requirements.
b. Many people make the mistake of trying to do too much at one time. If you have complex queries, try separating them into a sequence of repeated queries, each running on the ANSWER tables created by theprevious ones. You may be pleasantly surprised.
4. Make sure your network is properly configured to handle the requests. Case in point, an older version of Novell defaults the Receive Buffer Packet Size to a very small value. Boosting that to its maximum improved performance for one client dramatically.
While you *can* improve performance somewhat by mucking about with the BDE settings, I have had better luck optimizing the actual application instead of the engine.
I have never seen dramatic improvements through engine-only fiddling. YMMV.
-- Lance
In a word: don't!
The only thing you *should* do is turn LOCAL SHARE on and make certain that everyone's using the same .NET file.
Instead, focus on optimizing your workstation's use of Windows itself and your use of Paradox:
1. Make sure you have plenty of free disk space.
2. Make sure you have an appropriate amount of RAM for the version of Windows you're using.
3. Make sure your database is efficiently designed and that you're accessing it properly.
For example:
a. SenFilter (and setGenFilter) is slow; setRange is fast. Of course, setRange is more limited with wildcards and requires you to have an index. Still, the speed improvements outweigh the design requirements.
b. Many people make the mistake of trying to do too much at one time. If you have complex queries, try separating them into a sequence of repeated queries, each running on the ANSWER tables created by theprevious ones. You may be pleasantly surprised.
4. Make sure your network is properly configured to handle the requests. Case in point, an older version of Novell defaults the Receive Buffer Packet Size to a very small value. Boosting that to its maximum improved performance for one client dramatically.
While you *can* improve performance somewhat by mucking about with the BDE settings, I have had better luck optimizing the actual application instead of the engine.
I have never seen dramatic improvements through engine-only fiddling. YMMV.
-- Lance
- Thread starter
- #3
- Status
Similar threads
- Locked
- Question