Specifies the database to which to connect. This information can be given in the following ways:

	Driver/DB/Host.
	Same as the first parameter to the DBI connect function.
	DBIx::Recordset object
	Takes the same database handle as the given DBIx::Recordset object.
	DBIx::Database object
	Takes Driver/DB/Host from the given database object. See DBIx::Database for details about DBIx::Database object. When using more then one Recordset object, this is the most efficient method.
	DBIx::Datasbase object name
	Takes Driver/DB/Host from the database object which is saved under the given name ($saveas parameter to DBIx::Database -> new)
	an DBI database handle
	Uses given database handle.

Tablename. Multiple tables are comma-separated.

Username. Same as the second parameter to the DBI connect function.

Password. Same as the third parameter to the DBI connect function.

Reference to a hash which holds the attributes for the DBI connect function. See perldoc DBI for a detailed description.

Fields which should be returned by a query. If you have specified multiple tables the fieldnames should be unique. If the names are not unique you must specify them along with the tablename (e.g. tab1.field).

NOTE 1: Fieldnames specified with !Fields can't be overridden. If you plan to use other fields with this object later, use $Fields instead.

NOTE 2: The keys for the returned hash normally don't have a table part. Only the fieldname part forms the key. (See !LongNames for an exception.)

NOTE 3: Because the query result is returned in a hash, there can only be one out of multiple fields with the same name fetched at once. If you specify multiple fields with the same name, only one is returned from a query. Which one this actually is depends on the DBD driver. (See !LongNames for an exception.)

NOTE 4: Some databases (e.g. mSQL) require you to always qualify a fieldname with a tablename if more than one table is accessed in one query.

The TableFilter parameter specifies which tables should be honoured when DBIx::Recordset searches for links between tables (see below). When given as parameter to DBIx::Database it filters for which tables DBIx::Database retrieves metadata. Only thoses tables are used which starts with prefix given by !TableFilter. Also the DBIx::Recordset link detection tries to use this value as a prefix of table names, so you can leave out this prefix when you write a fieldname that should be detected as a link to another table.

When set to 1, the keys of the hash returned for each record not only consist of the fieldnames, but are built in the form table.field.

Fields which should be used for ordering any query. If you have specified multiple tables the fieldnames should be unique. If the names are not unique you must specify them among with the tablename (e.g. tab1.field).

NOTE 1: Fieldnames specified with !Order can't be overridden. If you plan to use other fields with this object later, use $order instead.

Condition which describes the relation between the given tables (e.g. tab1.id = tab2.id) (See also !TabJoin.)

  Example

  '!Table'       => 'tab1, tab2',
  '!TabRelation' => 'tab1.id=tab2.id',
  'name'         => 'foo'

  This will generate the following SQL statement:

  SELECT * FROM tab1, tab2 WHERE name = 'foo' and tab1.id=tab2.id ;

!TabJoin allows you to specify an INNER/RIGHT/LEFT JOIN which is used in a SELECT statement. (See also !TabRelation.)

  Example

  '!Table'   => 'tab1, tab2',
  '!TabJoin' => 'tab1 LEFT JOIN tab2 ON	(tab1.id=tab2.id)',
  'name'     => 'foo'

  This will generate the following SQL statement:

  SELECT * FROM tab1 LEFT JOIN tab2 ON	(tab1.id=tab2.id) WHERE name = 
'foo' ;

Name of the primary key. When this key appears in a WHERE parameter list (see below), DBIx::Recordset will ignore all other keys in the list, speeding up WHERE expression preparation and execution. Note that this key does NOT have to correspond to a field tagged as PRIMARY KEY in a CREATE TABLE statement.

Name of the primary key. In contrast to !PrimKey this field is treated as an autoincrement field. If the database does not support autoincrement fields, but sequences the field is set to the next value of a sequence (see !Sequence and !SeqClass) upon each insert. If a !SeqClass is given the values are always retrived from the sequence class regardless if the DBMS supports autoincrement or not. The value from this field from the last insert could be retrieved by the function LastSerial.

Name of the sequence to use for this table when inserting a new record and !Serial is defind. Defaults to <tablename>_seq.

Name and Parameter for a class that can generate unique sequence values. This is a string that holds comma separated values. The first value is the class name and the following parameters are given to the new constructor. See also DBIx::Recordset::FileSeq and DBIx::Recordset::DBSeq.

