Home Evaluation Summary for programmers Product limitations Goals of Axisbase Quick start Installation Using the launchpad and opening databases Connecting to a sample database Using building blocks Planning Define the purpose Define the requirements Borrow existing work Determine the architecture Design the data model Design the process model Deploy and maintain the product
building blocksPerforming a mailmerge Bulk e-mailing
ProgrammingSingle-threaded progress indicator in c#
Database menu itemsImport XML Save Copy As Integrity Check Change Password
Database Properties windowOpening the database properties window Record types tab Display types tab Roles and Users tabs Sidebar tab Database ID/Links tab Counters tab
Building blocksBuilding blocks window Editing grids and cells Hyperlinks and nesting Data Subset window Data Outsource window List window Window window Report window Bulk Operation window Label Printer window Choosing a data source
Special topicsExpression syntax Browse records Storing building blocks within other building blocks Programming Using custom code in building blocks Using Axisbase as an embedded database Axis1.Util namespace reference Axis1.Data namespace reference (Fishnets) Axis1.Data namespace reference (other) Axis1.Forms namespace reference
Design the process model
A process model is a plan for the flow of the user interface - how the user gets from screen to screen, what shows on each one, and what other things happen. While the data model describes what is persistent, the process model describes change.
For small projects, you may want to skip the formal documentation of the process model, but you should still read this section to organize your thoughts about what is possible and convenient in Axisbase. This section explains the building blocks in Axisbase.
Kinds of processes
Data loading fundamentals
Axisbase loads and saves data in whole chunks, not one record at a time. For example, if you request to load all sales in the last week, the database server will load them all into server memory, transfer them all to the workstation, and then they will be displayed. The user can make any number of changes, which are held in the memory of the workstation. When the user chooses to commit the changes, the changed records are sent back to the server for saving. This method is generally replacing the older method of data access in which records are fed to the workstation only as requested and each change is saved when the change is made.
The advantage of the new method is that it works well across the internet, because there are no delays in the user interface during editing. To maintain good performance with Axisbase, you can keep the datasets as small as possible by filtering any data, and never requesting all of a record type that has a large number of records. For example, always request sales in a user-entered date range rather than all sales from all time.
The portion of the database that is loaded into workstation memory is called a data set. A data set can contain records of one main record type, and optionally records of related types. For example, a data set could be all the sales made in the last week, and all the line items of those sales. The collection of records of one record type is called a table; the columns of the table correspond to properties of the record type, and the rows correspond to the records. In Axisbase, the table/row/column terminology is only used for data sets that are loaded into workstation memory; however, in many other systems, that terminology is used more generally and includes records stored in the permanant database.
Axisbase building blocks
In Axisbase, you organize your user interface with building blocks. The kinds of blocks are as follows.
The arrows in the graphic above are important. The arrows connecting data sources to layouts signify that layouts draw their data from data sources. The layouts are then placed inside the final presentation blocks (reports and windows). Important points to remember about this are:
Re-use of building blocks
A design goal for the process model is to re-use as many building blocks as possible for as many purposes as possible. Generalize.
For example, suppose you have created a data subset that includes packages needing to be shipped, and a list which formats that data set in a certain way, and a report that contains the list. This sequence of data subset -> list -> report is useful to the shipping department to get a printed list of packages to ship. Now suppose a different department needs a report of packages that were shipped to a certain customer, and that report can be in the same format but with different data. In this case, you only need to create a new data subset and feed it into the same list. You can create a new report that includes the list with the new subset attached.
A second example would be when you need to alter the format but not the data set. In this case, build a new list, but make the new list use the same data subset.
A useful set of building blocks gives the end-user a choice of how to load data (which data subset to use), and how to format it (which list to use). You can use hyperlinks placed on windows to specify the possible connections, or you can create a series of windows (or reports) containing lists, whose purpose is just to connect the contained list to different data subsets.
Parameters are data values entered by the user, which are not stored in any record. For example, if you load sales by a date range, the beginning and ending dates would be two parameters. The parameters are named, such as "fromdate" and "todate". Parameter entry fields can be placed on windows; parameter values can be included in lists and reports; and paramteter values can be used by data subsets to control data loading.
Through the extensive use of parameters, you can avoid any programming while still giving the end user a lot of flexibility in searching for and displaying data.
Capabilities of data subsets
You can do a lot with data subsets. This information is meant to let you know what can be done, for the purpose of the design phase. (The instructions to create data subsets is in a different section of the documentation.)
Data subsets are procedural; by creating one, you are telling Axisbase, "first do this, then do this, ..." and so on. You usually start with all records of one type, and then apply various steps to that, the end result of which is an in-memory data set containing one or more tables, with a row for each record and a column for each property of the record type.
A simple example is:
1. Start with all customers
2. Filter by state=NY
3. Sort by customer name
4. Only include the columns name and city
Axisbase performs some optimizations, so it does not always do the steps in the order listed. In this case, it would only load customers in NY into memory (so it basically skips step 1). Also, it only loads the name and city in the first place, instead of loading all columns and then throwing them out.
If a data subset has more than one table in it, each table has its own list of steps.
Here is a list of all the steps that can be used:
There are four possible sources of rows for a table:
At this point, if you haven't actually worked with data subsets, it will be hard to remember the above information. The main point to take from this is that you can do almost anything you can think of.
The bulk operation building block can be used to do a variety of things to and with whole data sets.
The basic idea of a bulk operation is to load a data set into memory from any data source (a data subset or data outsource), then perform a sequence of operations on it.
The kinds of operations that can be performed are:
If you know SQL, you will recognize that bulk operations are similar to SQL UPDATE, INSERT, and DELETE statements. Bulk operations can be a lot easier to work with, and are more flexible when the logic gets complex. You don't have to modify or delete the records that were loaded; for example, you could load in the line items of sales made in the last month, and then mark the products referenced by those line items as active.