Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64

2007-01-15 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

SQLite works fine on 64 bit platforms.  In my case I am using Linux
64bit.  The warnings are about pointers being cast to int.

> Looking at the code, there are pointer to int truncations
> everywhere, 

Pointers are used as placeholders in callbacks.  For example if you
register a function, you supply a chunk of data in the form of a void
pointer that is supplied to you again when the function is called.  If
your data really was an int, then you'd convert to void* at
registration, and then convert from void* in the callback.  That is not
an error nor if information lost.

> and I've found no magic bullet for declalring int's as 64 bit
> (__int64 and longlong is how I normally do it.)  

No platform uses 64 bit ints.  Every common 64 bit platform uses 32 bit
ints.  Microsoft was unique in also using 32 bit longs while everyone
else uses 64 bit longs.

Somehow convincing sqlite to use 64 bit ints won't solve your problem.
You need to show what your other errors are.

BTW SQLite is limited to 2GB for strings and blobs even on 64 bit
platforms due to using int in the api for the size of various things.
Not that shoving such large objects into the database is a good idea
anyway.  http://www.sqlite.org/cvstrac/tktview?tn=2125

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFrHX+mOOfHg372QQRAlsyAJ9qiydtFUptvjruaPAJi02vCkD9VACgzp5y
QIAjOieKHwMFjVzTctKEDDg=
=GIOt
-END PGP SIGNATURE-

-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64

2007-01-15 Thread Joe Wilson
--- [EMAIL PROTECTED] wrote:
> "Ian Frosst" <[EMAIL PROTECTED]> wrote:
> >  Looking at the code, there are pointer to int truncations
> > everywhere,
> 
> Where, specifically, are you seeing pointer to int truncations
> in the SQLite code base?

I haven't seen any. I suspect there aren't any.

As for his comment on the lack of a 64 bit datatype, he did not
look very hard...

#ifdef SQLITE_INT64_TYPE
  typedef SQLITE_INT64_TYPE sqlite_int64;
  typedef unsigned SQLITE_INT64_TYPE sqlite_uint64;
#elif defined(_MSC_VER) || defined(__BORLANDC__)
  typedef __int64 sqlite_int64;
  typedef unsigned __int64 sqlite_uint64;
#else
  typedef long long int sqlite_int64;
  typedef unsigned long long int sqlite_uint64;
#endif



 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64

2007-01-15 Thread drh
"Ian Frosst" <[EMAIL PROTECTED]> wrote:
>  Looking at the code, there are pointer to int truncations
> everywhere,

Where, specifically, are you seeing pointer to int truncations
in the SQLite code base?  This is something that needs to be
fixed.
--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-



[sqlite] SQLite 3.3.10 compilation with VC++ for Win64

2007-01-15 Thread Ian Frosst

Has anyone here gotten 3.3.10 (or any subsequent version) to compile and run
successfully through Visual C++ (I'm using 2005, but again, any version
would do.)  Looking at the code, there are pointer to int truncations
everywhere, and I've found no magic bullet for declalring int's as 64 bit
(__int64 and longlong is how I normally do it.)  If there really is no way
to get VC++ to work, would it be fair to assume that I have to get a 64 bit
version of gcc, and use that to do the compilation (I've read that it will
compile int to 64 bit)?

Thanks,
Frosstoise


RE: [sqlite] Restricting integer primary key values

2007-01-15 Thread Brett Keating
Hi Wayne,

What I've decided to do is manage it myself. I have a trigger on deletes
to the main table, which stores the deleted primary key in another
table. If the other table is empty, I query for the max key in the main
table and increment it by one. If the other table is not empty, I take a
value from that table and use it, then delete that value from that
table.

The values of the primary keys don't matter to me so long as they are
within my range, so I'm just trying to re-use any "holes" in the
sequence just in case I ever run out (which I imagine won't happen in my
lifetime but hey you never know).

Thanks for the replies,
Brett

