Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
-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
--- [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
"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
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
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?
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?
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
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
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
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
Complete Noob here warning! Heres my ultimate goal, so you all can either guide me towards a solution or tell me Im barking up the wrong tree! ;c) Im trying to set up a full text search of a database of song lyrics. This is a Windows application that will run on Win2000. Its 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 Im 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 thats 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 cant load the extension. If I understand what Ive 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 Im stuck with getting from point A to point B. Ive tried to install/run MSYS/MinGW but it doesnt even start on my system. I successfully installed Dev-C++ and tried to simply re-compile the source and see what happens. It wont 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 Im asking for (many pleases and thank-yous! 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) Im really NOT interested in learning C or C++. I dont expect that Ill be a long-time customer of Dev-C++ either. Any helping hand that someone could lend would be MOST appreciated. Thank you, David Leigh