A different take on database settings

Many users are happy when the system is installed and work true to the motto: “Never change a running system”. Settings that refer to systems or resources that are no longer used are often forgotten. On the other hand, there are also settings that need to be adjusted over time so that the system runs as smoothly as on the first day.

That’s why we at Goecom have thought about how we can keep track of such database specific information in conzept 16 that tends to be forgotten. Important parameters here include the size of the database cache and the size of the database. The database cache should be as large as possible: Ideally large enough so that the entire database can be loaded into the cache. The database grows over time. However, the corresponding cache size is not adjusted. This can lead to performance bottlenecks. Another important source of error can be the unobserved growth of the database. If the hard drive is full, no more data can be written.

This can lead to data loss if no action is taken in time. If only one database is set up on the server, the cache size, the database size and the available storage space on the data carrier can be determined using the commands

DbaInfo(_DbaCacheMb)          // Cache size DbaInfo(_DbaAreaSize)         // Database size DbaInfo(_DbaAreaVolumeFreeMB) // Free space on data carriers

However, if several databases are set up, a corresponding routine must be implemented for checking in all databases. Many settings relating to the database server are stored in conzept 16 in a file – the data room table. In addition to the database path and the size of the database cache, the settings for sending alerts are also configured.

It is essential for us to check certain basic settings when starting the program, including not only that there is sufficient capacity for the databases, but also that the mail notification for problem situations is set up. The conzept 16 server or the server system used is generally not maintained or checked by the customers themselves. This is often the responsibility of external service partners. The range of services offered by some service partners varies greatly and is not always optimally utilized for cost reasons. It is therefore possible that certain problem situations are simply not monitored. It is therefore very easy to avoid reporting damage to the database if the people concerned are informed in advance.
It is also very important to check all settings, which we know from the web interface of the conzept 16 server, at regular intervals. “Are the backup times still correct?” The question “Why is my database in read mode?” is also very interesting; if the software being used has an accounting system, this setting may not be desirable. All these settings can be controlled or checked via the data room table without having to go to the web interface.

The data room table can be analyzed as follows. Execute a function with an RmtCall() (this is then executed directly on the server). This allows you to locate the data room table (c16_serv.ars) and store it as an internal binary object. The client can then access this object and start the corresponding analysis or send corresponding messages to the user.

// damit ermitteln wir den Speicherort der c16_serv.ars Datei
// If this cannot be determined (e.g. under Linux),
// then this file is located in the server files -> i.e. root
aPath # _Sys->spPathPfmData;
// The structure of the file can be found in the C16 help
// (Beispiel - c16_serv.ars)
/* Dateininhalt Start */
[AreaTable]
  <ProtocolCRC=0>
  <DebugOptions=0>
  <HsbNoDongle=0>
  <LicenseFileAutoUpdate=1>
  <LogUserLimitExcess=0>
  <UserResvCount=0>
  <WebSvcPort=4745>
  <WebSvcLang='DE'>
  <ProxyType=1>
  <ProxyPort=800>
  <ProxyAddress='192.168.1.1'>
[Area]
  <Name='Marvin'>
  <CA1='C:\Temp\Datenbanken'>
  <CacheMB=8192>
  <CacheSave=1>
  <CachePreload=1>
  <BackupVSS=0>
  <TempMB=1024>
  <TransactionLog=1>
  <ReadOnly=0>
  <Protected=0>
  <ProcedureLimit=256>
/* Dateininhalt Ende */

Dies hilft uns ungemein weiter, denn wir können Probleme vermeiden, bevor diese überhaupt entstehen. Dadurch stärken wir das Vertrauen unserer Kunden in uns und unsere Software.