I am having a problem with single quotes in a C program.
Consider a simple table
CREATE TABLE t(comp TEXT);
Lets say I use sqlite3_prepare to prepare the following string:
"SELECT rowid FROM table WHERE comp=?;"
And then I call sqlite3_bind_text to bind "abc'def" to the statement.
And t
Igor, I thought having a statement in progress or not finalized resulted
in SQLITE_LOCKED, not SQLITE_BUSY... but I have been searching for such
a condition anyway.
As to the second question below, the parameters bound each time are
different, thus the reset.
Igor Tandetnik wrote:
Dixon
No, I did not explicitly set it.
John Stanton wrote:
Do you set the inherit handles flag on your CreateProcess call?
Dixon Hutchinson wrote:
The basic problem is that I am getting SQLITE_BUSY on a call to
sqlite3_exec where the SQL passed is simply "COMMIT;"
Notes:
1. Th
The basic problem is that I am getting SQLITE_BUSY on a call to
sqlite3_exec where the SQL passed is simply "COMMIT;"
Notes:
1. This in on a WIN32 platform.
2. There is only one process (the main process) that makes any calls
to sqlite3 for the DB in question.
3. The process is singl
the
open succeeds just fine. All I want to do really is test for the
existence of the file and whether or not I have permissions to open it
with sqlite.
Trevor Talbot wrote:
On 12/1/06, Dixon Hutchinson <[EMAIL PROTECTED]> wrote:
I have multiple processes accessing the resulting DB. One of
I think this is a different question, unrelated to the previous
sqlite_open thread.
I'm in a WIN32 environment. I'm using:
h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ ||
FILE_SHARED_WRITE,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
to establish if my DB exists b
r may depend on the character of
the data in the table.
My own testing says that in the originally posed case, using "COLLATE
NOCASE" is just a titch faster than using LIKE.
D
Igor Tandetnik wrote:
Dixon Hutchinson
wrote:
I have an SQLite db with one TEXT column. That column and
I have an SQLite db with one TEXT column. That column and an INTEGER
column (not the rowid as this column is definitely not unique by itself)
are declared UNIQUE together.
CREATE TABLE foo (
bar TEXT,
p INTEGER,
rowid INTEGER PRIMARY KEY AUTOINCREMENT, -- I know... this is
implicit.
Consider the sequence below with SQLite 3.3.7 on Windows:
sqlite> CREATE TABLE xyzzy
...> (
...> comp TEXT,
...> parent INTEGER,
...> ROWID INTEGER PRIMARY KEY AUTOINCREMENT,
...> UNIQUE(parent, comp)
...> );
sqlite> .indices xyzzy
sqlite_autoindex_xyz
I am having difficulty getting a clean build under Visual Studio. I
believe I have followed the advice given at
http://www.sqlite.org/cvstrac/wiki?p=VsNetSolution.
I am getting lots of errors of the sort:
...\\sqlite3\\vdbemem.c(194) : warning C4267: '=' :
conversion from 'size_t' to 'int', p
I am running version 3.3.6 compiled with Visual Studio .net 2003 in a
single threaded app.
While using sqlite3_exec to execute a "COMMIT;", in run into a null
pointer problem in sqlite3_step.
I added tests for the null pointer to vdbeapi.c:
if (NULL == p) {
DebugBreak();
}
I did the math once, came to the same conclusion, then somewhere in the
last moths, forgot it and slipped into 32-bit mode for some reason :-[
Specifying AUTOINCREMENT should work fine for what I need.
[EMAIL PROTECTED] wrote:
Dixon Hutchinson <[EMAIL PROTECTED]> wrote:
If I ac
Brandon,
I think you tickled the right neurons. I misread the SQLite web page.
Below is the statement from the web page. The italics is how I
mis-interpreted it.
If no ROWID is specified on the insert, an appropriate ROWID is
created automatically. The usual algorithm is to give the n
h will fail, regardless of the
availability of empty rows that resulted from deletes. The behavior I
desire is that after "largest possible integer" is reach, "/the database
engine starts picking candidate ROWIDs at random until it finds one that
is not previously used/".
Mario Frasca
your point?
Mario Frasca wrote:
Dixon Hutchinson wrote:
[...] I was hoping to get the behavior specified at
http://www.sqlite.org/autoinc.html. where the AUTOINCREMENT keyword
is not used.
but you are getting quite exactly what is stated there:
«If you ever delete rows or if you ever c
probably shouldn't, since it seems to be causing you
problems.
If you want the column to be explicitly declared in your table, call it
something else like id. If you don't want to do that just use the keyword
ROWID in your queries, without declaring it as a column, and everything
wil b
I am having a problem with default behavior of ROWID not auto-incrementing.
I use the following to create my table:
CREATE TABLE abc
{
c TEXT,
p INTEGER,
t TEXT,
ROWID INTEGER PRIMARY KEY,
UNIQUE(p,c)
);
When I insert into the table using just c, p and t, I see that ROWID is
assi
When compiling under windows, I get lots of warning messages from Visual
Studio. All of the warnings have to do with worries about 64 bit vs 32
bit enties existing togeather, eg:
vdbemem.c(194) : warning C4267: '=' : conversion from 'size_t' to
'int', possible loss of data
I could just
18 matches
Mail list logo
