company logo

_OptDataSource - Data source definition

Data source definitions depend slightly on the mode used for running a database. One may run a database in a local network environment (LAN) defining a local data source. One may also run the database in client/server mode (usually in the local network), in which case one has to define a client/server data source. One may also run the database from a Web server using the replication client feature, in which case a replication data source has to be defined.

In contrast to other options, which might be defined as options in the database, data sources or a data catalog must be defined in the configuration or ini-file, since the data source is required to read the options from the database.

Data sources definitions is the external way of defining a database source by means of options. A data source can be defined as set of options e.g. as section in an ini-file or as xml element in a configuration file. Data sources may also be defined as part of database options, but not for the primary database, which has to be opened in order to read internally stored database options.

Enumarators overview

Enumerator details

  1. DICTIONARY - DICTIONARY options

    The dictionary path refers to the location of the application dictionary database. When referring to a dictionary or resource database as database, the system dictionary (ode.sys) has to be referred to as dictionary.

    Paths can be defined as absolute or relative paths, or as reference path containing symbolic references (%sym_name%).

    Usually, this value is set in the configuration or ini-file in the DICTIONARY option for the data source definition. In case of complex dictionary definition, one may, however, also define the database path in the PATH sub-option DICTIONARY.PATH.

    ; simple definition

    DICTIONARY=C:/ODABA/Sample/Sample.dev

    ; complex definition

    DICTIONARY=C:/ODABA/Sample/Sample.dev[

    TYPE=ODABA

    CONNECTION=Local]

    Code: 1
    to list
  2. DATABASE - DATABASE options

    The database path refers to the location of the root base for the database. Paths can be defined as absolute or relative paths, or as reference path containing symbolic references (%sym_name%).

    Usually, this value is set in the configuration or ini-file in the DATABASE option for the data source definition. In case of complex database definitions with sub-options, one may, however, also define the database path in the PATH sub-option DATABASE.PATH.

    ; simple definition

    DATABASE=C:/ODABA/Sample/Sample.dat

    ; compley definition

    DATABASE=C:/ODABA/Sample/Sample.dat[

    TYPE=ODABA

    CONNECTION=Local]

    Code: 2
    to list
  3. RESOURCES - RESOURCES options

    Usually, resources are defined in the dictionary. in special cases, however, resources cannot be provided in the dictionary and a separate resource database is required. When a resource database has been defined, application resources are searched in the resource database, but not in the dictionary.

    E.g. when running an application that works on the development database with the dictionary ode.sys, the resources, that one might want to test are not defined in this dictionary, but in the resource database ode.dev. Defining the database ode.dev as resource database in addition to the dictionary will solve this problem.

    The dictionary for the resource database is always the system dictionary defined in the SYSTEM section of the configuration file.

    Usually, this value is set in the configuration or ini-file in the RESOURCES option for the data source definition. In case of complex resource database definition, one may, however, also define the database path in the PATH sub-option RESOURCES.PATH.

    ; simple definition

    RESOURCES=C:/ODABA2/ode.dev

    ; complex definition

    RESOURCES=C:/ODABA/Sample/Sample.dat[

    TYPE=ODABA

    CONNECTION=Local]

    Code: 3
    to list
  4. SHARE - SHARE option

    This option is required when running the database in a file server mode for sharing the database between users (multi-user access).

    false/NO - database is used exclusively

    true/YES - database can be shared between different applications

    SHARE=YES

    Code: 4
    to list
  5. ONLINE_VERSION - ONLINE_VERSION option

    This value enables online versioning feature for the data source when being set to true. Online versioning allows automatic upgrades to higher database schema versions.

    false - online versioning disabled

    true - online versioning enabled

    When this variable is not set or set to false, the application will not run with updated database schema versions.

    Usually, this value is set in the configuration or ini-file in the ONLINE_VERSION option for the data source definition.

    ONLINE_VERSION=YES

    Code: 5
    to list
  6. VERSION - VERSION option

    Databases can be stored with different versions. Versions are numbered consecutively in order to identify the version the database is referring to. Defining a version number allows running the database for an old version instead of the current one.

    In order to open the database for a version which is not the current database version, the value must be set before opening the data source.

    Usually, this value is set in the configuration or ini-file in the VERSION option for the data source definition.

    Default: current version

    VERSION=1

    Code: 6
    to list
  7. ACCESS_MODE - ACCESS_MODE option

    The access mode defines whether the database will be used in write/update mode or read only:

    Read    - read only access

    Write    - write/update access

    New databases will be created automatically, when being opened in Write mode.

    Default: Read

    ACCESS_MODE=Write

    Code: 7
    to list
  8. PLATFORM_INDEPENDENT - PLATFORM_INDEPENDENT option

    Usually, databases differ in the internal format that is stored on the disk, depending on the platform, where the database has been allocated. The consequence is, that a database cannot be copied as file e.g. from a SUN station to an INTEL platform. To create a platform independent database that can run on any machine, one has to set this option to YES:

    • Platform independent databases can be copied by simple file copy from one machine to another, independent on the hardware used on the machines. When this option is not set to YES, databases must be converted using the DBCopy utility when hardware platform for the database changes.
    • Default: NO

    PLATFORM_INDEPENDENT=YES

    Code: 8
    to list
  9. TYPE - Dictionary storage type

    Dictionary databases may be stored in different data storage formats supported by ODABA. ODABA storage format is the default because it is the most efficient format for storing complex data structures.

    ODABA automatically distinguishes between ODABA and XML databases. When, however, running e.g. an ORACLE database, the type must be defined explicitly. The database type option can be defined in a configuration file as sub-option for the database option.

    The following values are supported:

    ODABA- ODABA database format

    XMLDatabase- XML file

    ORACLE - ORACLE database

    SQLSERVER- Microsoft SQL database

    MySQL- MySQL database

    Relational database formats (ORACLE, MS_SQL) require an ODABA object relationship mapper (ORM), which allows managing relationships and transactions efficiently. The ORM is a small ODABA database, which contains derived information from the original data. Since the ORM database does not add information to the underlying data, it can be reconstructed from the relational database at any time.

    DICTIONARY.TYPE=MySQL

    Code: 9
    to list
  10. SERVER_URL - SERVER_URL option

    The server name refers to the name or the TCP/IP address of the server machine, where the server is running.

    Usually, this value is set in the configuration or ini-file in the SERVER_URL option for the data source definition, but it might also be defined as global option variable.

    When a SERVER_URL option variable is defined, dictionary and client are accessed via server (object or replication mode). In order to use a local dictionary or database, instead, DICTIONARY.CONNECTION=local or DATABASE.CONNECTION=local has to be defined.

    SERVER_URL=server_name

    Code: 10
    to list
  11. SERVER_PORT - SERVER_PORT option

    This variable is only necessary when running in a client server environment (object or replication server). In this case, the port number must be identical with the port number passed to the server when starting it.

    This variable is only required in connection with the SERVER_URL option variable. When defining a SERVER_URL option variable but no SERVER_PORT, 6123 is used as default.

    Usually, this value is set in the configuration or ini-file in the SERVER_PORT option for the data source definition, but it might also be defined as global option variable.

    Default: 6123

    SERVER_PORT=1234

    Code: 11
    to list
  12. REPLICATION_SERVER - REPLICATION_SERVER option

    For running a replication client, this option refers has to be set to true (YES). In this case, SERVER_URL and SERVER_PORT) have to be defined in the data source or as global option variable. These option variables refers to the replication server name or its TCP/IP address.

    Running a replication database required, that the replication feature is enabled for the replication master database(s).

    Default: NO

    REPLICATION_SERVER=YES

    Code: 12
    to list
  13. OBJECT_SPACE - OBJECT_SPACE option

    In many cases, a database consists only of the root object space and no object space must be defined.

    In some cases the database is, however, build of a number of hierarchical object spaces where each object space may contain a whole universe of object instances. Object spaces are referenced in the defined hierarchy. In order to access a subordinated object space, a path to the object space must be defined in the data source.

    The root object space did not get a name, i.e. object space names begin with the first subordinated object space.

    Usually, this value is set in the configuration or ini-file in the OBJECT_SPACE option for the data source definition.

    OBJECT_SPACE=myClient.subClient

    Code: 13
    to list
  14. DATA_TYPE - DATA_TYPE option

    The DATA_TYPE option can be defined instead of the ACCESS_PATH option in order to process instances of the data type defined in the data source. The option is not used internally by ODABA, but might be used in an application. Some special service utilities (e.g. CopyResDB) refer to this option in order to perform schema operations.

    Usually, this value is set in the configuration or ini-file in the DATA_TYPE option for the data source definition.

    DATA_TYPE=Person

    Code: 14
    to list
  15. ACCESS_PATH - ACCESS_PATH option

    An access path to a collection may be defined in order to refer to a collection instead to a complete database or object space. The option is mainly used in copy utilities in order to define the data source for a copy operation.

     Code: 15
    to list
  16. ACCESS_KEY - ACCESS_KEY option

    Special object instances can be referred to by setting an access key value in the data source. This information is provided for the application and not directly used by the data source. In order to locate a specific instance when opening the data source, an access key value or position should be set in accessKey.

    Usually, this value is set in the configuration or ini-file in the INSTANCE option for the data source definition.

    INSTANCE=P12345

    Code: 16
    to list
  17. SCHEMA_VERSION - SCHEMA_VERSION option

    This variable allows defining a database version for opening the dictionary (schema version). When opening an older version of a database one may run with the appropriate dictionary version valid for this database. Usually the system tries to detect the proper schema version.

    When being set, this value is set typically in the configuration or ini-file in the SCHEMA_VERSION option for the data source definition.

    Default: Current schema version of the dictionary

    SCHEMA_VERSION=3

    Code: 17
    to list
  18. SYSTEM_VERSION - SYSTEM_VERSION option

    When the ODABA system version has been changed, i.e. when the internal ODABA schema has been expanded, one may run older ODABA versions of a dictionary by defining the old system version number. The version value must be set before opening the data source.

    Usually, only the previous system version can be accessed this way in order to upgrade from the previous version to the next version.

    Usually, this value is set in the configuration or ini-file in the SYSTEM_VERSION option for the data source definition.

    Default: current system version

    SYSTEM_VERSION=21

    Code: 18
    to list
  19. ENABLE_CONTEXT - ENABLE_CONTEXT handler option

    Database context functions (business rules) are executed always, when data is being accessed, i.e. when the data state changes or process events are generated. In order to disable event handling (e.g. for maintenance purposes), business rules can be disabled.

    Since context can be disabled temporarily by the application, this option only indicates the general settings when a database is going to be opened. When being disabled, context cannot be enabled by the application later on.

    true - context functionality is enabled

    false - context functionality is disabled

    Default: true

    ENABLE_CONTEXT=YES

    Code: 19
    to list
  20. WORKSPACE - WORKSPACE option

    The workspace variable defines the basic workspace to be used in the application. The application can open workspaces on top of the base workspace but not below. The defined workspace is either the base for the operation (when passing a workspace name) or the workspace for running the operation (when no workspace name has been passed).

    A workspace can be defined only when the workspace feature is enabled. When not defining a workspace the database is opened directly.

    Default: empty

     Code: 20
    to list
  21. OXS_NAMESPACE - OXS_NAMESPACE option

    An ODABA dictionary defined as xml schema (DICTIONARY.TYPE=XSD) requires several attribute extensions, which are defined in the ODABA schema extension at http://www.odaba.com/OXMLExtensions.xsd. Referring to such extension elements in the dictionary usually requires a name space prefix. This prefix (name space name) is defined in the users xml dictionary and must be passed as sub-option for the xml dictionary.

    Default: oxs

     Code: 22
    to list
  22. OSI_Library - OSI_Library option

    The OSI library path refers to a folder, which contains one or more OSI scripts, which are loaded when opening the dictionary. Besides the directory path the option contains a file selection mask (typically *.osi). This allows providing customized expressions or ODL definitions in order to temporarily overwrite or extend definitions in the resource database. Since the specifications from the OSI library directory are loaded before accessing resources in the dictionary, those get higher priority than dictionary resources.

    Any definition in the dictionary can be overloaded or extended except anything that is persistent. Thus, one may new view definitions or structures, but one cannot update or modify existing structure definitions, which are marked as persistent.

    OSI_Library=~/myProject/osi/*.*

    Code: 24
    to list
  23. CONNECTION_NAME - CONNECTION_NAME option

    The connection name is used for reconnecting the database.

     Code: 25
    to list
  24. PATH - Database path

    The path option contains the location to the ODABA OR mapper database, which is required in order to run ODABA with a relational database in a proper way.

    Code: 27
    to list
  25. PATH - Dictionary file path

    The path option contains the location to the ODABA OR mapper database for the dictionary, which is required in order to run ODABA with a dictionary stored in relational database in a proper way.

    Code: 28
    to list
  26. DATABASE - Database name

    When running ODABA on a relational database, the database name for the relational database server has to be passedin database.

     Code: 29
    to list
  27. DATABASE - Database name for dictionary

    When running ODABA with a dictionary stored in a relational database, the database name for the relational database server has to be passed in this option.

     Code: 30
    to list
  28. USER - User name

    When the database requires a user name, this can be passed in the USER option for the database.

    Code: 31
    to list
  29. USER - User name for dictionary

    When the dictionary requires a user name, this can be passed in the USER option for the dictionary database.

    Code: 32
    to list
  30. IGNORE_COPY_LEVEL - IGNORE_COPY_LEVEL option

    In order to ignore the copy level, which might have been defined in a dictionary for collections (references) or attributes, this option needs to be set to true (YES, true etc.).

    IGNORE_COPY_LEVEL=YES

    Code: 33
    to list
  31. PASSWORD - Password for dictionary

    When the dictionary requires a password, this can be passed in the PASSWORD option for the dictionary database.

    Code: 34
    to list
  32. PASSWORD - Database password

    When the database requires a password, this can be passed in the PASSWORD option for the database.

    Code: 35
    to list
  33. TYPE - Resource database storage type

    The resource database can be stored in different data storage formats supported by ODABA. ODABA storage format is the default because it is the most efficient format for storing complex data structures.

    ODABA automatically distinguishes between ODABA and XML databases. When, however, running e.g. an ORACLE database, the type must be defined explicitly. The database type option can be defined in a configuration file as sub option for the database option.

    The following values are supported:

    ODABA- ODABA database format

    XMLDatabase- XML file

    ORACLE - ORACLE database

    SQLSERVER- Microsoft SQL database

    MySQL- MySQL database

    Relational database formats (ORACLE, MS_SQL) require an ODABA object relationship mapper (ORM), which allows managing relationships and transactions efficiently. The ORM is a small ODABA database, which contains derived information from the original data. Since the ORM database does not add information to the underlying data, it can be reconstructed from the relational database at any time.

     Code: 36
    to list
  34. TYPE - Database storage type

    The database can be stored in different data storage formats supported by ODABA. ODABA storage format is the default because it is the most efficient format for storing complex data structures.

    ODABA automatically distinguishes between ODABA and XML databases. When, however, running e.g. an ORACLE database, the type must be defined explicitly. The database type option can be defined in a configuration file as sub-option for the database option.

    The following values are supported:

    ODABA- ODABA database format

    XMLDatabase- XML file

    ORACLE - ORACLE database

    SQLSERVER- Microsoft SQL database

    MySQL- MySQL database

    Relational database formats (ORACLE, MS_SQL) require an ODABA object relationship mapper (ORM), which allows managing relationships and transactions efficiently. The ORM is a small ODABA database, which contains derived information from the original data. Since the ORM database does not add information to the underlying data, it can be reconstructed from the relational database at any time.

    DATABASE.TYPE=ORACLE

    Code: 37
    to list
  35. DATABASE - Resource database name

    When running ODABA on a relational database, the database name for the relational database server has to be passedin database.

     Code: 38
    to list
  36. PASSWORD - Password for opening resource database

    When the resource database requires a password, this can be passed in the PASSWORD option for the database.

    Code: 39
    to list
  37. PATH - Database path

    The path option contains the location to the ODABA OR mapper database, which is required in order to run ODABA with a relational database in a proper way.

    Code: 40
    to list
  38. USER - User name for opening the resource database

    When the database requires a user name, this can be passed in the USER option for the database.

    Code: 41
    to list
  39. SYSTEM_UPGRADE - Automatic system upgrade

    When system version has been changed, i.e. structure for internal headers has been changed, usually an automatic upgrade to current system version will be done, when opening a database in write mode. In order to suppress system version upgrade, this property may be set to false. The default setting is true.

    After upgrading a database to a newer system version, the database cannot be accessed with older software versions.

    In order to disable automatic system upgrade for all databases opened in an application, the option may be set on global level to false (or NO):

    SYSTEM_UPGRADE=NO

     Code: 42
    to list
  40. LARGE_FILE - Large database file

    When the file size exceeds 2GB, the large file option is set for file systems that support large files automatically. This will cause a different strategy for internal locks, which may cause locking problems when being updated in a running production system. Hence, it is suggested to set the LARGE option to true, when the file system supports large files.

    The option is required for the 32-bit ODABA version, only, and is default for the 64-bit version. When not being set, the locking strategy differs between 32-bit and 64-bit version, i.e. running both versions simultaneously may also cause locking problems. Hence, it is suggested always to set the option when the file system supports large files.

    When the file system does not support large files, the option should be set to false in order to avoid undefined errors when the maximum file size has been exceeded.

    In order to define large databases for all databases in the application, LARGE_FILE may be set to true in the application section.

    LARGE_FILE=NO

    Code: 43
    to list
  41. CONNECTION - CONNECTION type option

    The connection type usually is determined by the system. In order to request explicit server or local database access, the connection type may be set to SERVER or LOCAL.

    By default the connection type is set to AUTOMATIC, i.e. the connection type depends on the client's connection type. When the application or data source is not connected with a server, the database will be opened as local database. When the application or data source is connected with a server, the database is opened as server database.

     Code: 50
    to list
  42. DATA_SOURCE - Data source name in a catalog

    Alternatively to the ini-file definitions that data source can be described in a data catalog. In this case one may refer to the data source name defined in the data catalog, instead defining the data source in a configuration file.

    Code: 52
    to list
  43. CONNECTION - CONNECTION type option

    The connection type usually is determined by the system. In order to request explicit server or local database access, the connection type may be set to SERVER or LOCAL.

     Code: 53
    to list
  44. CONNECTION - CONNECTION type option

    The connection type usually is determined by the system. In order to request explicit server or local dictionary access, the connection type may be set to SERVER or LOCAL.

    By default the connection type is set to AUTOMATIC, i.e. the connection type depends on the client's connection type. When the application or data source is not connected with a server, the dictionary will be opened as local dictionary. When the application or data source is connected with a server, the dictionary is opened locally, when the dictionary database path exists on client side and to as server dictionary otherwise.

     Code: 54
    to list
  45. KEY_FILE - Path to access key file

    The key required for accessing encoded databases may be passed via an access key file, which contains the key in one fo the supported formats (base64, hexadecimal, plain text, file reference). The path may contain option variables enclosed in %...%.

     Code: 55
    to list
to top previous next upper table of contents Comment