-Original Message-
From: w b [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 15, 2007 11:42 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Restricting integer primary key values


Hi Brett,

I dont think that there is a way within Sqlite to automagically do what
you are looking for. I know that within Oracle they have the ability for
you to define a sequence which allows lower and upper bounds to be
defined as well as if the sequence can loop, which sounds like what you
could be looking for.

However typically even within Oracle you then use the value obtained
from the sequence value into your insert statement. 

This however is not automatic and would still require you to check the
bounds conditions, since a declared sequence can be used for anything
you really like and is not tied to a specific primary key within a
specific table. 

In the case of sqlite you would probably need to create a C function to
do that your self.

Dr H, I was wondering if it would be worth considering exposing the
ability for a user to define a function that could override the auto
increment abilities of the primary key, or would that open up a can of
worms ?



Wayne


Brett Keating <[EMAIL PROTECTED]> wrote: Hi,

This does indeed work, but only to prevent primary keys from being
inserted into the database if they fall out of range.

What I was hoping was that the with this command, the sqlite3 would
always automatically choose primary keys that fell within this range.
However with this command, the sqlite3 will eventually automatically
choose a primary key outside of this range (I tested with a range of 100
to 1000), and fail to insert the new item based on the check clause.

I tried to repeat the statement hoping that a new primary key would be
generated and eventually the insertion would succeed, but this ended up
causing an infinite loop (I think the key once chosen by the automated
algorithm remains the same for repeated attempts).

Are there any alternatives? I want automatic key generation that is
restricted to a range, and I don't want failures unless all possible
values are taken. I will continue trying other things in the meantime.

Thanks,
Brett

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 14, 2007 6:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Restricting integer primary key values

"Brett Keating"  wrote:
> Hi,
> 
> I don't want to spam the list but basically, if "id INTEGER PRIMARY 
> KEY CHECK (id > 0 and id < 0x)" or something along those lines

> will work, please let me know. It's not clear if sqlite3 supports 
> checks on primary keys from what I can tell.
> 

SQLite does not support hexadecimal constants.  Use
4294967295 instead of 0x and it should work.
--
D. Richard Hipp  



-
To unsubscribe, send email to [EMAIL PROTECTED]

-





-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] Is there a way to turn off -journal files?

2007-01-15 Thread Will Leshner

On 1/15/07, Dave Gierok <[EMAIL PROTECTED]> wrote:

I'm building the Sqlite lib using the preprocessor definition TEMP_STORE=3, but 
I still notice that temporary '-journal' files are being created/deleted when 
running queries that will modify the DB.  I thought that the TEMP_STORE=3 was 
supposed to disable these temporary files that get created.


-journal files are an integral part of SQLite's ACID-ity, and as such,
they can't be turned off or otherwise avoided.


How can I build/use Sqlite such that these temporary files do not get created?  
I am running on Xbox360 and perf/storage are critical because the DB can be 
stored to a memory card (not much storage).


I wonder if this might work: keep the database on disk, but when using
it, always use it from an in-memory version. You could open an
in-memory database, attach the on-disk version, and then copy all the
data from the on-disk version to the in-memory version. Hmm.
Unfortunately, I'm not sure how to copy the data back out to the
on-disk version without the -journal file getting created, so maybe
this isn't such a great idea after all. If it were possible to
serialize the in-memory database as save it as a raw binary stream,
then it might work. But I don't think there is a way to do that.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-



RE: [sqlite] Is there a way to turn off -journal files?