Example: '!SeqClass' => 'DBIx::Recordset::FileSeq, /tmp/seq'

!WriteMode specifies which write operations to the database are allowed and which are disabled. You may want to set !WriteMode to zero if you only need to query data, to avoid accidentally changing the content of the database.

NOTE: The !WriteMode only works for the DBIx::Recordset methods. If you disable !WriteMode, it is still possible to use do to send normal SQL statements to the database engine to write/delete any data.

!WriteMode consists of some flags, which may be added together:

	DBIx::Recordset::wmNONE (0)
	Allow no write access to the table(s)
	DBIx::Recordset::wmINSERT (1)
	Allow INSERT
	DBIx::Recordset::wmUPDATE (2)
	Allow UPDATE
	DBIx::Recordset::wmDELETE (4)
	Allow DELETE
	DBIx::Recordset::wmCLEAR (8)
	To allow DELETE for the whole table, wmDELETE must be also specified. This is necessary for assigning a hash to a hash which is tied to a table. (Perl will first erase the whole table, then insert the new data.)
	DBIx::Recordset::wmALL (15)
	Allow every access to the table(s)

Default is wmINSERT + wmUPDATE + wmDELETE

If present, this will cause DBIx::Recordset to store all rows which will be fetched between consecutive accesses, so it's possible to access data in a random order. (e.g. row 5, 2, 7, 1 etc.) If not specified, rows will only be fetched into memory if requested, which means that you will have to access rows in ascending order. (e.g. 1,2,3 if you try 3,2,4 you will get an undef for row 2 while 3 and 4 is ok) see also DATA ACCESS below.

By default, the hash returned by the setup function is tied to the current record. You can use it to access the fields of the current record. If you set this parameter to true, the hash will by tied to the whole database. This means that the key of the hash will be used as the primary key in the table to select one row. (This parameter only has an effect on functions which return a typglob.)

This parameter defines how empty and undefined values are handled. The values 1 and 2 may be helpful when using DBIx::Recordset inside a CGI script, because browsers send empty formfields as empty strings.

	0 (default)
	An undefined value is treated as SQL NULL: an empty string remains an empty string.
	1
	All fields with an undefined value are ignored when building the WHERE expression.
	2
	All fields with an undefined value or an empty string are ignored when building the WHERE expression.

NOTE: The default for versions before 0.18 was 2.

Filters can be used to pre/post-process the data which is read from/written to the database. The !Filter parameter takes a hash reference which contains the filter functions. If the key is numeric, it is treated as a type value and the filter is applied to all fields of that type. If the key if alphanumeric, the filter is applied to the named field. Every filter description consists of an array with at least two elements. The first element must contain the input function, and the second element must contain the output function. Either may be undef, if only one of them are necessary. The data is passed to the input function before it is written to the database. The input function must return the value in the correct format for the database. The output function is applied to data read from the database before it is returned to the user. Example:

     '!Filter'   => 
	{
	DBI::SQL_DATE     => 
	    [ 
		sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
		sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
	    ],

'datefield' => [ sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"}, sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"} ],

}

Both filters convert a date in the format dd.mm.yy to the database format 19yymmdd and vice versa. The first one does this for all fields of the type SQL_DATE, the second one does this for the fields with the name datefield.

The !Filter parameter can also be passed to the function TableAttr of the DBIx::Database object. In this case it applies to all DBIx::Recordset objects which use these tables.

A third parameter can be optionally specified. It could be set to DBIx::Recordset::rqINSERT, DBIx::Recordset::rqUPDATE, or the sum of both. If set, the InputFunction (which is called during UPDATE or INSERT) is always called for this field in updates and/or inserts depending on the value. If there is no data specified for this field as an argument to a function which causes an UPDATE/INSERT, the InputFunction is called with an argument of undef.

During UPDATE and INSERT the input function gets either the string 'insert' or 'update' passed as second parameter.

This allows you to get a clear text description of a linked table, instead of (or in addition to) the !LinkField. For example, if you have a record with all your bills, and each record contains a customer number, setting !LinkName DBIx::Recordset can automatically retrieve the name of the customer instead of (or in addition to) the bill record itself.

	1 select additional fields
	This will additionally select all fields given in !NameField of the Link or the table attributes (see TableAttr).
	2 build name in uppercase of !MainField
	This takes the values of !NameField of the Link or the table attributes (see TableAttr) and joins the content of these fields together into a new field, which has the same name as the !MainField, but in uppercase.
	2 replace !MainField with the contents of !NameField
	Same as 2, but the !MainField is replaced with "name" of the linked record.

