1. The database engine

Since Version 2003, the abas Business Software is equipped with a log database as a standard. This technology differs fundamentally from the conventional database concepts. No longer will existing data objects be modified, but new data objects will be created, the existing database object will be labeled no longer valid and is later removed from the database with the "garbage collector". Compared to previous strategies this process has the following advantages:

• Online data backup
  Data backup can be carried out without any interruption to the ongoing operation.
• Increased write performance
  As the database files are only written in a sequential manner, a gain in performance compared to conventional database systems is achieved. The performance is even higher, the higher the performance of the processor of the used computer.
• Shadow database (from V2003R1)
  A "shadow database", i.e. a simultaneous copy of the real client, can be maintained on a different hard disk, even on a different computer. As the copying process has only to move the same amount of data as the proper write process on the real client, the strain on the network is drastically reduced, so that the shadow database can, for example, also be utilized on the other side of the firewall for Web applications. The Web applications are therefore not operating on the real client, but always on a current copy. It is moreover planned to pass on the data selectively, e.g. without financial accounting.
  By running a shadow database it is possible to continue to operate on the copy, without any loss of data since the last data backup (high availability).
• Parallel processing of read processes
  Because only new data objects are created it can not happen, that a part of a data object has been altered, another part not. The database process for read and write access no longer has to run in sync, but can be split into many read processes and one write process. Modern multiple processor installations are therefore able to process read and write processes on different processors in parallel, whereby we do expect an improvement in performance, especially with a larger number of users.
• Copying a database in an instant (from V2003Rx)
  A logical copy of the database, e.g. to test particular procedures or for a simulation can be created in an instant, independent of the size of the data set.
• Transactions are allowed to be virtually any size
  Using the conventional procedure the size of the transaction is limited by the main memory.
• Versioning (planned)
  This concept allows the versioning, i.e. the archiving of previous states of a data object. For example, the change history of an order can be traced and an UNDO function with reset to the n-th stand is offered.
• Online upgrades (planned)
  The log database supports the ability of upgrades during ongoing operations. A change of the data model does therefore not require any reorganization runs during which no work can be carried out, but can be implemented during ongoing operations. Extensive evening, night and weekend operations caused by upgrades do no longer have to be carried out.

2. The database features
Further features of the abas ERP database:

• Object definition of the database
  • abas ERP knows very complex data objects: for example, a product, including its production list, is a single data object in a database table (and not, as is the case in a relational database, recorded in at least 2 tables). If a production list is changed, a complex transaction is not required, because the lock of the single involved data object is sufficient.
  • The database knows polymorphic references. A single reference can therefore refer to different data objects. The operation can be significantly simplified. Example: In financial accounting there are references to accounts. In these references the following data objects can have been entered:
    • Customers
    • Vendors
    • Employees
    • G/L accounts

    But the user sees only one field, into which he can enter the various data objects.

• Database administration
  With the administration tools of the database the following options are available (even if data have already been integrated):
  • Existing database fields formats can be changed (e.g. instead of 30 characters text 60 characters are required or the number of whole number places is not sufficient), without the field content being lost
  • Extend database tables by new fields
  • Use new database tables for your own purposes
  • Insert references to one's own new database tables from standard tables and vice versa
  • Adapt screens or create new screens
  • Export data directly to OpenOffice (e.g. Open Calc) or to Microsoft products (e.g. Excel). For this, programming knowledge is not necessary, even if database tables have to be linked using joins.
  • Add individual keys. The key may consist of several fields wchich are not joined. The keys can then be used again in one's own selections.
• A number of interfaces are available, using which the database can be accessed, either in read or write mode. Here, the ODBC interface, the Java API, the EDP interface (ERP data access log, abas interface similar to ODBC, but faster), as well as the ActiveX interface have to be mentioned.
• During write operations the methods which are made available by abas ERP in the standard, as well as the methods which have been added by the user, are run. This is essential in order to maintain a consistent data set. The chosen technology of write interfaces automatically ensures this.
• FO language
  • The FOP (Flexible User Interface) enables the user or the supporting software company to add individual, project-specific adaptions. Adjustments are carried out by means of "FOPs" (Flexible User Interface Programs). An uncomplicated script language is available which can be easily learned even by persons who are not computer scientists.
  • For complex adaptions Java can also be used as the programming language. Script language FOPs can be called from Java programs as well.
  • In the script language, as well as in Java the user can define transactions which are linked to the standard transactions of abas ERP. An example: The saving of one's own data objects together with the saving of an order can run in the same transaction. This safeguards, that either order and one's own data objects or none of the two are saved.
  • These FOPs, as well as the Java FOPs can be coupled to events. They are then called EFOPs (Event Controlled Flexible User Interface Programs). Events are:
    • Enter screen (the call of a screen, e.g. for the setting of default values)
    • Screen validation (status: abas ERP has not yet completely checked and completed, the object is not yet on the hard drive and the transaction is still open)
    • Screen exit (status: abas ERP has checked and is content, the object is on the hard drive and the transaction is still open)
    • Cancel screen (status: user has canceled action, transaction still open)
    • The filling of a field (status: entry in the field has not been checked yet by abas ERP; used for example for the entry of "MAX" into a numerical field and then an EFOP shall determine the maximum value permitted and enter it)
    • Field verification. (status: content checked by abas ERP, an EFOP can carry out a more rigorous check and reject the content, as the case may be, e.g. customer has exceeded his limit and is not allowed to issue another order)
    • Leaving a field (used for follow-up actions like entry into another field of the screen due to the entry just made, e.g. an individual price finding)
    • Before and after the pressing of a button
    • Before and after inserting, deleting or moving a line

3. Further administration tools
Further administration tools enable the

• Menu design
• Creation of new, user-specific and user group-specific menus
• Integration of charts into screens
• Displaying data in user defined screens and equiping data with drill-down functions (Infosystem)

And the decisive point: With all the adaptions made in the database using FOPs and EFOPs, the user still remains upgradeable. In spite of the extensive adaptions we are still able to make the most up-to-date version of abas ERP available to the user, leaving the individual, project-specific applications unharmed!