2007-01-15 Thread Tom Briggs

   The short answer is that you can not (as far as I'm aware, anyway)
turn of journal files, though it's a common question and I'm sure you
can find a lot of information about it by searching the archives.

   TEMP_STORE controls where "truly" temp files (e.g. those needed for
sorting, and I believe for tables declared as temporary) are stored.
Journal files are not really temporary - they need to persist if the
process should die in order for recovery to be performed.  They also
need to be stored in a predictable location, again so that changes can
be consistently recovered in the case of a crash, so they are always
stored in the same directory as the database itself.  Thus TEMP_STORE
has no impact on their creation or location.

   -Tom

> -Original Message-
> From: Dave Gierok [mailto:[EMAIL PROTECTED] 
> Sent: Monday, January 15, 2007 11:23 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Is there a way to turn off -journal files?
> 
> I'm building the Sqlite lib using the preprocessor definition 
> TEMP_STORE=3, but I still notice that temporary '-journal' 
> files are being created/deleted when running queries that 
> will modify the DB.  I thought that the TEMP_STORE=3 was 
> supposed to disable these temporary files that get created.
> 
> How can I build/use Sqlite such that these temporary files do 
> not get created?  I am running on Xbox360 and perf/storage 
> are critical because the DB can be stored to a memory card 
> (not much storage).
> 
> Thanks,
> Dave Gierok
> 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] Restricting integer primary key values

2007-01-15 Thread Clark Christensen
Brett,

Have a look at http://www.sqlite.org/cvstrac/tktview?tn=1476  There may still 
be some custom function work to do for the OP's app, but this idea was a great 
start for me in implementing/managing a foreign sequence.  Not sure if his 
wrapper supports custom SQL functions.

 -Clark

- Original Message 
From: w b <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Sent: Monday, January 15, 2007 11:41:39 AM
Subject: RE: [sqlite] Restricting integer primary key values


Hi Brett,

I dont think that there is a way within Sqlite to automagically do what 
you are looking for. I know that within Oracle they have the ability 
for you to define a sequence which allows lower and upper bounds to be 
defined as well as if the sequence can loop, which sounds like what you could 
be looking for.

However typically even within Oracle you then use the value obtained from 
the sequence value into your insert statement. 

This however is not automatic and would still require you to 
check the bounds conditions, since a declared sequence can be used for 
anything you really like and is not tied to a specific primary key within a 
specific table. 

In the case of sqlite you would probably need to create a C function to do that 
your self.

Dr H, I was wondering if it would be worth considering exposing the 
ability for a user to define a function that could override the auto 
increment abilities of the primary key, or would that open up a can of worms 
?



Wayne


Brett Keating <[EMAIL PROTECTED]> wrote: Hi,

This does indeed work, but only to prevent primary keys from being
inserted into the database if they fall out of range.

What I was hoping was that the with this command, the sqlite3 would
always automatically choose primary keys that fell within this range.
However with this command, the sqlite3 will eventually automatically
choose a primary key outside of this range (I tested with a range of 100
to 1000), and fail to insert the new item based on the check clause.

I tried to repeat the statement hoping that a new primary key would be
generated and eventually the insertion would succeed, but this ended up
causing an infinite loop (I think the key once chosen by the automated
algorithm remains the same for repeated attempts).

Are there any alternatives? I want automatic key generation that is
restricted to a range, and I don't want failures unless all possible
values are taken. I will continue trying other things in the meantime.

Thanks,
Brett

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 14, 2007 6:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Restricting integer primary key values

"Brett Keating"  wrote:
> Hi,
> 
> I don't want to spam the list but basically, if "id INTEGER PRIMARY 
> KEY CHECK (id > 0 and id < 0x)" or something along those lines

> will work, please let me know. It's not clear if sqlite3 supports 
> checks on primary keys from what I can tell.
> 

SQLite does not support hexadecimal constants.  Use
4294967295 instead of 0x and it should work.
--
D. Richard Hipp  



-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-






-
To unsubscribe, send email to [EMAIL PROTECTED]
-



RE: [sqlite] Restricting integer primary key values

2007-01-15 Thread w b

Hi Brett,

I dont think that there is a way within Sqlite to automagically do what 
you are looking for. I know that within Oracle they have the ability 
for you to define a sequence which allows lower and upper bounds to be 
defined as well as if the sequence can loop, which sounds like what you could 
be looking for.

However typically even within Oracle you then use the value obtained from 
the sequence value into your insert statement. 

This however is not automatic and would still require you to 
check the bounds conditions, since a declared sequence can be used for 
anything you really like and is not tied to a specific primary key within a 
specific table. 

In the case of sqlite you would probably need to create a C function to do that 
your self.

Dr H, I was wondering if it would be worth considering exposing the 
ability for a user to define a function that could override the auto 
increment abilities of the primary key, or would that open up a can of worms 
?



Wayne


Brett Keating <[EMAIL PROTECTED]> wrote: Hi,

This does indeed work, but only to prevent primary keys from being
inserted into the database if they fall out of range.

What I was hoping was that the with this command, the sqlite3 would
always automatically choose primary keys that fell within this range.
However with this command, the sqlite3 will eventually automatically
choose a primary key outside of this range (I tested with a range of 100
to 1000), and fail to insert the new item based on the check clause.

I tried to repeat the statement hoping that a new primary key would be
generated and eventually the insertion would succeed, but this ended up
causing an infinite loop (I think the key once chosen by the automated
algorithm remains the same for repeated attempts).

Are there any alternatives? I want automatic key generation that is
restricted to a range, and I don't want failures unless all possible
values are taken. I will continue trying other things in the meantime.

Thanks,
Brett

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 14, 2007 6:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Restricting integer primary key values

"Brett Keating"  wrote:
> Hi,
> 
> I don't want to spam the list but basically, if "id INTEGER PRIMARY 
> KEY CHECK (id > 0 and id < 0x)" or something along those lines

> will work, please let me know. It's not clear if sqlite3 supports 
> checks on primary keys from what I can tell.
> 

SQLite does not support hexadecimal constants.  Use
4294967295 instead of 0x and it should work.
--
D. Richard Hipp  



-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-




RE: [sqlite] Restricting integer primary key values

2007-01-15 Thread Brett Keating
Hi,

This does indeed work, but only to prevent primary keys from being
inserted into the database if they fall out of range.

What I was hoping was that the with this command, the sqlite3 would
always automatically choose primary keys that fell within this range.
However with this command, the sqlite3 will eventually automatically
choose a primary key outside of this range (I tested with a range of 100
to 1000), and fail to insert the new item based on the check clause.

I tried to repeat the statement hoping that a new primary key would be
generated and eventually the insertion would succeed, but this ended up
causing an infinite loop (I think the key once chosen by the automated
algorithm remains the same for repeated attempts).

Are there any alternatives? I want automatic key generation that is
restricted to a range, and I don't want failures unless all possible
values are taken. I will continue trying other things in the meantime.

Thanks,
Brett

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 14, 2007 6:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Restricting integer primary key values

"Brett Keating" <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I don't want to spam the list but basically, if "id INTEGER PRIMARY 
> KEY CHECK (id > 0 and id < 0x)" or something along those lines

> will work, please let me know. It's not clear if sqlite3 supports 
> checks on primary keys from what I can tell.
> 

SQLite does not support hexadecimal constants.  Use
4294967295 instead of 0x and it should work.
--
D. Richard Hipp  <[EMAIL PROTECTED]>



-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-



[sqlite] Looking for Windows sqlite.dll with fts1.dll included

2007-01-15 Thread David Leigh
Complete Noob here – warning!

Here’s my ultimate goal, so you all can either guide me towards a solution
or tell me I’m barking up the wrong tree! ;c)

