Yes, I understand, if you just change to the owner and force the settings to the correct values there can be a huge time delay. My code avoids all the time consuming stuff because normally it does NOTHING except check the values of the settings. It also tried to just do those that are stored with the DB, as those are the only ones which will be wrong if you are managing your CFG files properly. It also makes the changes so they stick when the db is closed If it frequently has to fix a setting that someone or something is changing as an owner, That needs to be fixed. It could be updated so any change it does make is documented in a table so you can check on that scenario.
Hmm I bet Howard is using a very old version of this code!!!! I may have written it! I wrote the original version over 20 years ago. I took the concept with me when Howard hired me two employers ago! The one in my email solved all those problems and our DBs connect very fast now. That was when we still had a lot of wireless network connections (Interpret SLOW!) Changing some settings takes a significant amount of network traffic. Dennis ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, December 05, 2008 10:46 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Running 7.6 code from a batch? Dennis: But that is what's causing the problems.... The consultant (our friend Howard) uses one piece of code that connects to the database and does a bunch of settings, as you do. I believe he uses this code at multiple clients. From some of the settings that are made, I can tell that the code is pretty old but he is still using it with the DOS front-end of this client. We don't use it in the 7.6 front end. Obviously there is at least 1 setting that causes a huge drop in performance. What I don't know is if this code was always slow, or whether something has changed (operating system, hardware, an RBase DOS version build) so that all of a sudden it became really slow. Howard also isn't sure whether they may have purposely slowed performance by a setting in order to get more reliability. So the lesson is not just to have code that does the settings, but to make sure that the settings you are creating are correct! I can't test the file here because stand-alone I don't see much of a problem. But the next time I'm remoted into the client I will try to split the settings file up and see if I can tell which setting causes the drain! If I run the settings file from 7.6, it causes a huge performance drop there too, so it's not just a DOS thing. Karen Karen, A long time ago, I cobbled up this code to check and fix the settings after connecting to a DB. It was done for exatly the reason you are describing. Our users were getting tired of waiting for the database to connect, especially as they open several sessions on each computer. It does NOTHING TIME CONSUMING if all settings are correct. If it does need to fix a setting it changes the user to the OWNER so the fixed setting will STICK. It should be easy to cobble up one that matches your preferences. All my modules to connect to databases call this module. I would think this would be something that should be stored in an archive somewhere so others can learn from it. This could be put into a codelocked module for security purposes. Dennis McGrath
