I have a virtual table implementation that implements the xBestIndex/xFilter
functions.
Problem:
A LIKE query (for eg. field LIKE prefix%) gets sets to xBestIndex as a GT/LT
pair.
However, I can't tell from the sqlite3_index_info whether that GT/LT should be
NOCASE collation or BINARY
Simple question, likely to have a simple answer.
I have tables in SQLite using GUID primary key columns. I am attempting to
select a row based on its literal guid value in C#.Net.
Here's a sample query:
SELECTRole.Id, Role.Name, Role.Description, Role.Active, Role.BitMask
FROM
This defect report is cloned from mozilla bug595599
RW: This patch disables WAL journalling on OS/2 since that feature
requires memory-mapped file i/o which OS/2 doesn't support, and makes
other small changes where needed.
The patch was originally created by Rich Walsh against the amalgamation
On Wed, Sep 22, 2010 at 11:15 PM, Igor Tandetnik itandet...@mvps.orgwrote:
Josh Gibbs jgi...@imailds.com wrote:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
CREATE TABLE MessageRecipient (message_id INTEGER REFERENCES
Message(message_id) ON DELETE
Josh Gibbs jgi...@imailds.com wrote:
On 23/09/2010 3:15 p.m., Igor Tandetnik wrote:
You could do something like
delete from Recipient where recipient_ID = old.recipient_ID and
recipient_ID not in (select recipient_ID from MessageRecipient);
That was the last idea we had as well.
On Thu, Sep 23, 2010 at 7:16 AM, Ben Harper b...@imqs.co.za wrote:
I have a virtual table implementation that implements the
xBestIndex/xFilter functions.
Problem:
A LIKE query (for eg. field LIKE prefix%) gets sets to xBestIndex as a
GT/LT pair.
However, I can't tell from the
I know the literal GUID value shown is correct, as I copied it directly from
the results pane when I do a SELECT * FROM UserRole, however, as soon as I
add the WHERE clause, I get no results.
Execute 'SELECT UserId, typeof(UserId) FROM UserRole' preferably from
sqlite command line utility
On Wed, Sep 22, 2010 at 6:56 PM, Walter Meinl w...@lsvw.de wrote:
This defect report is cloned from mozilla bug595599
RW: This patch disables WAL journalling on OS/2 since that feature
requires memory-mapped file i/o which OS/2 doesn't support, and makes
other small changes where needed.
The
Hi,
I've got a table with a primary key and then any number of additional tables
with foreign keys that reference this primary key table with ON DELETE
RESTRICT hence stopping the deletion of any row from the primary key table
if there exists any rows in any of the foreign key tables that
I just discovered the MSVC compiler generates bad debug info for source files
larger than 64k lines, which is the case with the Sqlite amalgamation.
Does anyone know of a workaround?
Thanks,
Ben
___
sqlite-users mailing list
sqlite-users@sqlite.org
Hello Ben,
Thursday, September 23, 2010, 9:17:39 AM, you wrote:
BH I just discovered the MSVC compiler generates bad debug info for
BH source files larger than 64k lines, which is the case with the Sqlite
amalgamation.
BH Does anyone know of a workaround?
BH Thanks,
BH Ben
BH
OK.
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of Teg
Sent: 23 September 2010 03:20 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Breakpoints uncorrelated on MSVC amalgamation build
Hello Ben,
Which MSVC compiler has this bug? There's a link to information on that ?
On Thu, Sep 23, 2010 at 10:17, Ben Harper b...@imqs.co.za wrote:
I just discovered the MSVC compiler generates bad debug info for source
files larger than 64k lines, which is the case with the Sqlite amalgamation.
Does
On 23 Sep 2010, at 2:13pm, Andy Gibbs wrote:
I've got a table with a primary key and then any number of additional tables
with foreign keys that reference this primary key table with ON DELETE
RESTRICT
I always worry when I see descriptions like this. Those additional tables: do
they all
On Thursday, September 23, 2010 3:36 PM, Simon Slavin wrote:
On 23 Sep 2010, at 2:13pm, Andy Gibbs wrote:
I've got a table with a primary key and then any number of additional
tables
with foreign keys that reference this primary key table with ON DELETE
RESTRICT
I always worry when I see
On 23 Sep 2010, at 2:59pm, Andy Gibbs wrote:
It seems to be a trade-off -- either the complexity is in the DELETE
statement to keep the primary key table tidy or in the SELECT statement
querying it. If it has to be a choice, then the complexity has to be in the
DELETE statement since
MyJSQLView Version 3.23 Released
The MyJSQLView project is pleased to provide the release of Version
3.23 to the public. The release marks the addition of support for
the SQLite database. New to this release of MyJSQLView is also the
support for in memory databases that is featured for both the
Thanks - I've stepped through some of where.c to try and understand exactly
what's going
on, but in vain.
I'm looking around line 1272 of where.c, but I can't find where the system
decides
not to call xBestIndex because of a collation mismatch. By collation mismatch,
I mean the column's
I can't confirm this behaviour on anything other than 2010. But I seem to
recall the same business a few months ago, when I must have been on 2008.
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of Virgilio Fornazin
Sent: 23
There are more fields in each table, but for the sake of brevity, I ommited
them from the snippets below.
With smaller data sets, the second query works just fine as well.
SELECT COUNT(*) FROM link;
960219
SELECT COUNT(*) FROM node;
812193
Pvid's are INTEGERS.
On linux, the following query
This limitation has been around for a while in the MS Visual
debuggers... I can't find the MSDN article that discusses it, but
once you exceed 64k lines, all bets are off.
Work arounds include using the canonical source to build and debug, or
stripping comment lines, white space etc. from the
They are still using 16-bits offsets... arghh!
On Thu, Sep 23, 2010 at 14:10, Shane Harrelson sh...@sqlite.org wrote:
This limitation has been around for a while in the MS Visual
debuggers... I can't find the MSDN article that discusses it, but
once you exceed 64k lines, all bets are off.
On 23/09/2010 11:52 p.m., Richard Hipp wrote:
Josh Gibbsjgi...@imailds.com wrote:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
CREATE TABLE MessageRecipient (message_id INTEGER REFERENCES
Message(message_id) ON DELETE CASCADE, recipient_ID INTEGER
23 matches
Mail list logo