I’m trying to set up a full text search of a database of song lyrics.  This
is a Windows application that will run on Win2000.  It’s written in the
AutoIt3 scripting language that comes with some functions that facilitate
the access to SQLite.  I find SQLite to be an ideal solution for what I’m
trying to do.  Thank you Richard Hipp!

I used to be a DBA for DB2 on mainframes in a previous life.  Heavy SQL
experience so that’s not too much of an issue.  What IS an issue for me is
that I need to (want to) use the fts1 (and hopefully fts2 eventually)
extension and the .dll interface in a Windows environment.

When I do a test with SQLite.exe, I can load the fts1 extension just fine.
When I use the .dll version (version with or without Tcl) I get the “not
authorized” error and can’t load the extension.  If I understand what I’ve
read about that in the Wiki about Loadable Extensions and “calling”
sqlite3_enable_load_extension, it would appear that I need to re-compile the
source differently to either link the fts1 capability into the .dll or to
enable the loading of it at runtime.  Either solution is acceptable to me,
but I’m stuck with getting from point A to point B.

I’ve tried to install/run MSYS/MinGW but it doesn’t even start on my system.
I successfully installed Dev-C++ and tried to simply “re-compile” the source
and see what happens.  It won’t compile.  This is because, no doubt, that my
only experience in compiling is COBOL on an IBM mainframe.  I am CLUELESS
about C, C++, makefiles, def files, etc. Any step-by-step procedures out
there all refer to versions of SQLite BEFORE fts1.

What I’m asking for (many “pleases” and “thank-you’s!” here) is either:
*   A windows sqlite3.dll with fts1 linked in  OR
*   A windows sqlite3.dll with the ability to load extensions turned on   OR
*   The complete idiots guide to achieve either of those ends with Dev-C++ 
(or
something else that runs on my system)

I’m really NOT interested in learning C or C++.  I don’t expect that I’ll be
a long-time customer of Dev-C++ either.  Any helping hand that someone could
lend would be MOST appreciated.

Thank you,
David Leigh