John, The problem was the version of SQLite included in DBD. Its way old?.
I am a sysadmin as well as developer as well as tester as well as CFO. I wear many hats in this startup :) Our conclusion is that we need to look at the architecture again to see if the web services can be speeded up. There?s no point in us shaving off 0.01 ms off SQlite if the response takes 0.1ms in the web service. 100 calls per second isn?t good enough. We?ll look at mojolicious and see how many processes we can pre-fork. Rob > On 17 Sep 2015, at 15:41, John McKown <john.archie.mckown at gmail.com> wrote: > > The latest PERL DBI for SQLite that I could see is at > http://www.cpan.org/authors/id/I/IS/ISHIGAKI/DBD-SQLite-1.48.tar.gz . I > took a look at it and it has sqlite3.c (and others) from the 3.8.10 > amalgamation in it. > > Just "for fun", I copied 3 files (sqlite3.c, sqlite3.h, and sqlite3ext.h) > from my SQLite (64abb65d4df11e5b3bcc4afc8e7c18e907c6080a 2015-08-28 > 03:48:04 UTC) source. In the DBD-SQLite-1.48 source directory, I then did: > perl Makefile.PL #create the Makefile > make #create the SQLite.so shared library > sudo make install # Install the new DBD for SQLite > > The above was on RedHat Fedora 22 x86_64. All the test ran successfully. > > If it were me, I'd download the latest SQLite almagamation & the above > mentioned DBD-SQLite. Copy the 3 files I mentioned from the amalgamation > source to the DBD-SQLite-1.48 directory, then re-install DBD-SQLite as I > did. But, of course, this will likely need to go though whatever change > control procedures that Rob's installation has. Hum, I guess that I assumed > that Rob is a sysadmin on this system. So maybe he will really to push an > update request through channels to get DBD-SQLite updated. > > > On Thu, Sep 17, 2015 at 9:00 AM, Simon Slavin <slavins at bigfraud.org> wrote: > >> >>> On 17 Sep 2015, at 2:47pm, Rob Willett <rob.sqlite at robertwillett.com> >> wrote: >>> >>> 3. We cannot get WITHOUT ROWID working using Perl DBI. We get the >> following error >>> >>> DBD::SQLite::db prepare failed: malformed database schema (postcode) - >> near ?WITHOUT" >>> >>> This appears to be due to mismatched SQLite version but we are running >>> >>> macpro:postcode rwillett$ sqlite3 --version >>> 3.8.5 2014-08-15 22:37:57 c8ade949d4a2eb3bba4702a4a0e17b405e9b6ace >>> >>> The SQLite web page on WITHOUT ROWID indicates we need 3.8.2 or higher >> so we?re confused as to what the problem is. >> >> SQLite is not 'installed in your system'. It is compiled separately into >> each program which uses it. The version number returned by the >> command-line tool (sqlite3) is the version of SQLite that is compiled into >> the command-line tool. >> >> Your version of Perl will have a different version of SQLite compiled into >> it. To find out which version that is, I think you can do this: >> >> $dbh->{sqlite_version}; >> >> assuming $dbh is your handle to a SQLite connection. >> >> Simon. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > > > > -- > > Schrodinger's backup: The condition of any backup is unknown until a > restore is attempted. > > Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. > > He's about as useful as a wax frying pan. > > 10 to the 12th power microphones = 1 Megaphone > > Maranatha! <>< > John McKown > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
