> Change the 5000 to 5 and it crashes here on linux too.
I guess your compiler's default stack limit is big. I tested real query on
linux too and it crashed really fast. But satck size was limited by default
java's value, not gcc's limit.
> Maybe
> we need to limit the number of SELECT
On Wed, 2007-06-06 at 13:38 +0200, [EMAIL PROTECTED] wrote:
> > There have been some recent changes to try to address this
> > by placing various limits on number of columns, length of
> > SQL expressions, length of SQL statements etc. See:
> >
> >
> There have been some recent changes to try to address this
> by placing various limits on number of columns, length of
> SQL expressions, length of SQL statements etc. See:
>
> http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/limits.h=1.6
Nice. Limit is much better than a crash. But I
On Tue, 2007-06-05 at 13:35 +0200, [EMAIL PROTECTED] wrote:
> I'v read in change log that some stack allocted memory were moved to the
> heap, but I think that there is still to much allocated memory on the stack.
> After creating a table with 2000 columns, jdbc driver created a query that
> run
--- [EMAIL PROTECTED] wrote:
> My application's doesn't create any databases itself. It allows users to
> store any data. And users need to be able to store any number of columns in
> 1 table (the most I'v heard about is about 1, but I wouldn't be
> surprised if they had more). Trust me,
At 20:31 05/06/2007, you wrote:
> Excuse me for make this question but have you
> normalized your database? Try to design/define it in at least 3NormalForm.
My application's doesn't create any databases itself. It allows users to
store any data. And users need to be able to store any
> Excuse me for make this question but have you
> normalized your database? Try to design/define it in at least 3NormalForm.
My application's doesn't create any databases itself. It allows users to
store any data. And users need to be able to store any number of columns in
1 table (the
At 16:40 05/06/2007, you wrote:
Joe Wilson napisa³(a):
> Please respond to the mailing list in the future.
Sorry. Different client. I didn't notice the adress.
> At least theres a known workaround, so no problem.
Workaround is not a solution.
>
> > > hence your problem.
> >
> > Sure it is.
--- [EMAIL PROTECTED] wrote:
> Joe Wilson napisa³(a):
> > Please respond to the mailing list in the future.
>
> Sorry. Different client. I didn't notice the adress.
>
> > At least there's a known workaround, so no problem.
>
> Workaround is not a solution.
Increasing the stack will fix your
On 05 Jun 2007 16:40:32 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Joe Wilson napisał(a):
> At least theres a known workaround, so no problem.
Workaround is not a solution.
For an embedded (and lite) SQL engine like SQLite, you have to bear in
mind some features will never be
Joe Wilson napisał(a):
> Please respond to the mailing list in the future.
Sorry. Different client. I didn't notice the adress.
> At least theres a known workaround, so no problem.
Workaround is not a solution.
>
> > > hence your problem.
> >
> > Sure it is. Just like any bug or missing
Such a statement would never be issued on a low memory device.
This is an exceptional case involving a select with 2000
unions - I would not worry about it.
--- [EMAIL PROTECTED] wrote:
> This is very worrying since it means that the statement cannot be compiled on
> a
> low memory device.
> I
s@sqlite.org
To: sqlite-users@sqlite.org
cc:(bcc: clive/Emultek)
Subject: Re: [sqlite] Stack usage
--- [EMAIL PROTECTED] wrote:
> I'v read in change log that some stack allocted memory were moved to the
heap,
but I think that
> there is still to much allocated memory on the stack
Joe Wilson <[EMAIL PROTECTED]> on 05/06/2007 14:33:42
Please respond to sqlite-users@sqlite.org
To: sqlite-users@sqlite.org
cc:(bcc: clive/Emultek)
Subject: Re: [sqlite] Stack usage
--- [EMAIL PROTECTED] wrote:
> I'v read in change log that some stack allocted memory w
On 05 Jun 2007 14:59:40 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Are you sure it is sqlite that used the stack and not the jdbc driver
> (or your application)?
yes
> What happens if you run that query from the sqlite shell?
That query I pasted works. Bigger doesn't.
Ok, I
--- [EMAIL PROTECTED] wrote:
> I'v read in change log that some stack allocted memory were moved to the
> heap, but I think that
> there is still to much allocated memory on the stack.
> After creating a table with 2000 columns, jdbc driver created a query that
> run out of stack.
> Default
On 05 Jun 2007 13:35:33 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
I'v read in change log that some stack allocted memory were moved to the heap,
but I think that there is still to much allocated memory on the stack.
After creating a table with 2000 columns, jdbc driver created a query
17 matches
Mail list logo