See also !Links and WORKING WITH MULTIPLE TABLES below

This parameter can be used to link multiple tables together. It takes a reference to a hash, which has - as keys, names for a special "linkfield" and - as value, a parameter hash. The parameter hash can contain all the Setup parameters. The setup parameters are taken to construct a new recordset object to access the linked table. If !DataSource is omitted (as it normally should be), the same DataSource (and database handle), as the main object is taken. There are special parameters which can only occur in a link definition (see next paragraph). For a detailed description of how links are handled, see WORKING WITH MULTIPLE TABLES below.

The !MailField parameter holds a fieldname which is used to retrieve a key value for the search in the linked table from the main table. If omitted, it is set to the same value as !LinkedField.

The fieldname which holds the key value in the linked table. If omitted, it is set to the same value as !MainField.

This specifies the field or fields which will be used as a "name" for the destination table. It may be a string or a reference to an array of strings. For example, if you link to an address table, you may specify the field "nickname" as the name field for that table, or you may use ['name', 'street', 'city'].

Look at !LinkName for more information.

You can give an SQL Statement (or an array reference of SQL statements), that will be executed every time, just after an connect to the db. As third possibilty you can give an hash reference. After every successful connect, DBIx::Recordset excutes the statements, in the element which corresponds to the name of the driver. '*' is executed for all drivers.

Specifies default values for new rows that are inserted via hash or array access. The Insert method ignores this parameter.

Setting this parameter to zero will cause DBIx::Recordset to not tie the returned rows to an DBIx::Recordset::Row object and instead returns an simple hash. The benefit of this is that it will speed up things, but you aren't able to write to such an row, nor can you use the link feature with such a row.

Set the debug level. See DEBUGGING.

Only for tieing a hash! Gives an where expression (either as string or as hashref) that is used to prefetch records from that database. All following accesses to the tied hash only access this prefetched data and don't execute any database queries. See !Expires how to force a refetch. Giving a '*' as value to !PreFetch fetches the whole table into memory.

 The following example prefetches all record with id < 7:

 tie %dbhash, 'DBIx::Recordset::Hash', {'!DataSource'   =>  $DSN,
                                        '!Username'     =>  $User,
                                        '!Password'     =>  $Password,
                                        '!Table'        =>  'foo',
                                        '!PreFetch'     =>  {
                                                             '*id' => '<',
                                                             'id' => 7
                                                            },
                                        '!PrimKey'      =>  'id'} ;

 The following example prefetches all records:

 tie %dbhash, 'DBIx::Recordset::Hash', {'!DataSource'   =>  $DSN,
                                        '!Username'     =>  $User,
                                        '!Password'     =>  $Password,
                                        '!Table'        =>  'bar',
                                        '!PreFetch'     =>  '*',
                                        '!PrimKey'      =>  'id'} ;

Only for tieing a hash! If the values is numeric, the prefetched data will be refetched is it is older then the given number of seconds. If the values is a CODEREF the function is called and the data is refetched is the function returns true.

Only for tieing a hash! Gives an reference to an function that is called when more then one record for a given hash key is found to merge the records into one. The function receives a refence to both records a arguments. If more the two records are found, the function is called again for each following record, which is already merged data as first parameter.

 The following example sets up a hash, that, when more then one record with the same id is
 found, the field C<sum> is added and the first record is returned, where the C<sum> field
 contains the sum of B<all> found records:

 tie %dbhash, 'DBIx::Recordset::Hash', {'!DataSource'   =>  $DSN,
                                        '!Username'     =>  $User,
                                        '!Password'     =>  $Password,
                                        '!Table'        =>  'bar',
                                        '!MergeFunc'    =>  sub { my ($a, $b) = @_ ; $a->{sum} += $b->{sum} ; },
                                        '!PrimKey'      =>  'id'} ;

Give an SQL WHERE expression literaly. If $where is specified, all other where parameters described below are ignored. The only expection is $values which can be used to give the values to bind to the placeholders in $where

