The other day, I did a presentation of NexusDB for my friends in the Göteborg Delphi Meetup Group. After an initial discussion about the history of the database and some comments on the pricing, all of which you can find on the home page, I presented the first version of an application that was to follow us for a few hours.
The application I wrote was a very simple address application – it had a main form that listed individuals and when selecting an individual, the addresses assigned to the person were displayed below the list. Adding and editing an individual (with addresses) was done in a separate form. The main form had access to a data module containing the data sets to wich its grid was connected (DataSetDM). This data module also had methods for adding, editing and deleting personnel data. In addition to this, another data module, DbAccessDM, provided the actual connection to the database. The following picture shows how the first version of the application was set up.
This version was a stand-alone version, which meant that the application operated directly on the data, instead of accessing it via a separate server process. This gives us an application which is very easy to install, but it is also limited – only one application can access the data at a given time.
The second version addresses this problem – it uses another “database access” data module, which doesn’t implement its own database server, but instead accesses an external database server (e.g. the one which is available for download from the NexusDB web site). The structure of the client application is seen in the following picture:
If you look at the code, you see that from now on, the applications may be run with command-line parameter “/local” in which case the original data module (embedded server) is used. If the parameter is missing, the client data module is used.
The data for the two previous applications had to be set up manually using the NexusDB Enterprise Manager, which is also available from the NexusDB web site. The third version makes sure that data is created automatically when the application starts. This is done using SQL commands, executed using a TnxQuery component in the new CreateDM data module.
This application will always recreate its data when started. This is very useful in a test project, but in a real application, you will not drop an existing table, but you will create it only if it doesn’t already exist.
The fourth version describes a concept called triggers. A trigger is a piece of code which is executed automatically on the server, as a result of something that happens in the database. The trigger created for this project causes information to be written to the Log table when person data is added, edited or deleted. The trigger is added to the database when it is created – look at the SQL code in CreateDataDM’s query component.
This version of the application doesn’t let us see the result of the added log information (you may use the Enterprise Manager for that), so the final version displays the latest log entry in the application’s main form whenever something happens. It retrieves the log information from the log file by calling a stored procedure, i.e. a piece of SQL code added to the database and executed in the server. DataSetDM has now gotten a new component for executing stored procedures.
The code for this can be downloaded here.