DBD::DtfSQLmac - A DBI driver for the dtF/SQL 2.01 database engine, Macintosh edition
use DBI 1.08; # or use DBI 1.08 qw(:sql_types :utils); $dsn = "dbi:DtfSQLmac:HardDisk:path:to:database"; # or $dsn = "dbi:DtfSQLmac:HardDisk:path:to:database;dtf_commit_on_disconnect=1"; # get a list of all available data sources (databases), the # search will start in the current directory @ary = DBI->data_sources('DtfSQLmac'); # specify the commit behavior when diconnecting from a database $dbh ->{dtf_commit_on_disconnect} = 1; # retrieve metadata about a table's columns %resulthash = $dbh->func($tablename, 'table_col_info'); # The additional statement handle attribute dtf_table holds a reference to # an array of table names for each result set's column $ary_ref = $sth->{dtf_table}; # valid after execute, read-only # For everything else, see the DBI module documentation and the corresponding # sections in this document for differences and/or additions.
MacPerl 5.2.0r4 (5.004) DBI 1.08 (Mac build for MacPerl 5.2.0r4) Mac::DtfSQL 0.3201 (part of the distribution)
MacPerl >= 5.6.1 DBI >= 1.08 (Mac build for MacPerl 5.6.1) Mac::DtfSQL 0.3201 (part of the distribution)
DBD::DtfSQLmac is a DBI driver for the dtF/SQL 2.01 database engine, Macintosh edition. dtF/SQL is a relational database engine for Mac OS, Windows 95/NT, and several Unix platforms from sLAB Banzhaf & Soltau oHG (http://www.slab.de/), Boeblingen, Germany. The dtF/SQL database engine implements an impressive set of ANSI SQL-92 functionality. It is designed as an embedded database for product developers. Best of all, it's free for non-commercial use.
The state of free (or nearly free) relational databases on the Macintosh running classic Mac OS isn't great, thus dtF/SQL is a remarkable exception. Because of the lack of free relational databases, the number of Perl DBI drivers usable for the Macintosh is limited (in fact, there's only a handful). This module should help to alleviate the situation.
DBD::DtfSQLmac, a pure Perl driver, could not be used stand-alone. It could only be used in conjunction with the Mac::DtfSQL module (part of the distribution), which is the Perl interface to the dtF/SQL database engine. While the Mac::DtfSQL extension module does all the dirty work talking to the dtF/SQL C API, this module, DBD::DtfSQLmac, offers the standard Perl DBI API to relational databases.
This module should run on a PowerPC Macintosh with Mac OS 7.x/8.x/9.x right out of the box. Unfortunately, users of a 68K Mac are a bit out of luck, because I cannot provide a pre-built version of the Mac::DtfSQL extension module for them. One will need a Metrowerks Codewarrior compiler and linker to build a version for CFM 68K Macs running MacPerl 5.2.0r4 (see the Mac::DtfSQL module documentation for more information). However, be aware that support for dynamic loading of shared libraries has been dropped for the 68K versions of the new MacPerl 5.6.1 (and higher) tool and application. Hence, you will have to link the Mac::DtfSQL extension statically into your MacPerl 5.6.1 binary.
The DBD::DtfSQLmac driver currently has two main limitations: First, it could only be used in single-user mode (i.e. locally), because the dtF/SQL Database-Server, needed for a network connection, doesn't work as expected (at least on a single Mac, acting both as a client and server; I haven't tested it in a network). Second, due to the underlying database engine, the driver is limited to one connection at a time.
Please see the Mac::DtfSQL module documentation for more information on the dtF/SQL 2.01 database engine and how to get it.
First, install the Mac build of the DBI 1.08 module, available from the MacPerl Module Porters Page (http://dev.macperl.org/mmp/). As with every module, use Chris Nandor's installme.plx droplet for installation. This installer is part of the cpan-mac-0.50 module, available from CPAN (http://www.perl.com/CPAN-local/authors/id/CNANDOR/) or via Chris Nandor's MacPerl page: http://pudge.net/macperl/.
After you've installed the DBI module, simply drop the packed archive DBD-DtfSQLmac-0.3201.tar.gz or the unpacked folder DBD-DtfSQLmac-0.3201 on the installme.plx droplet. Answer the upcoming question "Convert all text and MacBinary files?" with "Yes". This should install the module properly.
DBD-DtfSQLmac-0.3201.tar.gz
DBD-DtfSQLmac-0.3201
Afterwards, you have to install the dtF/SQL 2.01 shared library 'dtFPPCSV2.8K.shlb' by hand. The dtF/SQL 2.01 shared library comes with the distribution that you have to download from sLAB's web site (see the README document or DtfSQL.pm for details). Either put the 'dtFPPCSV2.8K.shlb' shared library (or at least an alias to it) in the SAME folder as the shared library 'DtfSQL' that comes with this module (by default, this folder is ':site_perl:MacPPC:auto:Mac:DtfSQL:) or put the dtF/SQL 2.01 shared library in the System Extensions folder. This is crucial since this module can only be used in conjunction with the dtF/SQL 2.01 shared library.
To be sure that everything is ok and the module loads properly, run the test.pl script first. Then run the test scripts located in the 't' folder. Some samples are provided in the 'samples' folder, to help you getting started.
More details may be found in the INSTALL.5004 document.
Always install the the DBI module first. The pre-built DBI module (version 1.21 as of this writing) for MacPerl 5.6.1 is available via the MacPerl Module Porters page (http://dev.macperl.org/mmp/). As with every module, use the installme.plx droplet for installation. This droplet is part of the MacPerl 5.6.1 distribution.
After you've installed the DBI module, simply drop the DBD-DtfSQLmac-0.3201.tar.gz packed archive or the unpacked folder DBD-DtfSQLmac-0.3201 on the installme.plx droplet. Answer the upcoming question "Convert all text and MacBinary files?" with "Yes". This should install the module properly.
More details may be found in the INSTALL.561 document.
A minimum of 10MB / 11MB of RAM assigned to the MacPerl 5.2.0r4 / 5.6.1 application. A minimum of 11MB / 12MB of RAM assigned to the MPW Shell for running the MacPerl 5.2.0r4 / 5.6.1 tool.
This module requires quite a bit of RAM, as noted above. These values were determined by running the DBI test suite that comes with this module. They should be regarded as the absolute minimum. The MacPerl 5.6.1 application and tool will need at least 1MB more RAM than the MacPerl 5.2.0r4 application and tool. However, as your database grows, be prepared to assign more memory to MacPerl. If the memory assigned is less than the minimum, the MacPerl application or tool may crash during connection. Otherwise, the MacPerl application and the tool usually report an "out of memory!" or a "Can't connect as user X" error. However, if you get such an out of memory error, it's better to quit the corresponding application (and assign more RAM to it). If you try to run another script, you can crash your computer.
The following is quoted from the DBI FAQ:
" 5.5 How can I create or drop a database with DBI?
Database creation and deletion are concepts that are entirely too abstract to be adequately supported by DBI. For example, Oracle does not support the concept of dropping a database at all! Also, in Oracle, the database server essentially is the database, whereas in mSQL, the server process runs happily without any databases created in it. The problem is too disparate to attack in a worthwhile way.
Some drivers, therefore, support database creation and deletion through the private func() methods. You should check the documentation for the drivers you are using to see if they support this mechanism. "
The DtfSQLmac driver does not have a dedicated method for creation and deletion of a database. Either use the dtfAdmin tool (PPC only) to create an (empty) database or use the createSampleDB.pl script as a template for your own database creation script. It's not a great challenge (see also the documentation of the Mac::DtfSQL module). To delete a database, simply drop it into the trash.
createSampleDB.pl
See the dtF/SQL (KNOWN) LIMITATIONS section in the Mac::DtfSQL module documentation for limitations of the dtF/SQL database engine.
$dsn = "dbi:DtfSQLmac:SampleDB.dtf"; $dbh = DBI->connect( $dsn, 'dtfadm', 'dtfadm', {RaiseError => 1, AutoCommit => 0} ) || die "Can't connect to database: " . DBI->errstr;
Generally, works as expected. Please note that the DtfSQLmac driver is limited to one connection at a time. You will get an error message, if you try to establish a second connection to the same or another database.
The AutoCommit and PrintError attributes for each connection default to on (see below and in the DBI.pm pod for more information regarding the AutoCommit and PrintError attributes). However, it is strongly recommended that AutoCommit is explicitly defined as required rather than rely on the default. Future versions of the DBI may issue a warning if AutoCommit is not explicitly defined.
@ary = DBI->data_sources('DtfSQLmac');
Returns a list of all data sources (databases) available via the DtfSQLmac driver. The search for dtF/SQL databases starts in the current working directory and will recursively step down the directory tree. Use the chdir function to set the directory you want to start with. The default working directory is determined according to the following rules:
chdir
The current working directory for a script on the Mac is the location of the MacPerl application, if the running script has not been saved yet. If the script is saved to disk, then the current directory is the location of that script. Unless you are using the MPW perl tool, in which case the current directory is the directory you are currently in with the MPW shell. Use the cwd() function exported by the Cwd.pm module to figure out what the current working directory is:
cwd()
use Cwd; $curdir = cwd(); # full path to the current working directory
All files of type 'DTFD' with creator 'dtF=' will be recognized as dtF/SQL database files.
Work as expected.
Generally, works as expected. The only additional driver specific method (i.e. non-portable) you are able to call is the table_col_info method. It works on a database handle, thus you have to call func as a method for a valid database handle $dbh. It allows you to retrieve metadata about a table's columns. Pass it a table name as an argument:
func
%resulthash = $dbh->func($tablename, 'table_col_info');
The table_col_info prototype could be declared as follows:
table_col_info
%resulthash = table_col_info ($tablename);
table_col_info retrieves metadata about a table's columns, i.e. for each column its name, its type (a DBI SQL type number), its type as string (as declared in CREATE TABLE), its position (starting with 0), its nullable attribute (0 or 1, where 0 means NOT nullable) and the column's comment are retrieved.
The result is returned as a hash, where the key is the column name and the value is a reference to an array holding the type, type as string, position, nullable and comment information:
%resulthash = ( columnname_0 => [$DBI_type, 'type as string', $position, $nullable, 'comment'], .. columnname_n => [$DBI_type, 'type as string', $position, $nullable, 'comment'], );
If you use the keys function to get at all column names, don't rely on their order to determine the column's position; always use the array's position element ( $resulthash{$columnname}->[2] ). If the table doesn't exist, an empty hash is returned (but no error is raised).
This section describes attributes common to all handles.
Example:
$h->{AttributeName} = ...; # set/write ... = $h->{AttributeName}; # get/read
The following attributes are handled by DBI itself and not by DBD::DtfSQLmac, thus they all should work like expected:
The following common DBI attribute is handled by DBD::DtfSQLmac and works as expected:
$sth = $dbh->prepare($statement) || die $dbh->errstr;
Generally, works as expected. However, the dtF/SQL database engine doesn't support the concept of prepared statements. This is nothing you have to worry about, as the DtfSQLmac driver does a fairly good job on emulating this concept. But you should keep in mind that the DtfSQLmac driver is unable to give much useful information about a statement, such as $sth->{NUM_OF_FIELDS}, until after $sth->execute has been called.
Not supported.
@usertables = $dbh->tables;
The tables method returns the names of all usertables. Views are not supported by the dtF/SQL database engine. Note that the five system tables ddrel, ddfield, dduser, ddindex and ddfkey are not included in this list.
ddrel
ddfield
dduser
ddindex
ddfkey
Work as expected. See the discussion of supported datatypes in the Statement Handle Attributes section.
$sql = $dbh->quote($value); $sql = $dbh->quote($value, $data_type);
Generally, works as expected. dtF/SQL's quote character for string/character datatype values is the single quotation mark "'". Thus,
$dbh->quote("Don't");
would return 'Don''t' (including the outer quotation marks).
'Don''t'
This section describes attributes specific to database handles.
$dbh->{AutoCommit} = ...; # set/write ... = $dbh->{AutoCommit}; # get/read
dtF/SQL supports transactions as units of work, i.e. a transaction is always active. (To be precise, you can abort a transaction, but the next SQL statement implicitly starts a new transaction, while the BEGIN TRANSACTION statement explicitly starts a transaction -- see the SQL Reference.) Transactions consist of an arbitrary number of database requests, regardless of their complexity. dtF/SQL ensures that all operations within a transaction are performed successfully, or not at all. With this transaction concept you can guarantee data integrity and consistency. Internally, only one transaction per client is allowed at a time, i.e. a client application cannot nest transactions.
If the AutoCommit attribute is true, then database changes cannot be rolled-back (undone). If false then database changes automatically occur within a 'transaction' which must either be committed or rolled-back using the commit or rollback methods.
According to the DBI convention, the DtfSQLmac driver defaults to AutoCommit mode true (or on if you like).
Important note: Changing the AutoCommit attribute from off to on will issue a commit, i.e. all outstanding changes will implicitely be committed (made permanent) and cannot be rolled-back (undone) afterwards. Be careful with this feature. You might want to do a rollback before changing the AutoCommit mode! Changing AutoCommit from on to off has no immediate effect.
The AutoCommit attribute is discussed in greater detail in the DBI.pm pod.
dtf_commit_on_disconnect is a private driver database handle attribute (as indicated by the starting phrase dtf_). It specifies the commit behavior when you disconnect from a database. The DBI spec complains, that the transaction behavior of the disconnect method is undefined for most databases (see the documentation for the disconnect method in the DBI module). With the dtf_commit_on_disconnect attribute, you are able to make this behavior explicit for the DtfSQLmac driver: 0 means no commit on disconnect, while 1 means the opposite. You can either supply the attribute's setting as part of the data source name (separated by a semicolon), e.g.
dtf_commit_on_disconnect
$dsn = "dbi:DtfSQLmac:SampleDB.dtf;dtf_commit_on_disconnect=1";
or, after you've created a database handle $dbh, set its value as usual with
$dbh->{dtf_commit_on_disconnect} = 1;
The default value is 0, that is, no automatic commit on disconnect. Don't mistake this attribute with the AutoCommit attribute, which specifies whether (or not) each statement should automatically be committed.
$rc = $sth->bind_param($p_num, $bind_value) || die $sth->errstr; $rv = $sth->bind_param($p_num, $bind_value, \%attr) || ... $rv = $sth->bind_param($p_num, $bind_value, $bind_type) || ...
Generally, works as expected. The bind_param method can be used to bind (assign/associate) a value with a placeholder embedded in the prepared statement. Placeholders are indicated with the question mark character (?). For example:
$sth = $dbh->prepare("SELECT firstname, lastname FROM clients WHERE firstname = ?"); $sth->bind_param(1, "Thomas", SQL_VARCHAR); # placeholders are numbered from 1 $sth->execute;
Note that the ? is not enclosed in quotation marks even when the placeholder represents a string. Every question mark enclosed in single quotes will not be recognized as a placeholder by the DtfSQLmac driver. This allows you to insert string data that may contain a question mark.
Note also that you should not quote the actual value that you intend to bind to the placeholder, since that's done internally by the driver. E.g. don't make a call like
$sth->execute($dbh->quote($firstname)); # don't do that !
[ Side-note: Due to the dtF/SQL quoting rules, where a single quotation mark must be doubled if you want to insert it as data (e.g. don't must be quoted as 'don''t'), a valid SQL statement has an even number of single quotes (or pairs of quotes, if you like). The execute method will check this and raise an error, if the quotes don't occur in pairs. ]
Undefined bind values or undef are be used to indicate NULL values.
The third parameter can be used to hint at the data type the placeholder should have. Either use
$sth->bind_param(1, $value, { TYPE => SQL_INTEGER }); or $sth->bind_param(1, $value, SQL_INTEGER);
as a short-cut.
The DtfSQLmac driver is only interested in knowing if the placeholder should be bound as a number or a string. It's sufficient if you either pass SQL_VARCHAR for string types or SQL_INTEGER for numeric types to bind_param (but you are not restricted to these two, see below). After the first call of bind_param, the type hint for that particular placeholder is "frozen", i.e. all subsequent calls to bind_param could be made without a type hint for that placeholder. If the type hint is provided again, it will be ignored. In other words, you cannot change the type hint of a parameter after the first call to bind_param (but it can be left unspecified, in which case it defaults to the previous value). If your first call to bind_param for a particular placeholder has no type hint, SQL_VARCHAR is assumed as a default and cannot be changed afterwards. This may or may not be what you wanted, so be careful. Please note that the undef value, which indicates a NULL value, is compatible with every type. All undef values will be bound as the string NULL, without quotation marks, even if the type is a string type (SQL_VARCHAR).
Don't abuse placeholders for any element of a SQL statement that is not associated with a table's field, i.e. don't use a placeholder for a table name, column name, SQL-clause etc. A placeholder should always be treated as a column-parameter that has a column's data type (for which you then can provide the actual data). However, the DtfSQLmac driver doesn't prevent you from doing weird things with placeholders. But your code will probably fail with other drivers, i.e. your code will not be portable.
Data Types for Placeholders
The TYPE value you provide to bind_param indicates a standard (non-driver-specific) type for this parameter. The DtfSQLmac driver supports the following ten DBI SQL type constants:
SQL_TINYINT (numeric) SQL_SMALLINT (numeric) SQL_INTEGER (numeric) SQL_DOUBLE (numeric) SQL_DECIMAL (numeric) SQL_CHAR (string type) SQL_VARCHAR (string type) SQL_DATE (string type) SQL_TIME (string type) SQL_TIMESTAMP (string type)
While the four following defined DBI SQL type numbers
SQL_LONGVARCHAR -> SQL_VARCHAR SQL_NUMERIC -> SQL_DECIMAL SQL_FLOAT -> SQL_DOUBLE SQL_REAL -> SQL_DOUBLE
will be mapped to their nearest corresponding DBI SQL type constant as shown, the three (as of DBI 1.08) binary data types (blob)
SQL_BINARY SQL_VARBINARY SQL_LONGVARBINARY
and
SQL_BIGINT (omitted/deprecated as of DBI 1.21)
are not supported at all. (Note that SQL_BIGINT was formerly mapped to SQL_INTEGER, but beginning with version 0.3201 of this module this mapping is no longer provided, since DBI 1.21 omitted SQL_BIGINT.) Likewise, any other DBI SQL type constant found in more recent versions of the DBI module are not supported at all. You will get an error message if you specify one of these constants.
Please note: With the DtfSQLmac driver, we always retrieve field values as string. This is done even for field values that have a decimal (fixed point number) data type, although the underlying Mac::DtfSQL module allows the retrieval as decimal object for these fields (see the Mac::DtfSQL module documentation for details). Thus, all data you may retrieve from the database is a scalar in Perl. These scalars will contain either numbers or strings. In general, conversion from one form to another is transparent, i.e. happens automatically in Perl. Generally, if a string represents a decimal, it is converted to a scalar holding a floating point number in arithmetical operations. Due to this conversion the accuracy may suffer. However, in order to avoid this, you are able to create a decimal object, assign it a value from a string that represents a decimal, perform arithmetical operations with it and then store it back to the database (see the dbi_6_update-decimal.pl sample script).
dbi_6_update-decimal.pl
See also the section on Placeholders and Bind Values in the DBI documentation for more information.
$rv = $sth->rows;
Returns the number of rows affected by the last executed statement.
Returns -1, if the statement is not a row affecting statement, for example a create, drop, grant, and revoke statement. If the statement was of a modifying kind (insert, update, delete statements), the number of affected records is returned. For select statements, the number of rows in the result set will be returned. You can always rely on the returned row count information, as the dtF/SQL database engine is able to return valid values even for select statements.
This section describes attributes specific to statement handles. Most of these attributes are read-only.
... = $sth->{NUM_OF_FIELDS}; # get/read
Note that the DtfSQLmac driver cannot provide valid values for most of the attributes until after $sth->execute has been called (except for the NUM_OF_PARAMS attribute, which is valid after $sth = $dbh->prepare).
The number of parameters (placeholders) in the prepared statement.
Number of fields (columns) the prepared statement will return. Non-select statements will have NUM_OF_FIELDS == 0.
Returns a reference to an array of field names for each result set's column. The names may contain spaces but should not be truncated or have any trailing space. Note that the names have the letter case (upper, lower or mixed) as defined in the CREATE TABLE statement. Portable applications should use NAME_lc or NAME_uc.
print "First column name: $sth->{NAME}->[0]\n";
Undef for non-select statements.
Like NAME in the manpage but always returns lowercase names.
Like NAME in the manpage but always returns uppercase names.
This is a private driver statement handle attribute (as indicated by the starting phrase dtf_). As a convenience for the user, it returns a reference to an array of corresponding table names for each result set's column. Thus, for each field name in the NAME array, you can easily determine the table name this particular column/field belongs to.
Returns a reference to an array of integer values for each result set's column. The value indicates the data type of the corresponding column. Note that the binary data type (blob -- binary large objects) is not supported. Returns undef for non-select statements.
The DtfSQLmac driver internally uses the following ten DBI SQL type constants:
SQL_TINYINT (= -6) SQL_SMALLINT (= 5) SQL_INTEGER (= 4) SQL_DOUBLE (= 8) SQL_DECIMAL (= 3) SQL_CHAR (= 1) SQL_VARCHAR (= 12) SQL_DATE (= 9) SQL_TIME (= 10) SQL_TIMESTAMP (= 11)
Run the dbi_108_types.pl script (part of the distribution) to get a complete list of all DBI 1.08 SQL type numbers.
dbi_108_types.pl
All possible dtF/SQL types as used in a CREATE TABLE statement are mapped to the standard DBI SQL type numbers as shown in the following table.
DBI SQL type const | dtF/SQL type * | dtF/SQL internal C type ----------------------+-------------------------------+----------------------------------------- SQL_TINYINT | CHAR (numeric) ** | char (1 byte) SQL_TINYINT | BYTE | unsigned char (1 byte) | | SQL_SMALLINT | SMALLINT or SHORT | short (2 byte), SQL_SMALLINT | WORD | unsigned short (2 byte) | | SQL_INTEGER | INTEGER or INT or LONG | int, long (4 byte signed) SQL_INTEGER | LONGWORD | unsigned long (4 byte unsigned) | | SQL_DOUBLE | REAL | double SQL_DOUBLE | FLOAT | double SQL_DOUBLE | DOUBLE | double | | SQL_DECIMAL | DECIMAL(precision,scale) or | DTFDECIMAL | DEC(p,s) or NUMERIC(p,s) | | | SQL_CHAR | CHAR(x) ** or CHARACTER(x) | String max. 4095 characters | (fixed length) | + \0 (Nul char) | | SQL_VARCHAR | SHORTSTRING or VARCHAR(x) | String max. 4095 characters | or CHAR VARYING(x) | + \0 (Nul char) | | SQL_DATE | DATE | String: yyyy-mm-dd or yyyy/mm/dd SQL_TIME | TIME | String: hh:mm:ss[.fff] (24 hour) *** SQL_TIMESTAMP | TIMESTAMP | String: yyyy-mm-dd hh:mm:ss[.fff] *** | | SQL_BINARY | BIT (not supported) | char[] (not supported) SQL_VARBINARY | BIT (not supported) | char[] (not supported) SQL_LONGVARBINARY | BIT (not supported) | char[] (not supported) * As used in a CREATE TABLE statement ** Note: While CHAR means a numeric data type (signed byte), CHAR(x) means a character string of some fixed length x. Internally, 'CHAR(' is used to denote a string/character data type. *** with optional second fractions
Note that in some cases two or more dtF/SQL types are mapped to the same DBI SQL type constant (e.g. the CHAR and BYTE numeric types are both mapped to SQL_TINYINT). This is not an error, as the DBI specification explicitely allows type variants, for example a signed or unsigned variant (see the documentation for the type_info() method). Thus, all possible values for TYPE have at least one entry in the output of the type_info_all() method.
type_info()
type_info_all()
Returns a reference to an array of integer values for each result set's column. Depending on the TYPE of the column, the following values are returned:
SQL_TINYINT: precision is 3, and the display width should be 4 (for the sign) SQL_SMALLINT: precision is 5, and the display width should be 6 (for the sign) SQL_INTEGER: precision is 10, and the display width should be 11 (for the sign) SQL_DOUBLE: precision is 15, and the display width should be 22 (for the sign + decimal point + the letter E + a sign + 2 or 3 digits) SQL_DECIMAL: precision is the precision as declared in the type definition of the CREATE TABLE statement, and the display width should be precision + 2 (for the sign + decimal point) SQL_CHAR: precision is the max. length as declared in the type definition of the CREATE TABLE statement, and the display width should be the same SQL_VARCHAR: precision is the max. length as declared in the type definition of the CREATE TABLE statement or 4095 if you've used the SHORTSTRING type, and the display width should be the same SQL_DATE: precision is 10, and the display width should be the same (yyyy-mm-dd) SQL_TIME: precision is 12, and the display width should be the same (hh:mm:ss[.fff]) SQL_TIMESTAMP: precision is 23, and the display width should be the same (yyyy-mm-dd hh:mm:ss[.fff])
Returns a reference to an array of integer values for each column. Actually, scale is only valid when the TYPE is a decimal (SQL_DECIMAL). For all other data types, an undef value is returned (to indicate that scale is not applicable).
Works as expected. Returns a reference to an array indicating the possibility of each column returning a null: 0 = no (i.e. declared as NOT NULL or PRIMARY KEY), 1 = yes, 2 = unknown.
Returns the statement string passed to the $dbh->prepare method.
$dbh->prepare
No known bugs. Please report bugs to the author.
Thomas Wegner t_wegner@gmx.net
Copyright (c) 2000-2002 Thomas Wegner. All rights reserved. This program is free software. You may redistribute it and/or modify it under the terms of the Artistic License, distributed with Perl.
DBI, Mac::DtfSQL, The dtF/SQL 2.01 documentation: Introduction.pdf, C/C++/Java Reference.pdf, Programmer's Manual.pdf and SQL Reference.pdf
For general DBI information and questions, see the DBI home page at
http://dbi.perl.org/
2 POD Errors
The following errors were encountered while parsing the POD:
Can't have a 0 in =over 0
To install DBD::DtfSQLmac, copy and paste the appropriate command in to your terminal.
cpanm
cpanm DBD::DtfSQLmac
CPAN shell
perl -MCPAN -e shell install DBD::DtfSQLmac
For more information on module installation, please visit the detailed CPAN module installation guide.