Although usually helpful, this advice only applies to pure-Perl modules; the DBD::SQLite distribution includes the C source code for the SQLite database library, and thus must be compiled on the target machine (or a very close equivalent).

Please, if you suggest simplicistic solutions, also make sure that they apply. DBD::SQLite is a module with an XS part and that means that additional files need to be transferred, and, most important, the compiler and architecture used to compile the XS portion of the module must match the compiler and architecture that the webserver uses for its Perl. If they don't match, copying the files will not achieve anything at all.

Understood and agreed, but since there's a 95+% chance that the server is either win32 or linux, I'd still go for it. IMO, it would be much more profitable to spend a little time getting SQLite to work than it would to spend the time re-coding its capabilities.

You make a good case, but I'd (obviously) try my way before giving up a real database for something lesser. (But that's just me.)

Hmmm....

Like you say I think it is a Linux box and I'd be tempted to try it if it was my own box, however its a ISP box and I suspect they might not like it. (what are the percentage chances of trying it killing the server?)

DBD::AnyData alows me to write my code using SQL statements so if (or when) I manage to get SQLite access or perhaps MySQL transitioning will hopefully be fairly simple. (Just changing the handler calls?)

At this stage it is just a prototype application I am writing so, performance is not a big issue. I would be interested in others opinions of the "just try it" idea.

Lance

Kia Kaha, Kia Toa, Kia Manawanui!
Be Strong, Be Brave, Be perservering!