Re: [sqlite] WHERE clause
On Feb 6, 2008, at 1:00 PM, Pavel Dedik wrote: > Hi all, > > how can I escape the '%' in where clause? > I suggested the query may look like this: > > *SELECT * from tbl where field LIKE '%\%text'; Try: select * from a where a like '%\%text' escape '\'; Dan. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] WHERE clause
Hi all,
how can I escape the '%' in where clause?
For example:
*CREATE TABLE tbl (*
*field varchar(30)*
*);
INSERT INTO tbl VALUES ('first_prefix%text');
**INSERT INTO tbl VALUES ('second_prefixSEPARATORtext');
**INSERT INTO tbl VALUES ('third_prefix%text');
**INSERT INTO tbl VALUES ('third_prefix%something');*
Now I want to select each rows, that contains foolowed by
string '%text'.
I suggested the query may look like this:
*SELECT * from tbl where field LIKE '%\%text';
*and expected result is:
*
first_prefix**%text**
third_prefix%text
*
But SQlite does not understand the backslash character as escape
character, but it is a valid char.
Have you any ideas?
Thanks,
Palo
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.5 threading & vfs discussion
Crap, sent the wrong (older/bad) diff... Attached is
the right one.
Brad House wrote:
It appears as though os_unix.c references pthread routines directly
when SQLITE_THREADSAFE is defined (and not 0).
I think those routines should probably be abstracted like the mutex
routines. The problem lies if an alternate threading implementation
is preferred on a unix-like system (as is the case in some embedded
environments), or if the system doesn't support pthreads at all, but
an alternate threading implementation exists (ex. SCO OpenServer 5.0.6) and
you still want to maintain thread-safety. Currently the only alternative
is to reimplement the entire VFS for Unix when all that is really
desired is to switch out the thread routines.
I've attached a patch for discussion which creates 4 new functions:
sqlite3_thread_create, sqlite3_thread_join, sqlite3_thread_self,
and sqlite3_thread_equal
Their use is roughly equivalent to the pthread_* counterparts. The
main exception here is that I've expanded the API slightly because
Win32 differentiates between a thread id and a thread handle.
I've included a Win32 example implementation as well, even though
it is not used. 'make test' on Linux appears to return the same results
with this patch as it does without it.
Am I going about resolving this issue wrong? Any other thoughts
on this?
Thanks.
-Brad
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Index: src/mutex_unix.c
===
RCS file: /sqlite/sqlite/src/mutex_unix.c,v
retrieving revision 1.5
diff -u -r1.5 mutex_unix.c
--- src/mutex_unix.c28 Nov 2007 14:04:57 - 1.5
+++ src/mutex_unix.c6 Feb 2008 03:46:28 -
@@ -295,4 +295,27 @@
return p==0 || p->nRef==0 || pthread_equal(p->owner, pthread_self())==0;
}
#endif
+
+int sqlite3_thread_create(sqlite3_threadhandle_t *threadhandle,
sqlite3_threadid_t *threadid, void *(*start_routine)(void *), void *arg){
+ if (pthread_create((pthread_t *)threadhandle, NULL, start_routine, arg)
!= 0)
+ return(SQLITE_ERROR);
+ if (threadid)
+ *threadid = *threadhandle;
+ return(SQLITE_OK);
+}
+
+int sqlite3_thread_join(sqlite3_threadhandle_t threadhandle, void **value_ptr){
+ if (pthread_join((pthread_t)threadhandle, value_ptr) != 0)
+ return(SQLITE_ERROR);
+ return(SQLITE_OK);
+}
+
+sqlite3_threadid_t sqlite3_thread_self(){
+ return((sqlite3_threadid_t)pthread_self());
+}
+
+int sqlite3_thread_equal(sqlite3_threadid_t t1, sqlite3_threadid_t t2){
+ return(pthread_equal((pthread_t)t1, (pthread_t)t2));
+}
+
#endif /* SQLITE_MUTEX_PTHREAD */
Index: src/mutex_w32.c
===
RCS file: /sqlite/sqlite/src/mutex_w32.c,v
retrieving revision 1.5
diff -u -r1.5 mutex_w32.c
--- src/mutex_w32.c 5 Oct 2007 15:08:01 - 1.5
+++ src/mutex_w32.c 6 Feb 2008 03:46:28 -
@@ -216,4 +216,30 @@
int sqlite3_mutex_notheld(sqlite3_mutex *p){
return p==0 || p->nRef==0 || p->owner!=GetCurrentThreadId();
}
+
+
+int sqlite3_thread_create(sqlite3_threadhandle_t *threadhandle,
sqlite3_threadid_t *threadid, void *(*start_routine)(void *), void *arg){
+ *threadhandle = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)start_routine, arg, 0, threadid);
+ if (*threadhandle == NULL)
+ return(SQLITE_ERROR);
+ return(SQLITE_OK);
+}
+
+int sqlite3_thread_join(sqlite3_threadhandle_t threadhandle, void **value_ptr){
+ if (WaitForSingleObject((HANDLE)threadhandle, INFINITE) !=
WAIT_OBJECT_O)
+ return(SQLITE_ERROR);
+ if (value_ptr)
+ GetExitCodeThread((HANDLE)threadhandle, (LPDWORD)value_ptr);
+ CloseHandle((HANDLE)threadhandle);
+ return(SQLITE_OK);
+}
+
+sqlite3_threadid_t sqlite3_thread_self(){
+ return((sqlite3_threadid_t)GetCurrentThreadId());
+}
+
+int sqlite3_thread_equal(sqlite3_threadid_t t1, sqlite3_threadid_t t2){
+ return(t1 == t2);
+}
+
#endif /* SQLITE_MUTEX_W32 */
Index: src/os_unix.c
===
RCS file: /sqlite/sqlite/src/os_unix.c,v
retrieving revision 1.174
diff -u -r1.174 os_unix.c
--- src/os_unix.c 16 Jan 2008 17:46:38 - 1.174
+++ src/os_unix.c 6 Feb 2008 03:46:28 -
@@ -55,15 +55,6 @@
#endif /* SQLITE_ENABLE_LOCKING_STYLE */
/*
-** If we are to be thread-safe, include the pthreads header and define
-** the SQLITE_UNIX_THREADS macro.
-*/
-#if SQLITE_THREADSAFE
-# include
-# define SQLITE_UNIX_THREADS 1
-#endif
-
-/*
** Default permissions when creating a new file
*/
#ifndef SQLITE_DEFAULT_FILE_PERMISSIONS
@@ -98,7 +89,7 @@
unsigned char locktype; /* The type of lock held on this fd */
in
[sqlite] SQLite 3.5 threading & vfs discussion
It appears as though os_unix.c references pthread routines directly
when SQLITE_THREADSAFE is defined (and not 0).
I think those routines should probably be abstracted like the mutex
routines. The problem lies if an alternate threading implementation
is preferred on a unix-like system (as is the case in some embedded
environments), or if the system doesn't support pthreads at all, but
an alternate threading implementation exists (ex. SCO OpenServer 5.0.6) and
you still want to maintain thread-safety. Currently the only alternative
is to reimplement the entire VFS for Unix when all that is really
desired is to switch out the thread routines.
I've attached a patch for discussion which creates 4 new functions:
sqlite3_thread_create, sqlite3_thread_join, sqlite3_thread_self,
and sqlite3_thread_equal
Their use is roughly equivalent to the pthread_* counterparts. The
main exception here is that I've expanded the API slightly because
Win32 differentiates between a thread id and a thread handle.
I've included a Win32 example implementation as well, even though
it is not used. 'make test' on Linux appears to return the same results
with this patch as it does without it.
Am I going about resolving this issue wrong? Any other thoughts
on this?
Thanks.
-Brad
diff -ruN sqlite-3.5.5.orig/src/mutex_unix.c sqlite-3.5.5/src/mutex_unix.c
--- sqlite-3.5.5.orig/src/mutex_unix.c 2008-01-22 21:13:56.0 -0500
+++ sqlite-3.5.5/src/mutex_unix.c 2008-02-05 17:45:25.0 -0500
@@ -295,4 +295,27 @@
return p==0 || p->nRef==0 || pthread_equal(p->owner, pthread_self())==0;
}
#endif
+
+int sqlite3_thread_create(sqlite3_threadhandle_t *threadhandle,
sqlite3_threadid_t *threadid, void *(*start_routine)(void *), void *arg){
+ if (pthread_create((pthread_t *)threadhandle, NULL, start_routine, arg)
!= 0)
+ return(SQLITE_ERROR);
+ if (threadid)
+ *threadid = *threadhandle;
+ return(SQLITE_OK);
+}
+
+int sqlite3_thread_join(sqlite3_threadhandle_t threadhandle, void **value_ptr){
+ if (pthread_join((pthread_t)threadhandle, value_ptr) != 0)
+ return(SQLITE_ERROR);
+ return(SQLITE_OK);
+}
+
+sqlite3_threadid_t *sqlite3_thread_self(){
+ return((sqlite3_threadid_t)pthread_self());
+}
+
+int sqlite3_thread_equal(sqlite3_threadid_t t1, sqlite3_threadid_t t2){
+ return(pthread_equal((pthread_t)t1, (pthread_t)t2));
+}
+
#endif /* SQLITE_MUTEX_PTHREAD */
diff -ruN sqlite-3.5.5.orig/src/mutex_w32.c sqlite-3.5.5/src/mutex_w32.c
--- sqlite-3.5.5.orig/src/mutex_w32.c 2008-01-22 21:13:56.0 -0500
+++ sqlite-3.5.5/src/mutex_w32.c2008-02-05 17:45:30.0 -0500
@@ -216,4 +216,28 @@
int sqlite3_mutex_notheld(sqlite3_mutex *p){
return p==0 || p->nRef==0 || p->owner!=GetCurrentThreadId();
}
+
+
+int sqlite3_thread_create(sqlite3_threadhandle_t *threadhandle,
sqlite3_threadid_t *threadid, void *(*start_routine)(void *), void *arg){
+ *threadhandle = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)start_routine, arg, 0, threadid);
+ if (*threadhandle == NULL)
+ return(SQLITE_ERROR);
+ return(SQLITE_OK);
+}
+
+int sqlite3_thread_join(sqlite3_threadhandle_t threadhandle, void **value_ptr){
+ if (WaitForSingleObject((HANDLE)threadhandle, INFINITE) !=
WAIT_OBJECT_O)
+ return(SQLITE_ERROR);
+ GetExitCodeThread((HANDLE)threadhandle, (LPDWORD)value_ptr);
+ return(SQLITE_OK);
+}
+
+sqlite3_threadid_t *sqlite3_thread_self(){
+ return((sqlite3_threadid_t)GetCurrentThreadId());
+}
+
+int sqlite3_thread_equal(sqlite3_threadid_t t1, sqlite3_threadid_t t2){
+ return(t1 == t2);
+}
+
#endif /* SQLITE_MUTEX_W32 */
diff -ruN sqlite-3.5.5.orig/src/os_unix.c sqlite-3.5.5/src/os_unix.c
--- sqlite-3.5.5.orig/src/os_unix.c 2008-01-22 21:13:56.0 -0500
+++ sqlite-3.5.5/src/os_unix.c 2008-02-05 17:45:20.0 -0500
@@ -55,15 +55,6 @@
#endif /* SQLITE_ENABLE_LOCKING_STYLE */
/*
-** If we are to be thread-safe, include the pthreads header and define
-** the SQLITE_UNIX_THREADS macro.
-*/
-#if SQLITE_THREADSAFE
-# include
-# define SQLITE_UNIX_THREADS 1
-#endif
-
-/*
** Default permissions when creating a new file
*/
#ifndef SQLITE_DEFAULT_FILE_PERMISSIONS
@@ -98,7 +89,7 @@
unsigned char locktype; /* The type of lock held on this fd */
int dirfd;/* File descriptor for the directory */
#if SQLITE_THREADSAFE
- pthread_t tid;/* The thread that "owns" this unixFile */
+ sqlite3_threadid_t tid;/* The thread that "owns" this unixFile */
#endif
};
@@ -139,7 +130,7 @@
** testing and debugging only.
*/
#if SQLITE_THREADSAFE
-#define threadid pthread_self()
+#define threadid sqlite3_thread_self()
#else
#define threadid 0
#endif
@@ -161,9 +152,9 @@
** transferOwnership() function below for additional information
*/
#if SQLITE_THREADSAFE
-# define SET_THREADID(X) (X)->tid = pthread_self()
+# def
Re: [sqlite] Solaris make test compilation error
BTW, in Solaris Nevada (build 44) sched_yield() has moved into libc. Which is why SQLite 3.5.5 builds without errors on Solaris Nevada. Auxiliary filters remain in librt so that linking with -lrt will work on all versions of Solaris. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Is it possible to do this using only SQL?
Of course it's possible, it's almost exactly as your pseudo-sql Greetings! Dennis Volodomanov escribió: > Hello all, > > > > I'm not sure if it's possible to do this using only SQL, so I'd like to > ask: > > > > I need to add a column to a table which will be populated with data from > another column in that table, but converted to lower-case. > > > > So, in pseudo-code I need to do this: > > > > ALTER TABLE MyTable ADD COLUMN LowerCase > > > > Let's say the schema becomes: > > > > MyTable(OriginalCase, LowerCase) > > > > So - something like the following: > > > > FOR EACH ROW IN MyTable > > UPDATE MyTable SET LowerCase = lower(OriginalCase); > > > > Is that possible? If not, I'll have to do it in the code, but that will > probably be slower and I'm expecting to have tens of thousands of rows. > > > > Thanks in advance for any ideas and suggestions. > > > >Dennis > > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Mailing List Changes
[EMAIL PROTECTED] wrote: > Doug Currie <[EMAIL PROTECTED]> wrote: >>> Please set the list so default reply is to the list. >> http://www.unicom.com/pw/reply-to-harmful.html >> > > One finds various screeds such as the one Doug references > above. And on the configuration screen for GNU mailman, > it "strongly recommends" that replys be to the author and > not to the list. > > And yet nearly everyone I know loaths that behavior. The > overwhelming majority of users prefer mailing list replies > to go back to the mailing list *only*. > > I think we have things configured now so that replies go > back to the list instead of the to original author. There > are likely other settings that will need to be adjusted as > we move forward. Please let me know if you see anything > unusual. > > In a semi-related rant: Setting up a new mailing list is > *way* harder than it needs to be. Way, Way harder. In order > to go from ezmlm to GNU mailman, we had to prototype the > setup on a separate machine, then spend a day debugging > the setup after transferring it to the production machine. > A day. For a mailing list. And this is with mailing list > software that is suppose to be *easy* to configure. I > tremble to thing what the difficult-to-configure software > must be like. > > To tie this back to the original question, when people who > write mail handling and mailing list software get their > programs to the point where I can set up a new mail system > and a new mailing list manager on a system in 15 minutes or > less with reasonable assurance that I have not opened major > security holes in the system, then, perhaps, I will be in a > better mood to listen to their polemics on Reply-To field > munging. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > Some very apt comments. Having been similarly irritated by the mindless complexity of setting up mailman to manage a simple list I empathize. The ease and simplicity of installing Sqlite is in stark comparison and no accident but the reward of a lot of discipline in paring away complexity, filtering out ornamentation and responding thoughtfully to user's experiences and suggestions. JS There are no victims, only volunteers. > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] DBD::SQLite 1.14 prepare_cached bug?
> Conclusion: avoid using $dbh->disconnect() for DBD::SQLite, instead use "undef $dbh". Good info. I don't use usually use prepare_cached(), but I'm adding your observation to my notes for when I'm trying to resolve the same. > What kind of SQL injection is possible here? Good point. Not sure. Possibly none because only the first statement in the SQL is compiled. Thanks! -Clark - Original Message From: Alexander Batyrshin <[EMAIL PROTECTED]> To: General Discussion of SQLite Database Sent: Monday, February 4, 2008 8:30:10 PM Subject: Re: [sqlite] DBD::SQLite 1.14 prepare_cached bug? I think i found solution. The problem is that DBD::SQlite->disconnect() method execute sqlite3_close() function. This function return SQLITE_BUSY in case if there are any active statement. >From API: "Applications should finalize all prepared statements and close all BLOBs associated with the sqlite3 object prior to attempting to close the sqlite3 object." Currently DBD::SQLite can finalize statements only via DESTROY method. In simplest case you can always use "undef $sth" or wait untill it goes out of scope which will finalize statement. But if you prepared statement via cache (prepare_cached) it will not work for you, because statement is till inside DBI cache. In this case we can call DESTROY on our cached statement only via DESTROY for database handler. And we can achieve it by "undef $dbh". "undef $dbh" - will close all cached statements and close database without any errors. Conclusion: avoid using $dbh->disconnect() for DBD::SQLite, instead use "undef $dbh". On Feb 5, 2008 3:37 AM, Alexander Batyrshin <[EMAIL PROTECTED]> wrote: > Hello, > > > What do you expect to see? From the code, I'm guessing something like: > > This is "test-case" program for testing DBD-SQLite behavior. Dumper is > only for be sure, that data was read correctly from database. > > > If you're just trying to silence the "closing dbh with active handles..." > > warning, "undef $sth;" usually works for me. I see you have it commented > > in your code? DBD-SQLite has spewed this warning for as long as I can > > remember. And $dbh->finish; doesn't squash it. > > Yes, this is what I want. "undef $sth" doesn't work for statement that > was prepare_cached. Because statement is still allocated inside $dbh > buffers for cached statement. > > > > Also, I see you could save the sprintf and $dbh->quote by changing to: > > > > my $sql = "select a_session from sessions where id = ?"; > > my $sth = $dbh->prepare_cached($sql); > > $sth->execute($sid); > > Yes, i know, but this is only "test-case" program without any > optimization and code-beauty refactoring. > > > In your example, the value of $sid, after doing the $dbh->quote, is parsed > > by the SQL parser. Doing that has always been unreliable for me, and it's > > generally open to SQL injection. In the example above, $sid isn't > > parsed/compiled by SQLite, it's just passed as-is as a bound parameter > > after $sth is prepared. > > What kind of SQL injection is possible here? > > > Are you building a web session manager using SQLite as the data store? How > > is Storable working for you? I usually just use Data::Dumper, and eval the > > stored hash. But doing the eval has always worried me :-)) > > It's work without any problems for me handling over 150k hits/day. > > > > -- > Alexander Batyrshin aka bash > bash = Biomechanica Artificial Sabotage Humanoid > -- Alexander Batyrshin aka bash bash = Biomechanica Artificial Sabotage Humanoid ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Select Error - SQL error: unrecognized token: ""select"
Carl Lindgren wrote: Could someone please give me a clue on why I'm getting this message "SQL error: unrecognized token: ""select" " from the command line using Bash for Dos and a sh script? Thanks for any help, Carl -- Carl Lindgren C. R. Lindgren Consulting / Business on the Desktop Using Bash for Dos and MS-KSH - >>>Script<<< #!/foobar/bash desired_data=Test DB_Path="/foobar/foo_DB" DB_Statement="\"select Data_Value from Table_Name where Data_Key = '$desired_data' ; \"" Sql_return=$(sqlite3.exe "$DB_Path" $DB_Statement) echo $Sql_return >>>End Script<<< >>>OUTPUT<<< sqlite3 /foobar/foo_DB "select Data_Value from Table_Name where Data_Key = 'Test' ; " SQL error: unrecognized token: ""select" >>> END OUTPUT<<< -- Carl Lindgren C. R. Lindgren Consulting / Business on the Desktop ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users I figured it out... DB_Path=c:/foobar/foo_DB DB_Statement="select Data_Value from Table_Name where Data_Key = '$desired_data' ; " Sql_return=$(sqlite3.exe $DB_Path "$DB_Statement") echo $Sql_return I had the quotes wrong. -- Carl Lindgren C. R. Lindgren Consulting / Business on the Desktop ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Update value from either database table?
On Feb 4, 2008 1:56 PM, Gussimulator <[EMAIL PROTECTED]> wrote: > I have a field I need to update given a condition, but I don't know wether > the condition occurs in table A or table B, how can I perform this query? > > I have 2 identical tables in design, but one contains system data and the > other one contains user data... On my update routine (in C) I have to > increase an INTEGER field from either table given a condition... The thing > is, the condition could be present on both tables... what should I do?? > > Thanks! I'm no database expert, but why not merge them with a single table, like this? [[ create table MyTable (foo, bar, baz, user_data INTEGER) ]] with user_data=0 for the "system" data, and user_data=1 for the "user" data. Unique/Primary-key constraints can be kept unique by appending the user_data column to the index (how well does SQLite perform with regard to multi-column indices, btw?) -- -- Stevie-O Real programmers use COPY CON PROGRAM.EXE ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] After sqlite3_create_function, calling function returns no such function
"Joe Cosby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > rc = sqlite3_create_function16(db, L"TimeToHms", 1, SQLITE_ANY, NULL, > &sqliteTimeToHms, NULL, NULL); > > Which returns SQLITE_OK, then later I have this query > > wstring testSql = L" select TimeToHms(time)" > L" from meta_data_master" > L" where meta_data_master.id <= 100"; > > And try to execute it: > > sqlite3_prepare16_v2(db, &testSql[0] ,-1, &pStmt,&pzTail); > > And get the error message "no such function: TimeToHms" Do you pass the same connection handle both to sqlite3_create_function16 and to sqlite3_prepare16_v2? Functions are registered per-connection. I don't see anything wrong in your code otherwise. Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Selecting ID for MAX() + GROUP BY
Dnia wtorek, 5 lutego 2008, Gerry Snyder napisał:
> P Kishor wrote:
> > sqlite> select t.* from test t join (select name, max(weight) as m
> > from test group by name) w on t.weight = w.m and t.name = w.name;
>
[...]
>
> select * from test join (select name as n, max(weight) as m from test
> group by name) where name = n and weight = m;
Thank You very much.
I know, that GROUP BY should have all SELECT fields, but thought, that he will
choose row with MAX(), not the last row in dataset.
With the problem of "ties" I suppose, the easiest (but not SQL) way to make
for() loop for each group (SELECT DISTINCT name), and do
SELECT * FROM test WHERE name='{loop name}' ORDER BY weight DESC LIMIT 1
vip;
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [3.5.4] Fails importing CSV file
Dennis At 11:01 04/02/2008 -0700, Dennis Cote wrote: >You will need to do your import in two steps. First import into a temp >table without the integer primary key column. Thanks a bunch for the explanation and the how-to. The accented characters are displayed funny when SELECTed in the DOS command-line sqlite3, but data show OK when viewed in a web browser. Guess it's DOS and Windows using different charsets/pagescodes. Thanks again G. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Encoding problem indeed...
I have found out what is the matter. In SQLite3 encoding works fine (I tried it by manually inserting values thrum SQlite browser - which exclude application error), but in older version of SQLite (which I used for my database by not knowing which version it is) it doesn't work. Since I have read that only newer versions of php (5.1+) support sqlite3, and I still have php 4.3 on my web server, I will have to transer my db into mysql :( SQLite did the job, was simple to use, light, but only when it comes to Latin encodings. SQLite3 is one I shall use when I get php update on web server. Thanx for help anyway! -- Best regards, Vladimir Mincev ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
