Databases

A single Kitto^x application can work on multiple databases, of different kinds. The Databases node in Config.yaml contains one or more subnodes, each containing the connection params to a database. The subnode called Main is the one used by default for database access. Give a different name to each subnode as in the following example:

Databases:
  Main: ADO
    Connection:
      .............................
  OTHER: ADO
    Connection:
    ..............................

Adapters

An adapter is a wrapper that allows Kitto^x to connect to a particular database (or a family of databases) through a particular data access library. Currently Kitto^x has three adapters:

• DBX to use Delphi's DBExpress data access layer.
• ADO to use Microsoft's ADO.
• FD to use Delphi's FireDac data access layer.

More adapters can be developed and plugged in as needed.

The adapter is specified by name as the value of each database's subnode.

Database types

Each adapter detects the type of database it is using and uses this information to affect the behaviour of Kitto^x, for example to generate slightly different SQL statements depending on the particular dialect the database understands.

Connection subnode

You specify each database's settings inside a Connection subnode whose structure depends on the adapter. For example, the ADO adapter accepts a single ConnectionString subnode with all params in the typical ADO format:

Example:

Databases:
  Main: ADO
    Connection:
      ConnectionString: >
        Provider=SQLOLEDB.1;User ID=sa;Password=xxx;
        Initial Catalog=MyDatabase;Data Source=%COMPUTERNAME%

DBX allows for specifying params as direct subnodes:

Databases:
  Main: DBX
    Connection:
      DriverName: DevartSQLServer
      HostName: %COMPUTERNAME%
      DataBase: MyDatabase
      User_Name: sa
      Password: xxx
      GetDriverFunc: getSQLDriverSQLServer
      LibraryName: dbexpsda40.dll
      VendorLib: sqloledb.dll

FD allows for specifying params as direct subnodes, specific to DriverID:

Databases:
  FDMSSQL: FD
    Connection:
      DriverID: MSSQL
      Server: %COMPUTERNAME%\MSSQL2K8R2
      ApplicationName: %APPTITLE%
      Database: HelloKitto
      OSAuthent: Yes
      Isolation: RepeatableRead
    
  FDFb: FD
    Connection:
      DriverID: FB
      # Alias of database defined in Aliases.conf
      Database: HELLOKITTO
      User_Name: SYSDBA
      Password: masterkey
      Server: localhost
      CharacterSet: UTF8
      Protocol: TCPIP

FireDAC driver registration

When using the FD (FireDAC) adapter, the physical driver unit for the target database must be compiled into your application. There are two approaches:

Approach 1: Explicit uses in UseKitto.pas (recommended for clarity)

Add the FireDAC driver units directly in your UseKitto.pas:

uses
  Kitto.Html.All,
  EF.DB.FD,
  // FireDAC drivers — include only the ones you need
  FireDAC.Phys.MSSQL, FireDAC.Phys.MSSQLMeta,   // SQL Server
  FireDAC.Phys.IBBase, FireDAC.Phys.FB,           // Firebird
  // FireDAC.Phys.PG, FireDAC.Phys.PGWrapper,     // PostgreSQL
  // FireDAC.Phys.MySQL, FireDAC.Phys.MySQLWrapper,// MySQL
  // FireDAC.Phys.Oracle, FireDAC.Phys.OracleMeta, // Oracle
  // FireDAC.Phys.SQLite, FireDAC.Phys.SQLiteWrapper,// SQLite
  Kitto.Auth.DB;

This is the approach used by the HelloKitto and TasKitto examples.

Approach 2: Conditional defines in the project (used by KEmployee)

The EF.DB.FD unit includes driver units conditionally via {$IFDEF} directives. Add the appropriate define to your project options (Project → Options → Delphi Compiler → Conditional defines):

Define	Enables
IBFB_SUPPORT	Firebird and InterBase (FireDAC.Phys.FB, FireDAC.Phys.IB)
MSSQL_SUPPORT	SQL Server (FireDAC.Phys.MSSQL)
ORACLE_SUPPORT	Oracle (FireDAC.Phys.Oracle)
PGSQL_SUPPORT	PostgreSQL (FireDAC.Phys.PG)
MYSQL_SUPPORT	MySQL (FireDAC.Phys.MySQL)
SQLITE_SUPPORT	SQLite (FireDAC.Phys.SQLite)

All projects must have the same defines

When you have multiple deployment projects for the same application (Standalone, Desktop, ISAPI, Apache), make sure all .dproj files include the same conditional defines. Otherwise the driver will be registered in one project but not in another, causing "Object factory missing" errors at runtime.

AfterOpenCommandText

If specified, the value of Connection/!AfterOpenCommandText is executed as a SQL command each time a connection is made. Useful if special connection setup is needed. The command text may contain macros.