> > > Any comments on this - Richard or Dan?
> >
> > The INTEGER PRIMARY KEY is always included in every index as an
> > implied extra column on the end. If you explicitly add the
> > INTEGER PRIMARY KEY as a column in the index, then you have it
> > in the index twice, which serves no purp
On Thu, 20 Nov 2008 12:47:26 +0530,
<[EMAIL PROTECTED]> wrote in General
Discussion of SQLite Database :
>I think the question by the original poster was about data security and
>not file security. He probably does not mind if the file is copied, but
>the data should be decipherable only by his a
On Thu, 20 Nov 2008 15:25:35 +0100, Christophe Leske <[EMAIL PROTECTED]> wrote
in
General Discussion of SQLite Database :
>
>>> Any chance to spare the ID field and get an index on the rowid for a
>>> given table?
>> I do not understand the question. Please rephrase. Use more words.
>>
>Mo
Abshagen, Martin RD-AS41 <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I wrote the following simple test and wonder why sqlite_bind_parameter_count()
returns the value 2 (as
> expected) while the subsequent four sqlite_bind_parameter_*() functions all
return 0.
> I tried it with sqlite3 versions 3.6.1
Hi all,
I have a problem with a query that I thought is easy. I have a database
containing a following data:
CREATE TABLE [Magazyn]
(
[IdMagazyn] integer PRIMARY KEY AUTOINCREMENT ,
[IdMat] integer,
[Partia] varchar (10),
[Ilosc] integer,
[DelK] integer DEFAULT 0,
[Mdata] integer
>> Any chance to spare the ID field and get an index on the rowid for a
>> given table?
> I do not understand the question. Please rephrase. Use more words.
>
Most of the ID fields are primary integer keys which also coincident with the
value of the rowid for a given table. Yes, you cannot
On Nov 13, 2008, at 9:56 AM, Hugh Gibson wrote:
>
> This query:
>
> SELECT * FROM Signals WHERE sUserID='[EMAIL PROTECTED]' AND nRowID >=
> 1932308
> and nRowID <= 1932508
Try either of these:
SELECT * FROM Signals WHERE +sUserID='...' AND nRowID>=... AND
nRowid<=;
SELECT * FROM
"wojtek" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Then, I have the following data in this Table:
> IdIdMat Partia Ilosc DelK
> 1614577149001
> 5614577149001
> 6614577144801
> 7614760519000
> 8614
"Abshagen, Martin RD-AS41"
<[EMAIL PROTECTED]> wrote in
message
news:[EMAIL PROTECTED]
> I wrote the following simple test and wonder why
> sqlite_bind_parameter_count() returns the value 2 (as expected) while
> the subsequent four sqlite_bind_parameter_*() functions all return 0.
> char sSqlPrepa
2008/11/19 wojtek <[EMAIL PROTECTED]>:
> Hiall,
> I have a problem with a query that I thought is easy. I have a database
> containing a following data:
> CREATE TABLE [Magazyn]
> (
>[IdMagazyn] integer PRIMARY KEY AUTOINCREMENT ,
>[IdMat] integer,
>[Partia] varchar (10),
>[Ilosc] i
> > Any comments on this - Richard or Dan?
>
> The INTEGER PRIMARY KEY is always included in every index as an
> implied extra column on the end. If you explicitly add the INTEGER
> PRIMARY KEY as a column in the index, then you have it in the
> index twice, which serves no purpose
I trie
Hi,
I wrote the following simple test and wonder why sqlite_bind_parameter_count()
returns the value 2 (as expected) while the subsequent four
sqlite_bind_parameter_*() functions all return 0.
I tried it with sqlite3 versions 3.6.1 and 3.6.6, so I think there is a simple
explanation to be found
Hiall,
I have a problem with a query that I thought is easy. I have a database
containing a following data:
CREATE TABLE [Magazyn]
(
[IdMagazyn] integer PRIMARY KEY AUTOINCREMENT ,
[IdMat] integer,
[Partia] varchar (10),
[Ilosc] integer,
[DelK] integer DEFAULT 0,
[Mdata] in
My current understanding, which may well be imperfect, is as follows:
1) If you open an Sqlite database more than once (i.e. issue
multiple calls to sqlite3_open) for reading and writing then you will
get locking conflicts between the different connections
2) So in order to avoid th
On Nov 20, 2008, at 7:17 AM, Christophe Leske wrote:
>
>> The INTEGER PRIMARY KEY is always included in every index as an
>> implied extra column on the end. If you explicitly add the INTEGER
>> PRIMARY KEY as a column in the index, then you have it in the index
>> twice, which serves no purpose
I agree with that. However if I were writing such an application I would
worry about folks copying the database and possibly rendering the database
useless.
There are a few things that I would recommend.
To keep others from reading the database you will have to write some sort of
encryption routi
> The INTEGER PRIMARY KEY is always included in every index as an
> implied extra column on the end. If you explicitly add the INTEGER
> PRIMARY KEY as a column in the index, then you have it in the index
> twice, which serves no purpose but does confuse the optimizer. Don't
> do that.
>
On Nov 20, 2008, at 6:20 AM, Hugh Gibson wrote:
> Any comments on this - Richard or Dan?
The INTEGER PRIMARY KEY is always included in every index as an
implied extra column on the end. If you explicitly add the INTEGER
PRIMARY KEY as a column in the index, then you have it in the index
t
2008/11/20 Christophe Leske <[EMAIL PROTECTED]>:
> Hi,
>
> i am creating my table as such:
>
> create temp table idlookup as select id from ...
>
> I would like ID to be unique in my idlookup table. How would I do this
> using this construct?
create temp table idlookup as select distinct id from
* Florian Weimer:
>> On Nov 19, 2008, at 9:59 PM, Florian Weimer wrote:
>>
>>> In order to avoid a resource leak, I think I need some sort of
>>> callback when the memory allocated by sqlite3_aggregate_context is
>>> freed by SQLite.
>>>
>>> As far as I can see, it is not guaranteed that the xFina
Any comments on this - Richard or Dan?
Hugh
> This appears to be the same as
> http://www.sqlite.org/cvstrac/tktview?tn=1893
>
> I've attached a comment there.
>
> This is quite a big trap which I only found when loading up the
> database with a lot of data. What's the timescale for fixing the
Hi,
i am creating my table as such:
create temp table idlookup as select id from ...
I would like ID to be unique in my idlookup table. How would I do this
using this construct?
Or is it impossible?
--
Christophe Leske
www.multimedial.de - [EMAIL PROTECTED]
http://www.linkedin.com/in/multim
On Nov 20, 2008, at 4:39 PM, Hugh Gibson wrote:
>>> According to Igor all that happens when you create a primary
>>> key is that an index with the unique constraint is created. And
>>> the only good reason for not being able to drop it, as far as I
>>> can tell, is so that the SQL statement store
> > According to Igor all that happens when you create a primary
> > key is that an index with the unique constraint is created. And
> > the only good reason for not being able to drop it, as far as I
> > can tell, is so that the SQL statement stored for the table is not
> > made invalid.
>
> Yes
> ahhh... now we are getting somewhere.
>
> Here is a suggestion... start a new thread, with a clear and relevant
> subject line, describe your app succinctly, note that it works on such
> and such machine, and that it fails to work on such and such machine,
> describe exactly what "does not run"
25 matches
Mail list logo
