Ashok wrote:
Hi All,
Have to come across any such issues?
Most experienced developers have come across such issues. As Richard
suggested, you are likely seeing the effect of a heap corruption that is
occurring somewhat earlier than the "crashing" which finally reveals a
problem. His
Hi All,
Have to come across any such issues?
Regards,
Ashok
On Tue, Aug 20, 2013 at 7:59 PM, Ashok Pitambar wrote:
> Hi Dan,
>
> Yes you are right , I think in my case pBuf has corrupted memory and while
> trying to access this it
> is crashing.
>
> Regards,
> Ashok
>
Hi Dan,
Yes you are right , I think in my case pBuf has corrupted memory and while
trying to access this it
is crashing.
Regards,
Ashok
On Tue, Aug 20, 2013 at 7:47 PM, Dan Kennedy wrote:
> On 08/20/2013 09:08 PM, Ashok Pitambar wrote:
>
>> Hi Richard,
>>
>>
On 08/20/2013 09:08 PM, Ashok Pitambar wrote:
Hi Richard,
If list of available buffers (*db->lookaside.pFree*) is NULL and
it is assigned
to pBuf and if you access pBuf->pNext it will crash. read my comments in
below code
snippet.
There is good chance that sqlite may
Hi Richard,
If list of available buffers (*db->lookaside.pFree*) is NULL and
it is assigned
to pBuf and if you access pBuf->pNext it will crash. read my comments in
below code
snippet.
There is good chance that sqlite may end up with empty
lookaside
What is the output of "EXPLAIN QUERY PLAN " ?
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/Threading-makes-SQLite-3x-slower-tp62243p70582.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing
On Tue, Aug 20, 2013 at 9:38 AM, Ashok Pitambar wrote:
> Hi All,
>
> I am facing an issue where in sqlite3DbMallocRaw function
> crashes while trying to access pBuf->pNext. Did anybody came across this
> issue? any help is appreciated.
>
This is generally an
Hi All,
I am facing an issue where in sqlite3DbMallocRaw function
crashes while trying to access pBuf->pNext. Did anybody came across this
issue? any help is appreciated.
stack trace:
sqlite3DbMallocRaw(
db = 0x24EFBF34,
?)
pBuf = 0x0B94256B -> (
pNext = 0x0 -> NULL
On Tue, Aug 20, 2013 at 9:24 AM, Filipe Oliveira
wrote:
>
> From my point of view the documentation isn't according to the
> implementation. Can anyone clarify?
>
Undocumented behavior is subject to change. You are advised to use only
documented behavior.
--
D.
On 08/12/2013 08:26 PM, Filipe Oliveira wrote:
Hi,
In parameters section of this page
http://www.sqlite.org/lang_expr.html says that
"A dollar-sign followed by an identifier name also holds a spot for a
named parameter with the name $. The identifier name in this case
can include one
On 4 Aug 2011, at 20:40, Seth Price wrote:
> so THREADSAFE=2 should work fine (as I understand it).
What makes you think it isn't?
> [...] it destroys performance.
My guess is that you've moved the bottle-neck to your disk,
and are suffering from seek latency.
So far I've sped it up by 2x-3x by increasing the cache size by 10x, removing
some extraneous SQL, and moving a bit of processing in-app. But using the full
dataset with two threads instead of one still results in a 3x-5x time increase
with either THREADSAFE=1 or 2. The fastest is
Am 16.08.2013 17:47, schrieb Kai Peters:
Stephen,
you might want to look at
http://dabodev.com/
Among other DBs it does support Sqlite and is fully cross-platform
Cheers,
Kai
Hello Stephen,
maybe another alternative is, to run FoxPro on a linux machine with the
windows emulator wine.
Again - rather a comment than a bug:
If sqlite3_finalize() fails, SQLiteBase.FinalizeStatement() throws an
exception. The only use of SQLiteBase.FinalizeStatement() is in
SqliteStatementHandle.ReleaseHandle() where this exception is caught and
ignored.
SQLite docs say that sqlite3_finalize()
14 matches
Mail list logo