> 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 sta
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:
> >
> > http://www.sqlite.org/cvstrac/fileview?f=sqlite
> 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&v=1.6
Nice. Limit is much better than a crash. But I h
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, the
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 number
> 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 mos
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 there's a known workaround, so no problem.
Workaround is not a solution.
>
> > > hence your problem.
> >
> > Sure it is. J
--- [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 pro
On 05 Jun 2007 16:40:32 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Joe Wilson napisał(a):
> At least there's 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 impleme
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.
>
> > > hence your problem.
> >
> > Sure it is. Just like any bug or missing feat
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
rs@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 t
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 wer
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 confus
--- [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 java'
ou sure it is sqlite that used the stack and not the jdbc driver
(or your application)?
What happens if you run that query from the sqlite shell?
The reason I ask is because I used sqlite on WinCE (but not currently)
and only 1 time I had problem with stack usage (a version that made
sqlite use the sta
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 java's stack limit is low, but it wasn't hard
18 matches
Mail list logo
