On Fri, Aug 03, 2007 at 11:38:57AM -0700, Joe Wilson wrote:
> > Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it
>
> :-)
>
> "Of course"? That's rich.
"Of course" - just because I haven't any possibility to do that.
> > OK, I'll try to ask maintainers about that.
>
>
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 03, 2007 at 09:27:22AM -0700, Joe Wilson wrote:
>
> > You are not checking the return code of the sqlite3 connection close.
>
> Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it
:-)
"Of course"? That's rich.
On Fri, Aug 03, 2007 at 09:27:22AM -0700, Joe Wilson wrote:
> You are not checking the return code of the sqlite3 connection close.
Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it
doesn't return any value when using sqlite_close.
> I have no idea if the PHP sqlite3 wrapper
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> > Your trace seems to indicate it has 20 or so open
> > connections to the same database file in the same process.
>
> I think, at last I've traced the problem:
>
> One of the scripts doesn't make use out of database contents at all. But at
>
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 01, 2007 at 03:04:35PM -0700, Joe Wilson wrote:
>
> > Maybe the php wrapper is not closing sqlite connections correctly
> > (or at all).
> >
> > See if you can get the stack traces of all threads in the php process
> > 162 via
On Wed, Aug 01, 2007 at 03:04:35PM -0700, Joe Wilson wrote:
> Maybe the php wrapper is not closing sqlite connections correctly
> (or at all).
>
> See if you can get the stack traces of all threads in the php process
> 162 via pstack, lsstack or by attaching gdb to it at runtime.
Before I'll
Maybe the php wrapper is not closing sqlite connections correctly
(or at all).
See if you can get the stack traces of all threads in the php process
162 via pstack, lsstack or by attaching gdb to it at runtime.
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> php
On Thu, Jul 26, 2007 at 04:26:41PM -0700, [EMAIL PROTECTED] wrote:
> If it works and then later stops working, it's much more likely that
> you're having a problem with some file descriptor that is not closed
> properly (on the temp db most likely).
> If it dies after let's say a week, you can
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> Starting from 101st it just keeps reporting "malformed..." error everytime,
> when one tries to access the database using any of PHP-scripts. Until I
> "manually" restart lighttpd server.
I have no idea about the architecture of lighttpd and its
On Thu, Jul 26, 2007 at 05:29:15PM -0700, Joe Wilson wrote:
> What happens on the 102nd time?
Starting from 101st it just keeps reporting "malformed..." error everytime,
when one tries to access the database using any of PHP-scripts. Until I
"manually" restart lighttpd server.
> If it fails,
On Thu, Jul 26, 2007 at 04:26:41PM -0700, [EMAIL PROTECTED] wrote:
> If it works and then later stops working, it's much more likely that
> you're having a problem with some file descriptor that is not closed
> properly (on the temp db most likely).
> If it dies after let's say a week, you can
-- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> The problem is, that the error message actually gives not any clue. It just
> tells, that "there was problem while truing to open temporary database file"
> - but there (considering the above) shouldn't be any problem. /var/tmp has
> rwxrwxrwx
>
> - Original Message
> From: Zbigniew Baniewski <[EMAIL PROTECTED]>
> To: sqlite-users@sqlite.org
> Sent: Thursday, July 26, 2007 4:12:00 PM
> Subject: Re: [sqlite] Problem with SQLite FastCGI module "malformed database
> schema"
>
>
>
On Thu, Jul 26, 2007 at 12:59:45PM -0700, Joe Wilson wrote:
> /var on my machine is drwxr-xr-x, and I don't have any issues with sqlite
> reading and writing temp files to /var/tmp/. Even if the permissions of /var
> were d--x--x--x, it would also be fine. As long as /var/tmp is rwx for
> the
On Thu, Jul 26, 2007 at 08:11:22AM -0700, Joe Wilson wrote:
> Try
>
> PRAGMA temp_store_directory = 'directory-name';
>
> Otherwise, the temp file location order for UNIX is:
>
> "/var/tmp",
> "/usr/tmp",
> "/tmp",
> ".",
Thanks, I'll try to. Although is rather temporar
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
>
> While using SQLite as FastCGI module from within PHP-scripts, sometimes I'm
> getting error messages, like:
>
> (mod_fastcgi.c.2551) FastCGI-stderr: PHP Warning:
> sqlite_open() [function.sqlite-open
> malformed database schema - unable to
While using SQLite as FastCGI module from within PHP-scripts, sometimes I'm
getting error messages, like:
(mod_fastcgi.c.2551) FastCGI-stderr: PHP Warning:
sqlite_open() [function.sqlite-open
malformed database schema - unable to open a temporary database file
for storing temporary tables in
17 matches
Mail list logo
