I have several clients running one of my DE apps on small networks, usually no more than five users. From time to time I have had users reporting resource conflict messages, even though the number of current users does not exceed the licensed user count. Usually, getting everyone out of the system, shutting down and starting again has solved the problem.
My colleague, Tom Blower, and I were recently investigating this irritating problem, and what we found may be of interest to readers of this forum.
Running a status report of forms on one database, we found that the configuration file appeared to have a number of records far in excess of the number of users. We checked other networks which had had problems and found a similar situation.
Now, whenever we find this situation, we create an installation(DIN)file with its associated files (using Neville Richards' brilliant DISTRIB) for the whole database (apart from the Configuration file), delete the database from its directory, create a new database in that directory, and then reinstall the application from the DIN file. This appears to solve the problem.
Typically, a network with up to five workstations seems to start running into trouble when the number of configuration records gets to 10 to 15. The configuration file appears to grow if people do not exit DE properly, for example, by losing a network connection, by rebooting from a freeze, by having a power cut, etc. There appears to be no way of resolving this problem, short of reinstalling the database as described above.
I thought I would post this item, in case anyone else has been having a resource conflict problem and has not thought to look at the configuration file. I would be interested to hear of anyone else's experience in this regard. If it can be proved that this is a reproduceable problem, which my own experience shows it to be, I will ask Sapphire if we can have a reproduceable solution!
Sorry for the long note, but hope it is useful.
This was posted a week or so ago on the CUI lists...
> I looked at your application...
> Some thoughts...
> 1. You can write a DQL that displays the contents of the System and User Configuration records. You cannot do a "for" statement on a system table...
but you can do a
List records in system configuration
> FieldA ;
> FieldB ;
Pick_whichever_fields_you_like Display to screen works good...
*When you do this on the application at your site... you might be shocked.
2. The Configuration file is NOT an INDEXED table.
3. The Computer_Name (DENAME) is the only field in the Configuration file that is UNIQUE.
4. If you Change (Modify) a record in the Configuration table...that change isn't reflected until you completely EXIT DataEase and re-start the application.
5. You CANNOT delete a User record in the Configuration table.
6. When a User is added to the Configuration table, that User gets all of the data associated with the DataBase Configuration Record.
Generally Accepted Opinion:
When you make a System Configuration change, it generally means something significant has changed and probably should be reflected in the User Configuration records also. This is
particularly important for all options on screens 2-5 of the System Configuration record.
Sometimes, DataEase can get confused about records that are in the User/System Configuration table... remember, it's NOT
indexed, and DataEase reads the records sequentially until it finds what it thinks is a "match"... which may or may NOT be correct...
If you run the DQL in #1, the data for each record should be the same... if NOT, you should question "Why Not?"...
There is an easy way to ensure that your Configuration table is up to snuff... and you are getting the correct locking options
and the correct network type.
Write a DQL that deletes all the records in the System Configuration table.
A simple: "Delete Records in System Configuration" will do the job nicely.
Immediately EXIT the database, and Ensuring that you have the correct Network type installed for your application, re-start the
Go directly to the System Configuration screen and make any necessary System changes...remember, this will be your "System" defaults.
Re-run the DQL from #1 above again.
You should have 2 records. One with your DENAME, and one with NO Computer_Name...this is the system default record. Both records
should be identical.
As each of your users sign back on to the database, they will each get a clean, new, default record.
When I create a new database... I rarely ever start from scratch...I start with a dozen critical (IMO) forms, and a few
dozen critical,(IMO) DQLs... The DQL in #1 above is among them...
"Use the right tools for the right job...if your hammer doesn't work, get a bigger hammer!"
Kingston & Company
Thank you for your very comprehensive reply to my message. I am not able to follow up your advice at present, as I am working away for a week, but I will take it up when I return home.
Thank you for very much for coming up with a solution. I had a feeling _you_ would know the answer!
|Thread Tools||Search this Thread|