All fair points - although I don't see any problems with race conditions (which was what had me nervous :-)

Running it without creating the tables first generates the following error ...

Did you run the extended tests on install?

DBIx::Sequence uses 2 tables for its operation, namely the dbix_sequence_state and the dbix_sequence_release tables. Those tables will be created if you run extended tests, if not you will need to create them yourself.

(from the docs)

Creating the tables manually and running a basic loop to get new IDs generates the following error ... The reason for this is that this module doesn't properly fetch all results after executing queries - and this leaves the various statement handles that it creates in an unstable state when used with DBD::Sybase.

That's interesting - I didn't know that you have to retrive all results from a statement handle in DBI. Is this a general thing, or just an issue (bug?) for the Sybase DBD? (I suddenly feel nervous about some of the code I've written to handle paged results.)

Might be nice to submit your Sybase patches to the DBIx::Sequence author.

After patching the code so that it will work with Sybase I ran three concurrent processes that did nothing but fetch new IDs. The result was that only one process actually got any IDs - the other two were effectively locked out. Admittedly this is an extreme use of the module, but it does show the limits that this technique can have.

True. However if you're being forced to write code for a DB without decent transaction support you don't have much choice (and, as you say, it is a somewhat extreme example that wouldn't be common outside of data-loading)

That said, you are completely correct that the best way to do it is with transactions if you have them.