Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
Your alternative to sqlite3_mutex_try() doesn't link on NT/2000/XP/Vista
because you still
have TryEnterCriticalSection there instead of getting the pointer to it
dynamically as Nicolas
suggested. So the current mutex_w32.c 1.4 does compile but won't link either.
http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/mutex_w32.c=1.3=1.4
To link it you have to add
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif _WIN32_WINNT
somewhere, I added it after the include guard in the amalgamation sqlite3.c of
3.5.0 alpha,
which I have done now to remove a link error in my code and it works. Hope drh
adds it in
the CVS.
I second that Win9X support should be dropped, it's as pointless as supporting
MS-DOS now.
It should have been dropped when sqlite3 was released.
-- sword
On Wed, 05 Sep 2007 10:20:37 +0200
Ralf Junker <[EMAIL PROTECTED]> wrote:
>
> >Isn't it time to drop the Win9X support from the default build?
>
> I do not believe that just because Win9x is missing a single required call
> justifies dropping support for it altogether!
>
> >I'm thinking that any optimization should be enabled for the majority of
> >users. Or if it's not really an optimization, why keeping it in the code
> >then?
>
> If possible, please keep the optimization.
>
> >An alternative is to call this function when available using
> >"GetProcAddress" (this is the case for a lot of other modern calls that
> >cannot be done right now).
>
> I second this alternative.
>
> According to http://msdn2.microsoft.com/en-us/library/ms686857.aspx,
> TryEnterCriticalSection() is available on all Windows NT sytems. Therefore an
> option to "GetProcAddress()" is checking for such OSes. The isNT() routine is
> already part of os_win.c and is used there frequently:
>
> static int isNT(void){
> if( sqlite3_os_type==0 ){
> OSVERSIONINFO sInfo;
> sInfo.dwOSVersionInfoSize = sizeof(sInfo);
> GetVersionEx();
> sqlite3_os_type = sInfo.dwPlatformId==VER_PLATFORM_WIN32_NT ? 2 : 1;
> }
> return sqlite3_os_type==2;
> }
>
>
> sqlite3_mutex_try() would then extend to something like this (untested!):
>
> int sqlite3_mutex_try(sqlite3_mutex *p){
> int rc;
> assert( p );
> assert( p->id==SQLITE_MUTEX_RECURSIVE || sqlite3_mutex_notheld(p) );
> if( isNT() && TryEnterCriticalSection(>mutex) ){
> p->owner = GetCurrentThreadId();
> p->nRef++;
> rc = SQLITE_OK;
> }else{
> rc = SQLITE_BUSY;
> }
> return rc;
> }
>
> Ralf
>
>
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] Re: sqlite ODBC?
I suppose this is it: http://www.ch-werner.de/sqliteodbc/ is this the official driver to use though? The readme file says: "The driver is usable but may contain lots of memory leaks and all other kinds of bugs. Use it on your own risk." Anyone have any bad experiences with it? Thanks, Mark On 10/3/07, Mark Wyszomierski <[EMAIL PROTECTED]> wrote: > Hi, > > Are there are ODBC drivers out there for sqlite on win32? I'm already > using an ODBC library and wanted to see if I could get around > rewriting everything using the native sqlite API. > > Thanks, > Mark > - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] sqlite ODBC?
Hi, Are there are ODBC drivers out there for sqlite on win32? I'm already using an ODBC library and wanted to see if I could get around rewriting everything using the native sqlite API. Thanks, Mark - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Virtual tables cannot be used with a shared cache?
In the documentation for sqlite3_enable_shared_cache it says: ** Virtual tables cannot be used with a shared cache. When shared ** cache is enabled, the [sqlite3_create_module()] API used to register ** virtual tables will always return an error. Just curious why is there such a restriction. The two concepts seem to be orthogonal - I wouldn't think a virtual table could make use of the page cache. Is there a way to have regular tables/indexes use a shared cache and virtual tables not? Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite, pthread and daemon
Just read this today, after doing some other research. Does this help any?
http://www.sqlite.org/faq.html#q6
It says, in a nutshell, don't use a database across forks.
On 10/3/07, John Stanton <[EMAIL PROTECTED]> wrote:
> How do you know that when your process forks that you are looking at the
> child, not the parent?
>
> Sabyasachi Ruj wrote:
> > Hi,
> >
> > I am writing an application which will continue to execute as a 'daemon' in
> > Linux.
> > The application is multi threaded.
> > And once the daemon is created, it will create few threads to perform some
> > tasks.
> >
> >>From here, I'll refer the 'process before creating the daemon' as 'PARENT
> > PROCESS',
> > and 'process after creating the daemon' as 'CHILD PROCESS'.
> >
> > So the threads are being created in CHILD PROCESS.
> >
> > I need to get the process id (PID) in those threads.
> >
> > Here is my problem!
> >
> > If I have called 'sqlite3_open' BEFORE creating the daemon,
> > then the PID I am getting inside the thread, is the PID of the
> > 'PARENT PROCESS', not the 'CHILD PROCESS'!
> >
> > But as after creating the daemon, the PARENT PROCESS gets killed,
> > those are invalid PIDs.
> >
> > This happens ONLY if I am calling the 'sqlite3_open' before creating the
> > daemon!
> >
> >
> > I am not getting if this is the expected behavior or not.
> >
> >
> > Herewith I am attaching one sample test project, that will depict the issue.
> > It is having one Makefile. The executable will be named as: pidtest
> >
> > To execute that process as a daemon use the '-d' command line argument.
> >
> > For example:-
> > ./pidtest -d
> >
> > This process will create one log file called 'log.txt' in the current
> > directory.
> > which will show the output.
> >
> > For limitation on size of the mail,I have removed SQLite source code('
> > sqlite3.c' and 'sqlite3.h').
> > I am using amalgamated code, version 3.4.0.
> > Checked with the latest 3.4.2. The problem is same.
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, send email to [EMAIL PROTECTED]
> > -
>
>
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
>
>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] SQLite, pthread and daemon
How do you know that when your process forks that you are looking at the
child, not the parent?
Sabyasachi Ruj wrote:
Hi,
I am writing an application which will continue to execute as a 'daemon' in
Linux.
The application is multi threaded.
And once the daemon is created, it will create few threads to perform some
tasks.
From here, I'll refer the 'process before creating the daemon' as 'PARENT
PROCESS',
and 'process after creating the daemon' as 'CHILD PROCESS'.
So the threads are being created in CHILD PROCESS.
I need to get the process id (PID) in those threads.
Here is my problem!
If I have called 'sqlite3_open' BEFORE creating the daemon,
then the PID I am getting inside the thread, is the PID of the
'PARENT PROCESS', not the 'CHILD PROCESS'!
But as after creating the daemon, the PARENT PROCESS gets killed,
those are invalid PIDs.
This happens ONLY if I am calling the 'sqlite3_open' before creating the
daemon!
I am not getting if this is the expected behavior or not.
Herewith I am attaching one sample test project, that will depict the issue.
It is having one Makefile. The executable will be named as: pidtest
To execute that process as a daemon use the '-d' command line argument.
For example:-
./pidtest -d
This process will create one log file called 'log.txt' in the current
directory.
which will show the output.
For limitation on size of the mail,I have removed SQLite source code('
sqlite3.c' and 'sqlite3.h').
I am using amalgamated code, version 3.4.0.
Checked with the latest 3.4.2. The problem is same.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] sqlite_open failing from time to time
I have a multi-threaded app, each thread owns it's own DB connection to a DB it opens for update. Other threads might have the DB open for reading/writing. From time to time the sqlite_open returns SQLITE_CANTOPEN on existing DB's. I'm curious about what circumstances would cause the open to report this and if the answer is to simply try again after a short sleep? That's how I handle "SQLITE_BUSY" errors. C - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Index size in file
An index which does not hold keys is not an index. If you don't want to allocate space for indexing then you put up with slow performance and use row searches. [EMAIL PROTECTED] wrote: I created an index on a TEXT column as I want to be able to I noticed a large increase in the file size. Looking at the binary of the file, I see that the index has a copy of all the data being indexed. 1. Is this necassary? 2. Is there a way to keep the index only in memory and not in the file. Clive - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] SQLite, pthread and daemon
Hi,
I am writing an application which will continue to execute as a 'daemon' in
Linux.
The application is multi threaded.
And once the daemon is created, it will create few threads to perform some
tasks.
>From here, I'll refer the 'process before creating the daemon' as 'PARENT
PROCESS',
and 'process after creating the daemon' as 'CHILD PROCESS'.
So the threads are being created in CHILD PROCESS.
I need to get the process id (PID) in those threads.
Here is my problem!
If I have called 'sqlite3_open' BEFORE creating the daemon,
then the PID I am getting inside the thread, is the PID of the
'PARENT PROCESS', not the 'CHILD PROCESS'!
But as after creating the daemon, the PARENT PROCESS gets killed,
those are invalid PIDs.
This happens ONLY if I am calling the 'sqlite3_open' before creating the
daemon!
I am not getting if this is the expected behavior or not.
Herewith I am attaching one sample test project, that will depict the issue.
It is having one Makefile. The executable will be named as: pidtest
To execute that process as a daemon use the '-d' command line argument.
For example:-
./pidtest -d
This process will create one log file called 'log.txt' in the current
directory.
which will show the output.
For limitation on size of the mail,I have removed SQLite source code('
sqlite3.c' and 'sqlite3.h').
I am using amalgamated code, version 3.4.0.
Checked with the latest 3.4.2. The problem is same.
--
Sabyasachi
pidtest_pthread.tar.gz
Description: GNU Zip compressed data
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] Index size in file
I created an index on a TEXT column as I want to be able to I noticed a large increase in the file size. Looking at the binary of the file, I see that the index has a copy of all the data being indexed. 1. Is this necassary? 2. Is there a way to keep the index only in memory and not in the file. Clive - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] CONFIG_FPE_FASTFPE and the text representation of a float
L.S. As per earlier posts: I'm using Sqlite on an Arm architecture without FP-unit running a kernel that has FASTFPE built in. After solving the mixed-endian issue, it turns out there's yet another problem when one is looking at floating point numbers in a text representation.. A number like 1.24, which is not exactly representable, will be presented still by Sqlite as '1.24', but the underlying 'magic' fails in the situation of FASTFPE, simply because the assumptions made on accuracy are obviously 'wrong' then ;( * a regular 64 bit float has 52+1 bits for the mantissa and thus an estimated number of accurate digits of log(2^53) ~= 15.955 => 16 digits * a fastfpe float has 32+1 bits for the mantissa and thus an estimated number of accurate digits of log(2^33) ~= 15.955 => 10 digits So, I've been trying to find the locations for this 'magic' and came up with the following two: src/printf.c:158 contains et_getdigit() with line 161: if( (*cnt)++ >= 16 ) return '0'; in which I'd need to change the 16 into 10. src/vdbemem.c:201 contains sqlite3VbdeMemStringify() with line 220: sqlite3_snprintf(NBFS, z, "%!.15g", pMem->r); in which I'd need to change the 15 into 9 Changing these values seems to work out fine (and it returns '1.24' again instead of something like '1.2399962718'), but since I'm not thát known with sqlite's source, I'm wondering if there are more locations that have some hardcoded notion on float-accuracy... DRH, any hints...? I'll wrap the changes up in a patch using some define like SQLITE_FASTFPE or something, unless DRH has a different idea ;) -- Best, Frank. - To unsubscribe, send email to [EMAIL PROTECTED] -
