silverbullet:

As is often the case, the answer depends on the problem you're trying to solve. What difficulties are you having with flat files? You mention random access and record locking, so it may be that using a database back end might be the answer. Then again, as MidLifeXis suggests, DBM::Deep might ease your pain.

Of course, XML might be good, so you might find something like MongoDB to be better.

Different problems require different solutions ... there is no silverbullet..

(Yes, the entire post was just for that punchline....)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Thank you for your reply. I will look into the DBM::Deep. Thanks for the help.

"Seem to" dominate? The very meaning of the name of Perl suggests it would be predominately focused on sequential text files.

That said, and DBM::Deep already mentioned, if you want to spin your own module to support what we in the dinosaur days would have called Fixed-Length Random Access File processes, you could look into the following features of Perl:

Input and output functions:

• binmode
• read
• seek
• sysread
• sysseek
• syswrite
• tell
• write

Modern data processing (is that an oxymoron?) thinks more in terms of XML and DB for re-usable, rewriteable data; but if you must play in the old fashioned fixed-length random-access file space, the above tools will readily permit migration of your old C code where you last reinvented that wheel to Perl where you seem fixated on this somewhat dated approach to data storage.

:-)

All that having been said, I myself could not resist the urge to port my old FLRAF routines to Perl when I first got here. I never bothered to write a module I would dare to put in front of other software engineers, however, since I knew going into the effort it was an exercise to produce a tool I was unlikely to ever need.

DBI/SQLite has been a good friend:

use DBI;

my $dbargs = 
{
    AutoCommit => 0,
    PrintError => 1
};

my $dbscns = "dbi:SQLite:dbname=$Db_dbn";
&debug::debug("\$dbscns = '$dbscns\n");

my $dbshan = DBI->connect($dbscns,"","",$dbargs);
&debug::debug("\$dbshan = '$dbshan'\n");
[download]

I appreciate your suggestions and perspective. Thank you.

DBM::Deep?

Thank you for your suggestion. I will look into it.

I have had a lot of success with SQLite, which is (by careful and deliberate design ...) a public-domain SQL system which stores everything in one file and requires no server.   The very nice thing about it is that, well, “it’s a [self-describing(!)] random-access file,” and a whale of a lot more.   All wrapped-up in a very small, high-performance engine that runs everywhere and with every language (not just Perl).   Quite frankly, I don’t “roll my own random-access files” anymore.   I can’t justify the effort, nor the bugs that I can avoid.

There is only one caveat, but it is an important one:   use transactions.   SQLite is also designed for fail-safe situations, so it will re-read everything that it has just written, quite by-design, unless you are using transactions, which allows more-“lazy” writes.   But, hey, you get “a self-describing multi-user random-access file that is understandable everywhere,” with transactions!   Not bad.   Not bad at all.

Thank you for the suggestion.