[sqlite] 答复: Error: database is locked on redhat6

I using the -o nolock option when I mount nfs storage, and it works, but I am not sure what will cause by this option in future... Tianjing -邮件原件- 发件人: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 代表 Simon Slavin 发送时间: 2012年4月22日 4:25 收件人: General Discussion

Re: [sqlite] sqlite3 .dump file does not recreate database

On Sat, Apr 21, 2012 at 02:07:17PM -0700, Kyle McKay scratched on the wall: > Is there some way to modify only the SQLite3 shell's .dump utility > to use 17g when dumping IEEE754 values (leaving all the other > behavior unchanged)? Not easily. Last time I checked, the shell uses

Re: [sqlite] sqlite3 .dump file does not recreate database

On 21 Apr 2012, at 10:07pm, Kyle McKay wrote: > Is there some way to modify only the SQLite3 shell's .dump utility to use 17g > when dumping IEEE754 values (leaving all the other behavior unchanged)? The source to the shell tool is included in the full (not amalgamated)

[sqlite] sqlite3 .dump file does not recreate database

The "Error: near line 10: column val is not unique" output is unexpected when loading the created .dump file. This session demonstrates the issue: $ /tmp/sqlite3 SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> SELECT

Re: [sqlite] Error: database is locked on redhat6

On 21 Apr 2012, at 7:05pm, Kit wrote: > 2012/4/21 田晶 : >> Hi all, >> I have a question when using sqlite on redhat6, I put the sqlite file on nfs >> storage(this storage is shared by isilion), the client using redhat 6 x64. >> Tianjing > > Never use

Re: [sqlite] BUG: No reliable way to import strings from a file

On 21 Apr 2012, at 6:48pm, Pavel Ivanov wrote: The type you probably want is TEXT. >>> >>> The rules are such that VARCHAR column also gets TEXT affinity. >> >> I thought it was worth explaining to him what was really going on. Didn't >> want him going through 30

Re: [sqlite] National characters in database names on linux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/12 04:27, Richard Hipp wrote: > The developer of Calibre is mistaken. It also isn't the first time: http://lwn.net/Articles/465311/ Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux)

Re: [sqlite] Error: database is locked on redhat6

2012/4/21 田晶 : > Hi all, > I have a question when using sqlite on redhat6, I put the sqlite file on nfs > storage(this storage is shared by isilion), the client using redhat 6 x64. > Tianjing Never use SQLite on NFS storage. -- Kit

Re: [sqlite] BUG: No reliable way to import strings from a file

2012/4/21 Braddock Gaskill : > > Hi Guys, > > This may be a known issue.  I know sqlite isn't known for it's CSV > support. > But it makes CSV .import almost useless for string types, even if you know > there will be no embedded commas or other delimiters. > > There is NO

Re: [sqlite] BUG: No reliable way to import strings from a file

>>> The type you probably want is TEXT. >> >> The rules are such that VARCHAR column also gets TEXT affinity. > > I thought it was worth explaining to him what was really going on.  Didn't > want him going through 30 databases changing hundreds of fields to VARCHAR > when he should be changing

[sqlite] Error: database is locked on redhat6

Hi all, I have a question when using sqlite on redhat6, I put the sqlite file on nfs storage(this storage is shared by isilion), the client using redhat 6 x64. When I search the database, I got the following error: [root@3-1 yubiao]# sqlite3 .UPLOAD.db SQLite version 3.6.20 Enter ".help" for

Re: [sqlite] BUG: No reliable way to import strings from a file

On 21 Apr 2012, at 5:03pm, Igor Tandetnik wrote: > Simon Slavin wrote: >> On 21 Apr 2012, at 2:04am, Braddock Gaskill wrote: >> >>> I now see that if I properly define the field type as VARCHAR instead of >>> STRING that the

Re: [sqlite] BUG: No reliable way to import strings from a file

Simon Slavin wrote: > On 21 Apr 2012, at 2:04am, Braddock Gaskill wrote: > >> I now see that if I properly define the field type as VARCHAR instead of >> STRING that the CSV is correctly parsed. > > SQLite doesn't have either of those types. It's

Re: [sqlite] BUG: No reliable way to import strings from a file

On 21 Apr 2012, at 2:04am, Braddock Gaskill wrote: > I now see that if I properly define the field type as VARCHAR instead of > STRING that the CSV is correctly parsed. SQLite doesn't have either of those types. It's doing its best to guess what you mean. Take a look

Re: [sqlite] BUG: No reliable way to import strings from a file

I now see that if I properly define the field type as VARCHAR instead of STRING that the CSV is correctly parsed. -braddock On Fri, 20 Apr 2012 17:54:04 -0700, Braddock Gaskill wrote: > Hi Guys, > > This may be a known issue. I know sqlite isn't known for it's CSV >

[sqlite] BUG: No reliable way to import strings from a file

Hi Guys, This may be a known issue. I know sqlite isn't known for it's CSV support. But it makes CSV .import almost useless for string types, even if you know there will be no embedded commas or other delimiters. There is NO SAFE WAY to import string fields using sqlite's .import function. If

Re: [sqlite] National characters in database names on linux

On Sat, Apr 21, 2012 at 1:59 AM, Jānis wrote: > Hi! > > I am using library management software Calibre having SQlite as dbms and > found that at least on linux I can not give the names to my "shelves" using > national characters like ā, ē, ī, š, ķ etc. I was informed by the

Re: [sqlite] National characters in database names on linux

Jānis wrote: I am using library management software Calibre having SQlite as dbms and found that at least on linux I can not give the names to my "shelves" using national characters like ā, ē, ī, š, ķ etc. I was informed by the developer of Calibre that it is limitation introduced by SQLite on