{
    "mode": "perldoc",
    "parameter": "DBD::DBM",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/DBD%3A%3ADBM/json",
    "generated": "2026-07-06T21:17:26Z",
    "synopsis": "use DBI;\n$dbh = DBI->connect('dbi:DBM:');                    # defaults to SDBMFile\n$dbh = DBI->connect('DBI:DBM(RaiseError=1):');      # defaults to SDBMFile\n$dbh = DBI->connect('dbi:DBM:dbmtype=DBFile');    # defaults to DBFile\n$dbh = DBI->connect('dbi:DBM:dbmmldbm=Storable');  # MLDBM with SDBMFile\n# or\n$dbh = DBI->connect('dbi:DBM:', undef, undef);\n$dbh = DBI->connect('dbi:DBM:', undef, undef, {\nfext              => '.db/r',\nfdir              => '/path/to/dbfiles/',\nflockfile         => '.lck',\ndbmtype           => 'BerkeleyDB',\ndbmmldbm          => 'FreezeThaw',\ndbmstoremetadata => 1,\ndbmberkeleyflags => {\n'-Cachesize' => 1000, # set a ::Hash flag\n},\n});\nand other variations on connect() as shown in the DBI docs, DBD::File metadata and \"Metadata\"\nshown below.\nUse standard DBI prepare, execute, fetch, placeholders, etc., see \"QUICK START\" for an example.",
    "sections": {
        "NAME": {
            "content": "DBD::DBM - a DBI driver for DBM & MLDBM files\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "use DBI;\n$dbh = DBI->connect('dbi:DBM:');                    # defaults to SDBMFile\n$dbh = DBI->connect('DBI:DBM(RaiseError=1):');      # defaults to SDBMFile\n$dbh = DBI->connect('dbi:DBM:dbmtype=DBFile');    # defaults to DBFile\n$dbh = DBI->connect('dbi:DBM:dbmmldbm=Storable');  # MLDBM with SDBMFile\n\n# or\n$dbh = DBI->connect('dbi:DBM:', undef, undef);\n$dbh = DBI->connect('dbi:DBM:', undef, undef, {\nfext              => '.db/r',\nfdir              => '/path/to/dbfiles/',\nflockfile         => '.lck',\ndbmtype           => 'BerkeleyDB',\ndbmmldbm          => 'FreezeThaw',\ndbmstoremetadata => 1,\ndbmberkeleyflags => {\n'-Cachesize' => 1000, # set a ::Hash flag\n},\n});\n\nand other variations on connect() as shown in the DBI docs, DBD::File metadata and \"Metadata\"\nshown below.\n\nUse standard DBI prepare, execute, fetch, placeholders, etc., see \"QUICK START\" for an example.\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "DBD::DBM is a database management system that works right out of the box. If you have a standard\ninstallation of Perl and DBI you can begin creating, accessing, and modifying simple database\ntables without any further modules. You can add other modules (e.g., SQL::Statement, DBFile\netc) for improved functionality.\n\nThe module uses a DBM file storage layer. DBM file storage is common on many platforms and files\ncan be created with it in many programming languages using different APIs. That means, in\naddition to creating files with DBI/SQL, you can also use DBI/SQL to access and modify files\ncreated by other DBM modules and programs and vice versa. Note that in those cases it might be\nnecessary to use a common subset of the provided features.\n\nDBM files are stored in binary format optimized for quick retrieval when using a key field. That\noptimization can be used advantageously to make DBD::DBM SQL operations that use key fields very\nfast. There are several different \"flavors\" of DBM which use different storage formats supported\nby perl modules such as SDBMFile and MLDBM. This module supports all of the flavors that perl\nsupports and, when used with MLDBM, supports tables with any number of columns and insertion of\nPerl objects into tables.\n\nDBD::DBM has been tested with the following DBM types: SDBMFile, NDBMFile, ODBMFile,\nGDBMFile, DBFile, BerkeleyDB. Each type was tested both with and without MLDBM and with the\nData::Dumper, Storable, FreezeThaw, YAML and JSON serializers using the DBI::SQL::Nano or the\nSQL::Statement engines.\n",
            "subsections": []
        },
        "QUICK START": {
            "content": "DBD::DBM operates like all other DBD drivers - it's basic syntax and operation is specified by\nDBI. If you're not familiar with DBI, you should start by reading DBI and the documents it\npoints to and then come back and read this file. If you are familiar with DBI, you already know\nmost of what you need to know to operate this module. Just jump in and create a test script\nsomething like the one shown below.\n\nYou should be aware that there are several options for the SQL engine underlying DBD::DBM, see\n\"Supported SQL syntax\". There are also many options for DBM support, see especially the section\non \"Adding multi-column support with MLDBM\".\n\nBut here's a sample to get you started.\n\nuse DBI;\nmy $dbh = DBI->connect('dbi:DBM:');\n$dbh->{RaiseError} = 1;\nfor my $sql( split /;\\n+/,\"\nCREATE TABLE user ( username TEXT, phone TEXT );\nINSERT INTO user VALUES ('Fred Bloggs','233-7777');\nINSERT INTO user VALUES ('Sanjay Patel','777-3333');\nINSERT INTO user VALUES ('Junk','xxx-xxxx');\nDELETE FROM user WHERE username = 'Junk';\nUPDATE user SET phone = '999-4444' WHERE username = 'Sanjay Patel';\nSELECT * FROM user\n\"){\nmy $sth = $dbh->prepare($sql);\n$sth->execute;\n$sth->dumpresults if $sth->{NUMOFFIELDS};\n}\n$dbh->disconnect;\n",
            "subsections": []
        },
        "USAGE": {
            "content": "This section will explain some usage cases in more detail. To get an overview about the\navailable attributes, see \"Metadata\".\n",
            "subsections": [
                {
                    "name": "Specifying Files and Directories",
                    "content": "DBD::DBM will automatically supply an appropriate file extension for the type of DBM you are\nusing. For example, if you use SDBMFile, a table called \"fruit\" will be stored in two files\ncalled \"fruit.pag\" and \"fruit.dir\". You should never specify the file extensions in your SQL\nstatements.\n\nDBD::DBM recognizes following default extensions for following types:\n\n.pag/r\nChosen for dbmtype \"SDBMFile\", \"ODBMFile\" and \"NDBMFile\" when an implementation is\ndetected which wraps \"-ldbm\" for \"NDBMFile\" (e.g. Solaris, AIX, ...).\n\nFor those types, the \".dir\" extension is recognized, too (for being deleted when dropping a\ntable).\n\n.db/r\nChosen for dbmtype \"NDBMFile\" when an implementation is detected which wraps BerkeleyDB\n1.x for \"NDBMFile\" (typically BSD's, Darwin).\n\n\"GDBMFile\", \"DBFile\" and \"BerkeleyDB\" don't usually use a file extension.\n\nIf your DBM type uses an extension other than one of the recognized types of extensions, you\nshould set the *fext* attribute to the extension and file a bug report as described in DBI with\nthe name of the implementation and extension so we can add it to DBD::DBM. Thanks in advance for\nthat :-).\n\n$dbh = DBI->connect('dbi:DBM:fext=.db');  # .db extension is used\n$dbh = DBI->connect('dbi:DBM:fext=');     # no extension is used\n\n# or\n$dbh->{fext}='.db';                       # global setting\n$dbh->{fmeta}->{'qux'}->{fext}='.db';    # setting for table 'qux'\n\nBy default files are assumed to be in the current working directory. To use other directories\nspecify the *fdir* attribute in either the connect string or by setting the database handle\nattribute.\n\nFor example, this will look for the file /foo/bar/fruit (or /foo/bar/fruit.pag for DBM types\nthat use that extension)\n\nmy $dbh = DBI->connect('dbi:DBM:fdir=/foo/bar');\n# and this will too:\nmy $dbh = DBI->connect('dbi:DBM:');\n$dbh->{fdir} = '/foo/bar';\n# but this is recommended\nmy $dbh = DBI->connect('dbi:DBM:', undef, undef, { fdir => '/foo/bar' } );\n\n# now you can do\nmy $ary = $dbh->selectallarrayref(q{ SELECT x FROM fruit });\n\nYou can also use delimited identifiers to specify paths directly in SQL statements. This looks\nin the same place as the two examples above but without setting *fdir*:\n\nmy $dbh = DBI->connect('dbi:DBM:');\nmy $ary = $dbh->selectallarrayref(q{\nSELECT x FROM \"/foo/bar/fruit\"\n});\n\nYou can also tell DBD::DBM to use a specified path for a specific table:\n\n$dbh->{dbmtables}->{f}->{file} = q(/foo/bar/fruit);\n\nPlease be aware that you cannot specify this during connection.\n\nIf you have SQL::Statement installed, you can use table aliases:\n\nmy $dbh = DBI->connect('dbi:DBM:');\nmy $ary = $dbh->selectallarrayref(q{\nSELECT f.x FROM \"/foo/bar/fruit\" AS f\n});\n\nSee the \"GOTCHAS AND WARNINGS\" for using DROP on tables.\n\nTable locking and flock()\nTable locking is accomplished using a lockfile which has the same basename as the table's file\nbut with the file extension '.lck' (or a lockfile extension that you supply, see below). This\nlock file is created with the table during a CREATE and removed during a DROP. Every time the\ntable itself is opened, the lockfile is flocked(). For SELECT, this is a shared lock. For all\nother operations, it is an exclusive lock (except when you specify something different using the\n*flock* attribute).\n\nSince the locking depends on flock(), it only works on operating systems that support flock().\nIn cases where flock() is not implemented, DBD::DBM will simply behave as if the flock() had\noccurred although no actual locking will happen. Read the documentation for flock() for more\ninformation.\n\nEven on those systems that do support flock(), locking is only advisory - as is always the case\nwith flock(). This means that if another program tries to access the table file while DBD::DBM\nhas the table locked, that other program will *succeed* at opening unless it is also using flock\non the '.lck' file. As a result DBD::DBM's locking only really applies to other programs using\nDBD::DBM or other program written to cooperate with DBD::DBM locking.\n"
                },
                {
                    "name": "Specifying the DBM type",
                    "content": "Each \"flavor\" of DBM stores its files in a different format and has different capabilities and\nlimitations. See AnyDBMFile for a comparison of DBM types.\n\nBy default, DBD::DBM uses the \"SDBMFile\" type of storage since \"SDBMFile\" comes with Perl\nitself. If you have other types of DBM storage available, you can use any of them with DBD::DBM.\nIt is strongly recommended to use at least \"DBFile\", because \"SDBMFile\" has quirks and\nlimitations and \"ODBMfile\", \"NDBMFile\" and \"GDBMFile\" are not always available.\n\nYou can specify the DBM type using the *dbmtype* attribute which can be set in the connection\nstring or with \"$dbh->{dbmtype}\" and \"$dbh->{fmeta}->{$tablename}->{type}\" for per-table\nsettings in cases where a single script is accessing more than one kind of DBM file.\n\nIn the connection string, just set \"dbmtype=TYPENAME\" where \"TYPENAME\" is any DBM type such as\nGDBMFile, DBFile, etc. Do *not* use MLDBM as your *dbmtype* as that is set differently, see\nbelow.\n\nmy $dbh=DBI->connect('dbi:DBM:');                # uses the default SDBMFile\nmy $dbh=DBI->connect('dbi:DBM:dbmtype=GDBMFile'); # uses the GDBMFile\n\n# You can also use $dbh->{dbmtype} to set the DBM type for the connection:\n$dbh->{dbmtype} = 'DBFile';    # set the global DBM type\nprint $dbh->{dbmtype};          # display the global DBM type\n\nIf you have several tables in your script that use different DBM types, you can use the\n$dbh->{dbmtables} hash to store different settings for the various tables. You can even use\nthis to perform joins on files that have completely different storage mechanisms.\n\n# sets global default of GDBMFile\nmy $dbh->('dbi:DBM:type=GDBMFile');\n\n# overrides the global setting, but only for the tables called\n# I<foo> and I<bar>\nmy $dbh->{fmeta}->{foo}->{dbmtype} = 'DBFile';\nmy $dbh->{fmeta}->{bar}->{dbmtype} = 'BerkeleyDB';\n\n# prints the dbmtype for the table \"foo\"\nprint $dbh->{fmeta}->{foo}->{dbmtype};\n\nNote that you must change the *dbmtype* of a table before you access it for first time.\n"
                },
                {
                    "name": "Adding multi-column support with MLDBM",
                    "content": "Most of the DBM types only support two columns and even if it would support more, DBD::DBM would\nonly use two. However a CPAN module called MLDBM overcomes this limitation by allowing more than\ntwo columns. MLDBM does this by serializing the data - basically it puts a reference to an array\ninto the second column. It can also put almost any kind of Perl object or even Perl coderefs\ninto columns.\n\nIf you want more than two columns, you must install MLDBM. It's available for many platforms and\nis easy to install.\n\nMLDBM is by default distributed with three serializers - Data::Dumper, Storable, and FreezeThaw.\nData::Dumper is the default and Storable is the fastest. MLDBM can also make use of user-defined\nserialization methods or other serialization modules (e.g. YAML::MLDBM or\nMLDBM::Serializer::JSON. You select the serializer using the *dbmmldbm* attribute.\n\nSome examples:\n\n$dbh=DBI->connect('dbi:DBM:dbmmldbm=Storable');  # use MLDBM with Storable\n$dbh=DBI->connect(\n'dbi:DBM:dbmmldbm=MySerializer' # use MLDBM with a user defined module\n);\n$dbh=DBI->connect('dbi::dbm:', undef,\nundef, { dbmmldbm => 'YAML' }); # use 3rd party serializer\n$dbh->{dbmmldbm} = 'YAML'; # same as above\nprint $dbh->{dbmmldbm} # show the MLDBM serializer\n$dbh->{fmeta}->{foo}->{dbmmldbm}='Data::Dumper';   # set Data::Dumper for table \"foo\"\nprint $dbh->{fmeta}->{foo}->{mldbm}; # show serializer for table \"foo\"\n\nMLDBM works on top of other DBM modules so you can also set a DBM type along with setting\ndbmmldbm. The examples above would default to using SDBMFile with MLDBM. If you wanted\nGDBMFile instead, here's how:\n\n# uses DBFile with MLDBM and Storable\n$dbh = DBI->connect('dbi:DBM:', undef, undef, {\ndbmtype  => 'DBFile',\ndbmmldbm => 'Storable',\n});\n\nSDBMFile, the default *dbmtype* is quite limited, so if you are going to use MLDBM, you should\nprobably use a different type, see AnyDBMFile.\n\nSee below for some \"GOTCHAS AND WARNINGS\" about MLDBM.\n"
                },
                {
                    "name": "Support for Berkeley DB",
                    "content": "The Berkeley DB storage type is supported through two different Perl modules - DBFile (which\nsupports only features in old versions of Berkeley DB) and BerkeleyDB (which supports all\nversions). DBD::DBM supports specifying either \"DBFile\" or \"BerkeleyDB\" as a *dbmtype*, with\nor without MLDBM support.\n\nThe \"BerkeleyDB\" dbmtype is experimental and it's interface is likely to change. It currently\ndefaults to BerkeleyDB::Hash and does not currently support ::Btree or ::Recno.\n\nWith BerkeleyDB, you can specify initialization flags by setting them in your script like this:\n\nuse BerkeleyDB;\nmy $env = new BerkeleyDB::Env -Home => $dir;  # and/or other Env flags\n$dbh = DBI->connect('dbi:DBM:', undef, undef, {\ndbmtype  => 'BerkeleyDB',\ndbmmldbm => 'Storable',\ndbmberkeleyflags => {\n'DBCREATE'  => DBCREATE,  # pass in constants\n'DBRDONLY'  => DBRDONLY,  # pass in constants\n'-Cachesize' => 1000,       # set a ::Hash flag\n'-Env'       => $env,       # pass in an environment\n},\n});\n\nDo *not* set the -Flags or -Filename flags as those are determined and overwritten by the SQL\n(e.g. -Flags => DBRDONLY is set automatically when you issue a SELECT statement).\n\nTime has not permitted us to provide support in this release of DBD::DBM for further Berkeley DB\nfeatures such as transactions, concurrency, locking, etc. We will be working on these in the\nfuture and would value suggestions, patches, etc.\n\nSee DBFile and BerkeleyDB for further details.\n"
                },
                {
                    "name": "Optimizing the use of key fields",
                    "content": "Most \"flavors\" of DBM have only two physical columns (but can contain multiple logical columns\nas explained above in \"Adding multi-column support with MLDBM\"). They work similarly to a Perl\nhash with the first column serving as the key. Like a Perl hash, DBM files permit you to do\nquick lookups by specifying the key and thus avoid looping through all records (supported by\nDBI::SQL::Nano only). Also like a Perl hash, the keys must be unique. It is impossible to create\ntwo records with the same key. To put this more simply and in SQL terms, the key column\nfunctions as the *PRIMARY KEY* or UNIQUE INDEX.\n\nIn DBD::DBM, you can take advantage of the speed of keyed lookups by using DBI::SQL::Nano and a\nWHERE clause with a single equal comparison on the key field. For example, the following SQL\nstatements are optimized for keyed lookup:\n\nCREATE TABLE user ( username TEXT, phone TEXT);\nINSERT INTO user VALUES ('Fred Bloggs','233-7777');\n# ... many more inserts\nSELECT phone FROM user WHERE username='Fred Bloggs';\n\nThe \"username\" column is the key column since it is the first column. The SELECT statement uses\nthe key column in a single equal comparison - \"username='Fred Bloggs'\" - so the search will\nfind it very quickly without having to loop through all the names which were inserted into the\ntable.\n\nIn contrast, these searches on the same table are not optimized:\n\n1. SELECT phone FROM user WHERE username < 'Fred';\n2. SELECT username FROM user WHERE phone = '233-7777';\n\nIn #1, the operation uses a less-than (<) comparison rather than an equals comparison, so it\nwill not be optimized for key searching. In #2, the key field \"username\" is not specified in\nthe WHERE clause, and therefore the search will need to loop through all rows to find the\nrequested row(s).\n\nNote that the underlying DBM storage needs to loop over all *key/value* pairs when the optimized\nfetch is used. SQL::Statement has a massively improved where clause evaluation which costs\naround 15% of the evaluation in DBI::SQL::Nano - combined with the loop in the DBM storage the\nspeed improvement isn't so impressive.\n\nEven if lookups are faster by around 50%, DBI::SQL::Nano and SQL::Statement can benefit from the\nkey field optimizations on updating and deleting rows - and here the improved where clause\nevaluation of SQL::Statement might beat DBI::SQL::Nano every time the where clause contains not\nonly the key field (or more than one).\n"
                },
                {
                    "name": "Supported SQL syntax",
                    "content": "DBD::DBM uses a subset of SQL. The robustness of that subset depends on what other modules you\nhave installed. Both options support basic SQL operations including CREATE TABLE, DROP TABLE,\nINSERT, DELETE, UPDATE, and SELECT.\n\nOption #1: By default, this module inherits its SQL support from DBI::SQL::Nano that comes with\nDBI. Nano is, as its name implies, a *very* small SQL engine. Although limited in scope, it is\nfaster than option #2 for some operations (especially single *primary key* lookups). See\nDBI::SQL::Nano for a description of the SQL it supports and comparisons of it with option #2.\n\nOption #2: If you install the pure Perl CPAN module SQL::Statement, DBD::DBM will use it instead\nof Nano. This adds support for table aliases, functions, joins, and much more. If you're going\nto use DBD::DBM for anything other than very simple tables and queries, you should install\nSQL::Statement. You don't have to change DBD::DBM or your scripts in any way, simply installing\nSQL::Statement will give you the more robust SQL capabilities without breaking scripts written\nfor DBI::SQL::Nano. See SQL::Statement for a description of the SQL it supports.\n\nTo find out which SQL module is working in a given script, you can use the dbmversions() method\nor, if you don't need the full output and version numbers, just do this:\n\nprint $dbh->{sqlhandler}, \"\\n\";\n\nThat will print out either \"SQL::Statement\" or \"DBI::SQL::Nano\".\n\nBaring the section about optimized access to the DBM storage in mind, comparing the benefits of\nboth engines:\n\n# DBI::SQL::Nano is faster\n$sth = $dbh->prepare( \"update foo set value='new' where key=15\" );\n$sth->execute();\n$sth = $dbh->prepare( \"delete from foo where key=27\" );\n$sth->execute();\n$sth = $dbh->prepare( \"select * from foo where key='abc'\" );\n\n# SQL::Statement might faster (depending on DB size)\n$sth = $dbh->prepare( \"update foo set value='new' where key=?\" );\n$sth->execute(15);\n$sth = $dbh->prepare( \"update foo set value=? where key=15\" );\n$sth->execute('new');\n$sth = $dbh->prepare( \"delete from foo where key=?\" );\n$sth->execute(27);\n\n# SQL::Statement is faster\n$sth = $dbh->prepare( \"update foo set value='new' where value='old'\" );\n$sth->execute();\n# must be expressed using \"where key = 15 or key = 27 or key = 42 or key = 'abc'\"\n# in DBI::SQL::Nano\n$sth = $dbh->prepare( \"delete from foo where key in (15,27,42,'abc')\" );\n$sth->execute();\n# must be expressed using \"where key > 10 and key < 90\" in DBI::SQL::Nano\n$sth = $dbh->prepare( \"select * from foo where key between (10,90)\" );\n$sth->execute();\n\n# only SQL::Statement can handle\n$sth->prepare( \"select * from foo,bar where foo.name = bar.name\" );\n$sth->execute();\n$sth->prepare( \"insert into foo values ( 1, 'foo' ), ( 2, 'bar' )\" );\n$sth->execute();\n"
                },
                {
                    "name": "Specifying Column Names",
                    "content": "DBM files don't have a standard way to store column names. DBD::DBM gets around this issue with\na DBD::DBM specific way of storing the column names. If you are working only with DBD::DBM and\nnot using files created by or accessed with other DBM programs, you can ignore this section.\n\nDBD::DBM stores column names as a row in the file with the key *metadata \\0*. So this code\n\nmy $dbh = DBI->connect('dbi:DBM:');\n$dbh->do(\"CREATE TABLE baz (foo CHAR(10), bar INTEGER)\");\n$dbh->do(\"INSERT INTO baz (foo,bar) VALUES ('zippy',1)\");\n\nWill create a file that has a structure something like this:\n\nmetadata \\0 | <dbdmetadata><schema></schema><colnames>foo,bar</colnames></dbdmetadata>\nzippy        | 1\n\nThe next time you access this table with DBD::DBM, it will treat the *metadata \\0* row as a\nheader rather than as data and will pull the column names from there. However, if you access the\nfile with something other than DBD::DBM, the row will be treated as a regular data row.\n\nIf you do not want the column names stored as a data row in the table you can set the\n*dbmstoremetadata* attribute to 0.\n\nmy $dbh = DBI->connect('dbi:DBM:', undef, undef, { dbmstoremetadata => 0 });\n\n# or\n$dbh->{dbmstoremetadata} = 0;\n\n# or for per-table setting\n$dbh->{fmeta}->{qux}->{dbmstoremetadata} = 0;\n\nBy default, DBD::DBM assumes that you have two columns named \"k\" and \"v\" (short for \"key\" and\n\"value\"). So if you have *dbmstoremetadata* set to 1 and you want to use alternate column\nnames, you need to specify the column names like this:\n\nmy $dbh = DBI->connect('dbi:DBM:', undef, undef, {\ndbmstoremetadata => 0,\ndbmcols => [ qw(foo bar) ],\n});\n\n# or\n$dbh->{dbmstoremetadata} = 0;\n$dbh->{dbmcols}           = 'foo,bar';\n\n# or to set the column names on per-table basis, do this:\n# sets the column names only for table \"qux\"\n$dbh->{fmeta}->{qux}->{dbmstoremetadata} = 0;\n$dbh->{fmeta}->{qux}->{colnames}          = [qw(foo bar)];\n\nIf you have a file that was created by another DBM program or created with *dbmstoremetadata*\nset to zero and you want to convert it to using DBD::DBM's column name storage, just use one of\nthe methods above to name the columns but *without* specifying *dbmstoremetadata* as zero. You\nonly have to do that once - thereafter you can get by without setting either\n*dbmstoremetadata* or setting *dbmcols* because the names will be stored in the file.\n\nDBI database handle attributes"
                },
                {
                    "name": "Metadata",
                    "content": "Statement handle ($sth) attributes and methods\nMost statement handle attributes such as NAME, NUMOFFIELDS, etc. are available only after an\nexecute. The same is true of $sth->rows which is available after the execute but does *not*\nrequire a fetch.\n\nDriver handle ($dbh) attributes\nIt is not supported anymore to use dbm-attributes without the dbm-prefix. Currently, if an\nDBD::DBM private attribute is accessed without an underscore in it's name, dbm is prepended to\nthat attribute and it's processed further. If the resulting attribute name is invalid, an error\nis thrown.\n\ndbmcols\nContains a comma separated list of column names or an array reference to the column names.\n\ndbmtype\nContains the DBM storage type. Currently known supported type are \"ODBMFile\", \"NDBMFile\",\n\"SDBMFile\", \"GDBMFile\", \"DBFile\" and \"BerkeleyDB\". It is not recommended to use one of the\nfirst three types - even if \"SDBMFile\" is the most commonly available *dbmtype*.\n\ndbmmldbm\nContains the serializer for DBM storage (value column). Requires the CPAN module MLDBM\ninstalled. Currently known supported serializers are:\n\nData::Dumper\nDefault serializer. Deployed with Perl core.\n\nStorable\nFaster serializer. Deployed with Perl core.\n\nFreezeThaw\nPure Perl serializer, requires FreezeThaw to be installed.\n\nYAML    Portable serializer (between languages but not architectures). Requires YAML::MLDBM\ninstallation.\n\nJSON    Portable, fast serializer (between languages but not architectures). Requires\nMLDBM::Serializer::JSON installation.\n\ndbmstoremetadata\nBoolean value which determines if the metadata in DBM is stored or not.\n\ndbmberkeleyflags\nHash reference with additional flags for BerkeleyDB::Hash instantiation.\n\ndbmversion\nReadonly attribute containing the version of DBD::DBM.\n\nfmeta\nIn addition to the attributes DBD::File recognizes, DBD::DBM knows about the (public) attributes\n\"colnames\" (Note not *dbmcols* here!), \"dbmtype\", \"dbmmldbm\", \"dbmstoremetadata\" and\n\"dbmberkeleyflags\". As in DBD::File, there are undocumented, internal attributes in DBD::DBM.\nBe very careful when modifying attributes you do not know; the consequence might a destroyed or\ncorrupted table.\n\ndbmtables\nThis attribute provides restricted access to the table meta data. See fmeta and \"fmeta\" in\nDBD::File for attribute details.\n\ndbmtables is a tied hash providing the internal table names as keys (accessing unknown tables\nmight create an entry) and their meta data as another tied hash. The table meta storage is\nobtained via the \"gettablemeta\" method from the table implementation (see\nDBD::File::Developers). Attribute setting and getting within the table meta data is handled via\nthe methods \"settablemetaattr\" and \"gettablemetaattr\".\n\nFollowing attributes are no longer handled by DBD::DBM:\ndbmext\nThis attribute is silently mapped to DBD::File's attribute *fext*. Later versions of DBI might\nshow a depreciated warning when this attribute is used and eventually it will be removed.\n\ndbmlockfile\nThis attribute is silently mapped to DBD::File's attribute *flockfile*. Later versions of DBI\nmight show a depreciated warning when this attribute is used and eventually it will be removed.\n\nDBI database handle methods\nThe $dbh->dbmversions() method\nThe private method dbmversions() returns a summary of what other modules are being used at any\ngiven time. DBD::DBM can work with or without many other modules - it can use either\nSQL::Statement or DBI::SQL::Nano as its SQL engine, it can be run with DBI or DBI::PurePerl, it\ncan use many kinds of DBM modules, and many kinds of serializers when run with MLDBM. The"
                },
                {
                    "name": "dbm_versions",
                    "content": "print $dbh->dbmversions;               # displays global settings\nprint $dbh->dbmversions($tablename);  # displays per table settings\n\nAn important thing to note about this method is that when it called with no arguments, it\ndisplays the *global* settings. If you override these by setting per-table attributes, these\nwill *not* be shown unless you specify a table name as an argument to the method call.\n"
                },
                {
                    "name": "Storing Objects",
                    "content": "If you are using MLDBM, you can use DBD::DBM to take advantage of its serializing abilities to\nserialize any Perl object that MLDBM can handle. To store objects in columns, you should (but\ndon't absolutely need to) declare it as a column of type BLOB (the type is *currently* ignored\nby the SQL engine, but it's good form).\n"
                }
            ]
        },
        "EXTENSIBILITY": {
            "content": "\"SQL::Statement\"\nImproved SQL engine compared to the built-in DBI::SQL::Nano - see \"Supported SQL\nsyntax\".\n\n\"DBFile\"\nBerkeley DB version 1. This database library is available on many systems without\nadditional installation and most systems are supported.\n\n\"GDBMFile\"\nSimple dbm type (comparable to \"DBFile\") under the GNU license. Typically not available\n(or requires extra installation) on non-GNU operating systems.\n\n\"BerkeleyDB\"\nBerkeley DB version up to v4 (and maybe higher) - requires additional installation but\nis easier than GDBMFile on non-GNU systems.\n\ndb4 comes with a many tools which allow repairing and migrating databases. This is the\nrecommended dbm type for production use.\n\n\"MLDBM\" Serializer wrapper to support more than one column for the files. Comes with serializers\nusing \"Data::Dumper\", \"FreezeThaw\" and \"Storable\".\n\n\"YAML::MLDBM\"\nAdditional serializer for MLDBM. YAML is very portable between languages.\n\n\"MLDBM::Serializer::JSON\"\nAdditional serializer for MLDBM. JSON is very portable between languages, probably more\nthan YAML.\n",
            "subsections": []
        },
        "GOTCHAS AND WARNINGS": {
            "content": "Using the SQL DROP command will remove any file that has the name specified in the command with\neither '.pag' and '.dir', '.db' or your {fext} appended to it. So this be dangerous if you\naren't sure what file it refers to:\n\n$dbh->do(qq{DROP TABLE \"/path/to/any/file\"});\n\nEach DBM type has limitations. SDBMFile, for example, can only store values of less than 1,000\ncharacters. *You* as the script author must ensure that you don't exceed those bounds. If you\ntry to insert a value that is larger than DBM can store, the results will be unpredictable. See\nthe documentation for whatever DBM you are using for details.\n\nDifferent DBM implementations return records in different orders. That means that you *should\nnot* rely on the order of records unless you use an ORDER BY statement.\n\nDBM data files are platform-specific. To move them from one platform to another, you'll need to\ndo something along the lines of dumping your data to CSV on platform #1 and then dumping from\nCSV to DBM on platform #2. DBD::AnyData and DBD::CSV can help with that. There may also be DBM\nconversion tools for your platforms which would probably be quicker.\n\nWhen using MLDBM, there is a very powerful serializer - it will allow you to store Perl code or\nobjects in database columns. When these get de-serialized, they may be eval'ed - in other words\nMLDBM (or actually Data::Dumper when used by MLDBM) may take the values and try to execute them\nin Perl. Obviously, this can present dangers, so if you do not know what is in a file, be\ncareful before you access it with MLDBM turned on!\n\nSee the entire section on \"Table locking and flock()\" for gotchas and warnings about the use of",
            "subsections": [
                {
                    "name": "flock",
                    "content": ""
                }
            ]
        },
        "BUGS AND LIMITATIONS": {
            "content": "This module uses hash interfaces of two column file databases. While none of supported SQL\nengines have support for indices, the following statements really do the same (even if they mean\nsomething completely different) for each dbm type which lacks \"EXISTS\" support:\n\n$sth->do( \"insert into foo values (1, 'hello')\" );\n\n# this statement does ...\n$sth->do( \"update foo set v='world' where k=1\" );\n# ... the same as this statement\n$sth->do( \"insert into foo values (1, 'world')\" );\n\nThis is considered to be a bug and might change in a future release.\n\nKnown affected dbm types are \"ODBMFile\" and \"NDBMFile\". We highly recommended you use a more\nmodern dbm type such as \"DBFile\".\n\nGETTING HELP, MAKING SUGGESTIONS, AND REPORTING BUGS\nIf you need help installing or using DBD::DBM, please write to the DBI users mailing list at\ndbi-users@perl.org or to the comp.lang.perl.modules newsgroup on usenet. I cannot always answer\nevery question quickly but there are many on the mailing list or in the newsgroup who can.\n\nDBD developers for DBD's which rely on DBD::File or DBD::DBM or use one of them as an example\nare suggested to join the DBI developers mailing list at dbi-dev@perl.org and strongly\nencouraged to join our IRC channel at <irc://irc.perl.org/dbi>.\n\nIf you have suggestions, ideas for improvements, or bugs to report, please report a bug as\ndescribed in DBI. Do not mail any of the authors directly, you might not get an answer.\n\nWhen reporting bugs, please send the output of $dbh->dbmversions($table) for a table that\nexhibits the bug and as small a sample as you can make of the code that produces the bug. And of\ncourse, patches are welcome, too :-).\n\nIf you need enhancements quickly, you can get commercial support as described at\n<http://dbi.perl.org/support/> or you can contact Jens Rehsack at rehsack@cpan.org for\ncommercial support in Germany.\n\nPlease don't bother Jochen Wiedmann or Jeff Zucker for support - they handed over further\nmaintenance to H.Merijn Brand and Jens Rehsack.\n",
            "subsections": []
        },
        "ACKNOWLEDGEMENTS": {
            "content": "Many, many thanks to Tim Bunce for prodding me to write this, and for copious, wise, and patient\nsuggestions all along the way. (Jeff Zucker)\n\nI send my thanks and acknowledgements to H.Merijn Brand for his initial refactoring of DBD::File\nand his strong and ongoing support of SQL::Statement. Without him, the current progress would\nnever have been made. And I have to name Martin J. Evans for each laugh (and correction) of all\nthose funny word creations I (as non-native speaker) made to the documentation. And - of course\n- I have to thank all those unnamed contributors and testers from the Perl community. (Jens\nRehsack)\n",
            "subsections": []
        },
        "AUTHOR AND COPYRIGHT": {
            "content": "This module is written by Jeff Zucker < jzucker AT cpan.org >, who also maintained it till 2007.\nAfter that, in 2010, Jens Rehsack & H.Merijn Brand took over maintenance.\n\nCopyright (c) 2004 by Jeff Zucker, all rights reserved.\nCopyright (c) 2010-2013 by Jens Rehsack & H.Merijn Brand, all rights reserved.\n\nYou may freely distribute and/or modify this module under the terms of either the GNU General\nPublic License (GPL) or the Artistic License, as specified in the Perl README file.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "DBI, SQL::Statement, DBI::SQL::Nano, AnyDBMFile, DBFile, BerkeleyDB, MLDBM, YAML::MLDBM,\nMLDBM::Serializer::JSON\n",
            "subsections": []
        }
    },
    "summary": "DBD::DBM - a DBI driver for DBM & MLDBM files",
    "flags": [],
    "examples": [],
    "see_also": []
}