Values which should be bound to the placeholders given in $where.

 Example:

 *set = DBIx::Recordset -> Search ({'!DataSource' => 'dbi:Oracle:....',
                                    '!Table'      => 'users',
                                    '$where'      => 'name = ? and age > ?',
                                    '$values'     => ['richter', 25] }) ;
 

NOTE: Filters defined with !Filter are not applied to these values, because DBIx::Recordset has no chance to know with values belongs to which field.

Value for field. The value will be quoted automatically, if necessary. The value can also be an array ref in which case the values are put together with the operator passed via $valueconj (default: or)

  Example:

  'name' => [ 'mouse', 'cat'] will expand to name='mouse' or name='cat'

Value for field. The value will always be quoted. This is only necessary if DBIx::Recordset cannot determine the correct type for a field.

Value for field. The value will never be quoted, but will converted a to number. This is only necessary if DBIx::Recordset cannot determine the correct type for a field.

Value for field. The value will not be converted in any way, i.e. you have to quote it before supplying it to DBIx::Recordset if necessary.

Values for multiple fields. The value must be in one/all fields depending on $compconj Example: '+name|text' => 'abc' will expand to name='abc' or text='abc'

'or' or 'and' (default is 'or'). Specifies the conjunction between multiple fields. (see above)

Regular expression for splitting a field value in multiple values (default is '\t') The conjunction for multiple values could be specified with $valueconj. By default, only one of the values must match the field.

 Example:
 'name' => "mouse\tcat" will expand to name='mouse' or name='cat'

 NOTE: The above example can also be written as 'name' => [ 'mouse', 'cat']

'or' or 'and' (default is 'or'). Specifies the conjunction for multiple values.

'or' or 'and' (default is 'and') conjunction between fields

Default operator if not otherwise specified for a field. (default is '=')

Operator for the named field

 Example:
 'value' => 9, '*value' => '>' expand to value > 9

Could also be an array ref, so you can pass different operators for the values. This is mainly handy when you need to select a range

  Example:

    $set -> Search  ({id          => [5,    7   ],
                     '*id'        => ['>=', '<='],
                     '$valueconj' => 'and'})  ;

  This will expanded to "id >= 5 and id <= 7"

NOTE: To get a range you need to specify the $valueconj parameter as and because it defaults to or.

$expr can be used to group parts of the where expression for proper priority. To specify more the one sub expression, add a numerical index to $expr (e.g. $expr1, $expr2)

  Example:

    $set -> Search  ({id          => 5,
                     '$expr'      => 
                        {
                        'name'  => 'Richter',
                        'country' => 'de',
                        '$conj'   => 'or'
                        }
                      }) ;

    This will expand to

        (name = 'Richter' or country = 'de') and id = 5
                     

First row to fetch. The row specified here will appear as index 0 in the data array.

Maximum number of rows to fetch. Every attempt to fetch more rows than specified here will return undef, even if the select returns more rows.

Add the number supplied with $max to $start. This is intended to implement a next button.

Subtract the number supplied with $max from $start. This is intended to implement a previous button.

Fieldname(s) for ordering (ORDER BY) (must be comma-separated, could also contain USING)

Fieldname(s) for grouping (GROUP BY) (must be comma-separated, could also contain HAVING).

String which is appended to the end of a SELECT statement, can contain any data.

Fields which should be returned by a query. If you have specified multiple tables the fieldnames should be unique. If the names are not unique you must specify them along with the tablename (e.g. tab1.field).

NOTE 1: If !fields is supplied at setup time, this can not be overridden by $fields.

NOTE 2: The keys for the returned hash normally don't have a table part. Only the fieldname part forms the key. (See !LongNames for an exception.)

NOTE 3: Because the query result is returned in a hash, there can only be one out of multiple fields with the same name fetched at once. If you specify multiple fields with same name, only one is returned from a query. Which one this actually is, depends on the DBD driver. (See !LongNames for an exception.)

Name of primary key. DBIx::Recordset assumes that if specified, this is a unique key to the given table(s). DBIx::Recordset can not verify this. You are responsible for specifying the right key. If such a primary exists in your table, you should specify it here, because it helps DBIx::Recordset optimize the building of WHERE expressions.

See also !PrimKey

search data

update record(s)

insert record

delete record(s)

setup empty object