> Unfortunately I oversimplified my explanation, and the processing
> that is required is somewhat more complex.
Perhaps you could give more detail about your data. It seems to me
that you should restructure your data so it is "atomic", ie so that
each bit of data appears in its own row in
Saturday, September 6, 2008, 10:03:00 AM, you wrote:
IT> "Neville Franks" <[EMAIL PROTECTED]> wrote
IT> in message news:[EMAIL PROTECTED]
>> At present the clm data is a list of one or more numeric id's
>> separated by either a space or comma. I need to update this so the
>> id's are always comma
Gerry Snyder wrote:
> I am not sure what all this means when taken together.
>
> It sounds as if defining id as shown above is unnecessary, since it is
> just an alias for ROWID, and if one is stable the other has to be. Correct?
>
> So now I can't interpret "ROWID can change" as meaning
Is there a common practice on quoting/sanitizing the snippets
generated by the fts search?
If I have "foo bar lee" in one field and search for bar, the
snippet function will return "foo bar lee", which is
obvious not what I want and can easily be used for cross-site
scripting.
I can think
D. Richard Hipp wrote:
> On Sep 6, 2008, at 2:50 AM, Scott Hess wrote:
>
>
>> On Fri, Sep 5, 2008 at 11:31 PM, jonwood <[EMAIL PROTECTED]>
>> wrote:
>>
>>> But the documentation states the ROWID
>>> can change at any time so I'm not sure what I can do safely.
>>>
>> Do this:
On Sat, Sep 6, 2008 at 7:44 AM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> On Sep 6, 2008, at 2:50 AM, Scott Hess wrote:
>> As a bonus, if the implementation of SQLite changes, SQL itself won't,
>> so id will _still_ be a valid integer primary key, even if the
>> implementation detail of rowid
On Sat, Sep 6, 2008 at 10:44 AM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> > As a bonus, if the implementation of SQLite changes, SQL itself won't,
> > so id will _still_ be a valid integer primary key, even if the
> > implementation detail of rowid changes.
>
> I promise that INTEGER PRIMARY
On Sep 6, 2008, at 2:50 AM, Scott Hess wrote:
> On Fri, Sep 5, 2008 at 11:31 PM, jonwood <[EMAIL PROTECTED]>
> wrote:
>> I have a table where the primary key consists of two columns. I'm
>> doing this
>> because these two columns combined must be unique, while each
>> column is not
>>
When building sqlite 3.6.2 on Mandriva Linux Cooker x86_64, some tests
fail:
12 errors out of 23377 tests
Failures on these tests: lookaside-1.4 lookaside-1.5 memsubsys1-2.3
memsubsys1-2.4 memsubsys1-3.2.4 memsubsys1-4.3 memsubsys1-4.4
memsubsys1-5.3 memsubsys1-6.3 memsubsys1-6.4
Can I suggest another way that I adopted a long time ago to solve this
kind of issue?
Forget the autoincrement function included in your RDBM and use a
customized one more or less similar to the one I developped in my ZQLib
(adapted from ZEOSDBO) for Delphi (previously I did the same thing
Scott Hess wrote:
>
> CREATE TABLE t (
> id INTEGER PRIMARY KEY,
> a TEXT NOT NULL,
> b INTEGER NOT NULL,
> UNIQUE (a, b)
> );
>
> (a,b) will be just as unique as in the first case, but now you can use
> id as a stable alias for rowid. There will be the same number of
> btrees (one
On Fri, Sep 5, 2008 at 11:31 PM, jonwood <[EMAIL PROTECTED]> wrote:
> I have a table where the primary key consists of two columns. I'm doing this
> because these two columns combined must be unique, while each column is not
> unique on its own.
>
> Because of the increased complexity of a
I have a table where the primary key consists of two columns. I'm doing this
because these two columns combined must be unique, while each column is not
unique on its own.
Because of the increased complexity of a dual-column primary key for some
operations, I'd like to use ROWID. But the
13 matches
Mail list logo
