You could just create a new one there. What do you suppose is the problem? Did you transfer the file in ASCII mode when it should have been in binary mode, or vice versa?

I've never tinkered with the portability across OS's of the file that SQLite uses to store its data. But I think SQLite does support block inserts, so you could write a script that just exports all the data into an ASCII file, and then another one to import it into SQLite at the other end of the line.

I've never tinkered with the portability across OS's of the file that SQLite uses to store its data.

I've always heard that SQLite files are cross-platform compatible, it's only cross-SQLite-version compatibility that is an issue. dhoss should try to figure out the SQLite versions the DBD's are built against, or that his SQLite browsing program is built against. If they don't match, that will quite likely be the problem. (Unless, like you said, he botched the upload. Which I doubt.)

p.s. I looked if I could find some official docs on file compatibility, and I found this on The SQLite introduction page:

Database files can be freely shared between machines with different byte orders.

I'm not sure actually. I think I'll probably just create a new DB via SSH. I could tinker around with it and see if I could get the existing one to work, but I'd rather set it up so that there's a setup method run if no DB file exists, much like you said.

So where do I find out what format the SQLite db needs to be in in order for me to export my data into a new database?

meh.

If I recall, the POD for DBD::SQLite lists resources for additional reading specific to the SQLite database. SQLite isn't Perl-only. It just happens that someone's gone to the work of creating a Perl module that enwraps SQLite. That means there is more support out there for SQLite than if it were a Perl-only entity. When I was looking into it a year or so ago I'm fairly certain that the module's POD points you toward the SQLite-specific documentation.




Dave