Database properties
Contents
On the Database properties tab, which is present when you have selected a new or existing database, you determine the general properties of this database.
Click here for information on how to edit properties in general. And click here to read about how to manage objects in the tree view in the Application browser. On the current tab you'll find the following settings:
When you create a new database, you provide the name for it that is displayed here. Axiell Designer will create all relevant (empty) SQL tables automatically and the Data storage options in the new .inf will be set identical to those in the other database definitions.
This database name must comply with the rules specified by your computer’s operating system for file names, and must be entered without an extension, preferably using only lower case letters (although database names are processed case-insensitively). In Windows environments you could, in principle, use long file names of up to 255 characters, but nevertheless it's better to limit a new database name to 8 letters without spaces. And do not use a minus character in the name, because this may result in errors.
De database structure that you define here is saved in an .inf file with the database name, in the \data folder of the currently opened work folder in Axiell Designer. The full path is displayed here.
This property displays the type of character set used to encode texts you provide for properties of this object. It does not say anything about the character set used to encode data in.
You can change the encoding of database structures (.inf files), application structures (.pbk files) and screens (.fmt files) simultaneously, with the Application character set conversion tool in Axiell Designer.
Collections can restrict access to data in various ways. One of them is through authorisation per record per user or role. If you set this property to anything but None, then a running Collections application will only allow a user access to a record in this database table if the user has the appropriate authorisation. Collections will use login data to establish which user is requesting data. In the Authorisation user field (see the option below) you can specify per record to which users or roles special access rights apply.
Of the three options (Exclude, Include and Specified rights), only Specified rights has been implemented for Axiell Collections, so you can't use the other two. Specified rights makes it possible to specify individual and detailed access rights per user or role per record.
Here you enter the name or the tag of the field in which the user names and/or roles that you want to use for authorisation will be filled in, and saved, per record in this database. Depending on the Authorization type specified in the option above, these names will be used to determine if and how users have access to the record.
For the Authorisation rights field, fill in the name or the tag of the field to be used. In this field, per user or role the specific access rights will be stored, that are assigned by the creator of a record. This should be an enumerative field with neutral values 0, 1, 2 and 3 and at least English Language values None, Read, Write and Full respectively (so 0 is None etc.).
This option can only be filled in if the Authorisation type has been set to Specified rights.
The Default access rights concern the access rights for all users to a record in which those users or their roles have not been explicitly assigned access rights; this option only applies if the Authorisation type has been set to Specified rights. If you are more likely to list users in a record, that have extensive access rights like writing or also being allowed to delete, then for this option you'll probably want to set limited default access rights, like read-only or no access at all. The reverse situation will probably occur less often. But it is of course important to choose these default rights carefully, because you won't be listing the majority of users in each new record.
For the Record owner field, also fill in a field name or tag of the field to use. Later, in this field the user name or role of the creator of a record will be stored automatically. This name or role is determined through the login of the current user. A Record owner field is mandatory for the Authorisation type: Specified rights.
For the Authorisation type: Specified rights you can choose here if the name of the Current user or the Current role (the role of the current user) will be stored by Collections as the record owner. The advantage of Current role over Current user is that if records are property of a role, you can always assign that role to other users so that they also get the right to adjust the access rights of others to the relevant records: this prevents a potential problem of the Current user option, when a particular record owner is no longer in a situation to do his or her work and has not been able to assign a different record owner.
If currently record owners are still user names, and you change the Record owner type to Current role, then the new setting only applies to new records; the owners of existing records will remain user names. Only those users could use search-and-replace in existing records to replace their name by their role, if desired, so that all records get a role as their owner.
If the access rights of the record owner are based on an Active Directory membership, then for Axiell Collections the Record owner type must always be set to Current role.
If a user has different roles, then the first of these roles as defined in the .pbk will become the record owner role when that user creates a record.
This option does not apply to Axiell Collections.
Minimum record size (in bytes)
This option does not apply to Axiell Collections.
With this option you determine the character set in which your database is stored, and also the sort and search order of your language region, because although different languages can use the same (or mostly the same) alphabet, the sorting thereof can be quite different. And when you want to sort records ascending or descending, it is important that it happens the way you would expect in your language region.
For Axiell Collections you'll have to use a Unicode language setting. Unicode allows you to enter foreign characters or to have records sorted according to your language characteristics. So choose here the language in which you plan to work, and make this setting for each database definition (.inf). If your databases are still empty, this is all you have to do. If your databases are already filled with Unicode data, but set up for a different language, and you change the language, then you'll have to reindex all indexes. Note that you only set your language region once. After that, it's still possible to enter characters from other languages in records, but Collections will continue sorting according to your own language characteristics.
Note that the DOS and ANSI settings at the top of the languages list are not applicable to Axiell Collections.
If you find you're having issues with multilingual data, possibly with an error referring to a not supported "culture", after you're application has moved to a new server or when your application runs under a different Windows version than Axiell Designer, please check out the possible solution here.
The value of this option must be the same for all databases in a single Collections application, otherwise an error will occur.
For Axiell Collections, the Left truncation option is irrelevant: left, right and middle truncation are supported by default, and can even be used together, for instance to search left and right truncated at the same time. The indexes do not need to be set up in any special way.
NB The user cannot perform left truncated searches on numeric or date indexes.
This option (for Axiell Collections 1.14 and up) replaces (after reindexing all databases) all free text index tables, all non-unique text (term) index tables and the wordlist table by a single so-called Full Text index table per .inf file. The advantage of this being that the SQL queries which are executed under the hood of Collections or the WebAPI or any other search-capable Axiell tools, will become much simpler and efficient and may therefore greatly increase search performance in the relevant indexes. For Full Text indexed databases it also allows Contains phrase and Does not contain phrase access point searching on both Text (term) and Free text indexed fields. Please see the Optional full text indexing for real phrase searching topic for a complete description of the implementation.
If you also have the Axiell Internet Server and/or WebAPI, changes will have to be made to the configuration of this software too because equals and contains searches behave differently* with the new index type. Please consult the Axiell helpdesk for more information about these consequences before you switch Full Text indexing on.
* In Full Text indexed databases, searching with the equals (=) operator shows different behaviour than in normal (non-Full Text indexed) databases. However, really the only difference is that searching Free text indexes (for long text fields) in a normal database using the equals operator, actually behaves as a contains all search, so there you only need to provide one or two words from the long text field, in random order, to find the record with the long value containing those words. With Full Text indexing though, the equals search behaves more as you would expect, namely to search for an exact match on the search key. So with Full Text indexing you must either provide the entire long value you are searching on or provide just one or two words from the long value, but put them in the right order and allow for words in front, in between or after the searched words, by entering an asterisk before, in between and after those words (and enclose it all by double quotes): it doesn't matter if there's a space or not between the asterisk and the word before or after it, unless you've entered a partial word, in which case the asterisk must be concatenated with the partial word. Of course, with this more limited implementation of the equals search, it might be easier to start using the desired "contains" search in Full Text indexed databases from now on as then you don't need to use truncation characters if your search key isn't the full value.
Also note that in Collections 1.15.1, implicit right truncation (for the full field contents) was enabled for equals searches but this has been turned off again, so if you'd like to truncate an equals search you'll always have to do it explicitly from now on.
This option does not apply to Axiell Collections.
This option indicates the storage type of the current database. For Axiell Collections you always use SqlServerStorage. The other options are not applicable.
If the current database is part of a SQL Server database (which is always true for Axiell Collections), the data source name has to be filled in here.
After all connection details have been filled in, click the Test button on the right to check if the connection with the database can be realized and if the relevant table exists at all.
Enter the name of the SQL database server, e.g. SERVER3\SQLSERVER19.
If you are using SQL Server Authentication instead of Windows authentication for the SQL Server, all Collections users together have one user name and password. You can enter that user name and password here.
If you do not use Windows verification, but do not want that the common user name and password are visible in Designer, or if you do not want to use a common user name and password, then for User id you may also literally enter the following string: <mustAuthenticate>, and leave Password empty, to use the pbk authentication, database authentication or Active Directory authentication that you activated for the application that uses this database. (Click here for more information about these authentication types.)