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
