Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Jan Nijtmans]

2013/12/17 margave :
> Well, I gave up on sqlite inside of Cygwin.
>
> I found a standalone sqlite3.exe that does not depend upon (or install with)
> Cygwin.
> It's from http://www.sqlite.org
> One executable, no .dlls ... and it just runs, no problems.

I think I know what's the problem: The SQLite version included
in Fossil 1.27 had a bug in the calculation of the temp path:
It should be "/tmp/etilqs." but the slash was missing, so
actual temporary files were named "/tmpetilqs.". Whether
it works or not depends on your rights on the '/' directory.

Workaround: Create a dummy directory "foo" inside
/tmp, and set the SQLITE_TMPDIR environment
variable to "/tmp/foo". Then temporary files should
be created in the right directory (even though the name
is not right) which should make it work.

This SQLite bug is already fixed here:
   
so next fossil version should be OK.

Thanks!
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Jan Nijtmans]

2013/12/17 margave :
> Well, I gave up on sqlite inside of Cygwin.
>
> I found a standalone sqlite3.exe that does not depend upon (or install with)
> Cygwin.
> It's from http://www.sqlite.org
> One executable, no .dlls ... and it just runs, no problems.

For most situation, indeed this .exe should work fine. Still
I'm sure that Jari Aalto (Cygwin's fossil maintainer) will be
interested to know what's the problem. I regularly
compile Fossil on Cygwin, and I don't see the problems you
mention.

Anyway, Thanks for your report!
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[margave]

Well, I gave up on sqlite inside of Cygwin.

I found a standalone sqlite3.exe that does not depend upon (or install with)
Cygwin.
It's from http://www.sqlite.org
One executable, no .dlls ... and it just runs, no problems.



--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/An-unable-to-open-database-file-error-that-has-nothing-to-do-with-opening-database-file-tp69199p72915.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Kees Nuyt]

On Sun, 15 Dec 2013 07:28:52 -0800 (PST), margave  wrote:

>Addendum: I ran "file" on sqlite3.exe ...
>
>On computer B (where sqlite3 works): PE32 executable (console) Intel 80386,
>for MS Windows
>On computer A (where it does not):   PE32+ executable (console) x86-64, for
>MS Windows

Well, something is not completely the same.

I'd start with examining :

* Exact windows version (start/computer/system properties)
* Exact cygwin version
* Package choices in cygwin
* sqlite3 --version
* Security properties of the database file
(roperties / security / advanced / etc.)

Remark: Do you know that concurrent access to sqlite files 
on network shared filesystems is not safe?

-- 
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Jan Nijtmans]

2013/12/15 margave :
> I noticed that the sqlite3.exe file on computer A has a different cksum than
> the one on computer B. (Seems odd! The Cygwin installer shows the same
> version on both!)
Which version? SQLite 3.8.2-2?
Apparently, you are running Cygwin on A and
Cygwin64 on B. SQLite is compiled with
exactly the same source-code on Cygwin
and Cygwin64, but with a different compiler.
So this suggests it isn't a problem in SQLite
but either in the compiler (unlikely), ore in
cygwin1.dll. Hard to tell without some more
information.

You could try "sqlite3  -vfs win32-longpath"
which uses the win32 API in stead of the cygwin
API to open the file. Does this make a difference?

Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[margave]

Addendum: I ran "file" on sqlite3.exe ...

On computer B (where sqlite3 works): PE32 executable (console) Intel 80386,
for MS Windows
On computer A (where it does not):   PE32+ executable (console) x86-64, for
MS Windows



--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/An-unable-to-open-database-file-error-that-has-nothing-to-do-with-opening-database-file-tp69199p72907.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[margave]

I have the same problem. I have .sqlite db files, and I wish to read them
with sqlite3.exe (under Cygwin x64 on Win 7 x64).  I want this to work on
both computer A and computer B. (Both have the same Win 7 and Cygwin
installed).

But it only works on computer B, not on computer A.

I have the SAME .sqlite db file on the desktop on both computers. I run
sqlite3 filename from a Cygwin bash shell (under mintty). As soon as I enter
a sql command (select * from xxx;) I get the "unable to open database file
error".

The two computers have fs mounts on one-another. So I can run sqlite3 on
computer B, referencing the db file on computer A ... and it works, just
like when I reference the local file.

But none of this works when running on computer A. (And ... I tried it from
a CMD prompt, as suggested above. No dice.)

I noticed that the sqlite3.exe file on computer A has a different cksum than
the one on computer B. (Seems odd! The Cygwin installer shows the same
version on both!) Anyway, I copied the working exe from B over to A. And it
doesn't run at all on A.

So I uninstalled sqlite on A and reinstalled. Still no go.

I'm confuzzled.



--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/An-unable-to-open-database-file-error-that-has-nothing-to-do-with-opening-database-file-tp69199p72906.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Warren Young]

On 6/9/2013 05:21, Stephen Chrzanowski wrote:

Warren, when you say "we may be switching the official builds back to Unix
mode soon", you're referring only to the Cygwin builds, correct?


Of course.


The Win32 versions will still be generated as is?


I only maintain the Cygwin packages.  I have no control over packages 
that appear on sqlite.org.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Warren Young]

On 6/9/2013 07:42, Philip Goetz wrote:


/path/to/sqlite3.exe db.sqlite

on the command line just hangs.


It sounds like you're trying to do that from Cygwin's mintty shell.  The 
Windows Console infrastructure isn't particularly robust, so when a 
third-party program like mintty tries to run a native Win32 console app, 
it sometimes does things like what you're seeing.


Run the native Win32 sqlite3.exe from cmd.exe instead.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Keith Medcalf]

MS-DOS or DOS box is a misnomer.  It is usually referred to as a "DOS Prompt" 
by those who think in clickety-pokery mode only.  As far as I know, there is no 
"DOS" version of sqlite3.

The Windows command line is a native Win32 Console Mode executable.  It will 
run in any environment that supports the execution of Win32 Console Mode 
applications.  

>From your description it sounds like the environment you are using cannot 
>execute Win32 Console Mode applications.  This is probably a restriction of 
>the shell you are using.

---
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org


> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Philip Goetz
> Sent: Sunday, 09 June, 2013 14:21
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] An "unable to open database file" error that has
> nothing to do with opening database file
> 
> My sqlite db seems to work when I access it from perl or java. It's
> only when I use the cygwin executable on the command line that it
> doesn't work.  So all I really need to know is, How can I use the
> available Windows sqlite binary from
> http://www.sqlite.org/download.html on the cygwin command line?
> 
> The documentation says,
> 
> At a shell or DOS prompt, enter: "sqlite3 test.db". This will create a
> new database named "test.db".
> 
> And this indeed works, from the DOS prompt. But from the cygwin
> command line, it just hangs.
> 
> MS-DOS is not a usable work environment.  How can I download or build
> an executable that will work from the cygwin command line?
> ___
> 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] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

Also, I can't use the precompiled Windows binary to open databases
created with whatever sqlite version the Cygwin Perl DBI uses, but I
can use the cygwin sqlite3.exe to open databases created with the
precompiled Windows binary.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

My sqlite db seems to work when I access it from perl or java. It's
only when I use the cygwin executable on the command line that it
doesn't work.  So all I really need to know is, How can I use the
available Windows sqlite binary from
http://www.sqlite.org/download.html on the cygwin command line?

The documentation says,

At a shell or DOS prompt, enter: "sqlite3 test.db". This will create a
new database named "test.db".

And this indeed works, from the DOS prompt. But from the cygwin
command line, it just hangs.

MS-DOS is not a usable work environment.  How can I download or build
an executable that will work from the cygwin command line?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

Okay, but is there a simple answer for me, like getting a different
build (eg the standard windows build)?

I'm confused about the windows builds. There's a "sqlite-shell-win32
command-line shell", which looks like an executable, but it doesn't in
fact work from the command line.  I can only open a database with it
through the windows GUI.  I have to configure windows to "Open files
of this type with [sqlite3.exe]", then rename the sqlite file to end
in .sql or whatever you designated, then click on it.  Just typing

/path/to/sqlite3.exe db.sqlite

on the command line just hangs.

The other build available is a DLL, and I don't know how to use a DLL.

On Fri, Jun 7, 2013 at 1:48 PM, Warren Young  wrote:
> On 6/6/2013 21:56, Philip Goetz wrote:
>>
>>
>> I think the problem is that the Cygwin distribution has the wrong
>> version of SQLite, one built for unix.
>
>
> Nope.  And even if true, it wouldn't be the right explanation.
>
> There are two major ways to build SQLite on Cygwin:
>
> 1. By default, building SQLite under Cygwin gets you a special Cygwin-aware
> mode, where SQLite bypasses the Cygwin DLL for some things, calling the
> Win32 API directly.  This is how the current[*] official binaries in the
> Cygwin distro are built.  Such a build still uses POSIX APIs for opening
> files, though, so the paths go to the Cygwin DLL first, and then after
> translation, to the Win32 API.  Since such a built knows its running on
> Windows, it shouldn't be using illegal characters in generated file names.
>
> 2. You can also build SQLite in a pure POSIX mode, with no direct calls to
> Win32 at all.  This mode is more compatible with other POSIX programs
> running under Cygwin, but less compatible with native Win32 builds of
> SQLite.  This distinction is irrelevant, however, because the file opening
> path is the same as with the Cygwin-aware build.
>
>
> [*] (You can find test builds of SQLite for Cygwin built in Unix mode
> instead of Cygwin mode, but there hasn't been an official one in many
> months, which was quickly replaced due to the problems it caused.  We may be
> switching the official builds back to Unix mode soon, providing we can fix
> those problems, since the special Cygwin mode of SQLite causes its own
> problems.  It's one of those "having your cake and eating it too" kinds of
> things.)
>
> ___
> 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] An "unable to open database file" error that has nothing to do with opening database file

[Stephen Chrzanowski]

Warren, when you say "we may be switching the official builds back to Unix
mode soon", you're referring only to the Cygwin builds, correct?  The Win32
versions will still be generated as is?

Personally, I've built a very specific VM to build from the Amalgamation
source, however, I also keep the official DLL kicking around as well.


On Fri, Jun 7, 2013 at 1:48 PM, Warren Young  wrote:

> On 6/6/2013 21:56, Philip Goetz wrote:
>
>>
>> I think the problem is that the Cygwin distribution has the wrong
>> version of SQLite, one built for unix.
>>
>
> Nope.  And even if true, it wouldn't be the right explanation.
>
> There are two major ways to build SQLite on Cygwin:
>
> 1. By default, building SQLite under Cygwin gets you a special
> Cygwin-aware mode, where SQLite bypasses the Cygwin DLL for some things,
> calling the Win32 API directly.  This is how the current[*] official
> binaries in the Cygwin distro are built.  Such a build still uses POSIX
> APIs for opening files, though, so the paths go to the Cygwin DLL first,
> and then after translation, to the Win32 API.  Since such a built knows its
> running on Windows, it shouldn't be using illegal characters in generated
> file names.
>
> 2. You can also build SQLite in a pure POSIX mode, with no direct calls to
> Win32 at all.  This mode is more compatible with other POSIX programs
> running under Cygwin, but less compatible with native Win32 builds of
> SQLite.  This distinction is irrelevant, however, because the file opening
> path is the same as with the Cygwin-aware build.
>
>
> [*] (You can find test builds of SQLite for Cygwin built in Unix mode
> instead of Cygwin mode, but there hasn't been an official one in many
> months, which was quickly replaced due to the problems it caused.  We may
> be switching the official builds back to Unix mode soon, providing we can
> fix those problems, since the special Cygwin mode of SQLite causes its own
> problems.  It's one of those "having your cake and eating it too" kinds of
> things.)
>
> __**_
> 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] An "unable to open database file" error that has nothing to do with opening database file

[Warren Young]

On 6/6/2013 21:56, Philip Goetz wrote:


I think the problem is that the Cygwin distribution has the wrong
version of SQLite, one built for unix.


Nope.  And even if true, it wouldn't be the right explanation.

There are two major ways to build SQLite on Cygwin:

1. By default, building SQLite under Cygwin gets you a special 
Cygwin-aware mode, where SQLite bypasses the Cygwin DLL for some things, 
calling the Win32 API directly.  This is how the current[*] official 
binaries in the Cygwin distro are built.  Such a build still uses POSIX 
APIs for opening files, though, so the paths go to the Cygwin DLL first, 
and then after translation, to the Win32 API.  Since such a built knows 
its running on Windows, it shouldn't be using illegal characters in 
generated file names.


2. You can also build SQLite in a pure POSIX mode, with no direct calls 
to Win32 at all.  This mode is more compatible with other POSIX programs 
running under Cygwin, but less compatible with native Win32 builds of 
SQLite.  This distinction is irrelevant, however, because the file 
opening path is the same as with the Cygwin-aware build.



[*] (You can find test builds of SQLite for Cygwin built in Unix mode 
instead of Cygwin mode, but there hasn't been an official one in many 
months, which was quickly replaced due to the problems it caused.  We 
may be switching the official builds back to Unix mode soon, providing 
we can fix those problems, since the special Cygwin mode of SQLite 
causes its own problems.  It's one of those "having your cake and eating 
it too" kinds of things.)

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Warren Young]

On 6/5/2013 11:25, Philip Goetz wrote:

I suspect it's intercepting calls to the filesystem.


Yes, the Cygwin DLL does translate POSIX paths to Windows paths 
internally.  Then it calls the native APIs for you to give you the POSIX 
effect you asked for via the DLL.


Part of the fun here is that the Cygwin DLL *also* tries to cope with 
Windows style paths, and the Windows APIs *also* sometimes cope with 
forward slashes.


Because relying on this can cause all kinds of havoc, the DLL now warns 
you about it the first time you try it in a session:


$ ls c:/
cygwin warning:
  MS-DOS style path detected: c:/
  Preferred POSIX equivalent is: /c
  CYGWIN environment variable option "nodosfilewarning" turns off this 
warning.

  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

Not all code paths cause this warning, though, and sometimes the hack to 
cope with backslashes doesn't get run at all.  I wouldn't expect it to 
even try in this case, since the first part of the path looks POSIXy.


Bottom line, I suspect there is a bug in SQLite here.  It shouldn't be 
using backslashes in a Cygwin build.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Warren Young]

On 6/4/2013 09:22, Philip Goetz wrote:


Is it caused by using a 32-bit sqlite3?


> How does a 32-bit app access a 5G file?

According to https://www.sqlite.org/limits.html, SQLite doesn't really 
have a 32-bit limit.  It's not trying to load all 5 GiB into RAM at 
once.  It manipulates the DB file in chunks, so the limit is in the 
terabytes, regardless of platform.



Is there a 64-bit Windows or Linux SQLite available?


There is a 64-bit Cygwin in development, which you can download here:

ftp://cygwin.com/pub/cygwin/64bit/

It is far from complete, but my SQLite packages are already in it.

I'd suggest that you try one or both of these things first, though:

1. Say "pragma temp_store=2" before your other SQL commands.  This will 
force SQLite to use in-memory temporary tables, avoiding disk.  It may 
be that this will bypass the bug that causes the error.


If this succeeds, I'd like to hear back.  There's currently been some 
speculation on the Cygwin mailing list as to whether in-memory temp 
files are suitable for such large DBs on 32-bit systems.  It would be 
nice to have a concrete test that shows that it does work.


2. Try the 32-bit Cygwin SQLite testing packages, here:

http://etr-usa.com/cygwin/sqlite3/

You may need to download up to 4 different files, three of which are 
buried a level deep in that tree.  Basically, you want to unpack any of 
the files called *3.7.17-2* into the root of your Cygwin tree.  Only 
download files corresponding to the ones you already have downloaded. 
You probably haven't installed the repo version of the -debuginfo 
package already, for example, so don't bother installing the test 
version, either.


These test packages have a purpose entirely different from what it 
sounds like your issue is, but they happen to be built with the 
"TEMP_STORE=2" mode by default.  (Don't count on this build choice to 
make it to the official release.  I haven't decided yet.)


For what it's worth, the main purpose of these packages is that they are 
trying to make Cygwin SQLite switchable between POSIX or BSD advisory 
locks and Windows mandatory locks.  The current method interoperates 
well with native Windows SQLite, but not with programs ported to Cygwin 
that assume POSIX advisory locks.  To test this new feature, you need to 
install Cygwin 1.7.19.  You should also skim this Cygwin mailing list 
thread:


http://cygwin.com/ml/cygwin/2013-06/msg00034.html

If nothing else, the second half of this post:

http://cygwin.com/ml/cygwin/2013-06/msg00078.html

Beware, these packages do not pass the SQLite test suite.  (That mainly 
because no one has yet gotten the test suite to run under Cygwin!)  Back 
up your DB first!

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

I'm using Cygwin, a unix shell that runs under Windows. I don't know
how cygwin interacts with the OS, but I have to specify cygwin-style
paths rather than windows-style paths in perl to connect to the SQLite
db, so I suspect it's intercepting calls to the filesystem.

Using \ and * as characters in a filename is a spectacularly bad idea,
even if Windows lets you do it this year.

On Wed, Jun 5, 2013 at 12:57 PM, Stephen Chrzanowski
 wrote:
> Good to know, however note that he's using /var/tmp which to me looks like
> linux, not windows.
>
>
> On Wed, Jun 5, 2013 at 5:41 AM, Clemens Ladisch  wrote:
>
>> Stephen Chrzanowski wrote:
>> > I think the problem is with the \ (Note direction) as this makes the next
>> > character a literal character.
>>
>> Only for software that interprets backslashes in this way.
>>
>> The Windows file name parser doesn't.
>>
>>
>> Regards,
>> Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Stephen Chrzanowski]

Good to know, however note that he's using /var/tmp which to me looks like
linux, not windows.


On Wed, Jun 5, 2013 at 5:41 AM, Clemens Ladisch  wrote:

> Stephen Chrzanowski wrote:
> > I think the problem is with the \ (Note direction) as this makes the next
> > character a literal character.
>
> Only for software that interprets backslashes in this way.
>
> The Windows file name parser doesn't.
>
>
> Regards,
> Clemens
> ___
> 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] An "unable to open database file" error that has nothing to do with opening database file

[Clemens Ladisch]

Stephen Chrzanowski wrote:
> I think the problem is with the \ (Note direction) as this makes the next
> character a literal character.

Only for software that interprets backslashes in this way.

The Windows file name parser doesn't.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Stephen Chrzanowski]

I think the problem is with the \ (Note direction) as this makes the next
character a literal character.  So it isn't trying to drop the file into a
sub directory, its using a literal character e.  So

/var/tmp/etilqs_PIREaghry4bPE*S8\et*ilqs_02LTi9u3HO3cx0g
translates to
/var/tmp/etilqs_PIREaghry4bPE*S8et*ilqs_02LTi9u3HO3cx0g
as far as the OS is concerned.

But something is messing with SQLites head because of that.  SQLite might
be trying to open the file changing the \ to \\ which means literal \ which
ends up being NOT the same filename

I've NOT looked at source code to validate my statement.  This is 100%
theory.


On Tue, Jun 4, 2013 at 12:13 PM, Richard Hipp  wrote:

> On Tue, Jun 4, 2013 at 11:59 AM, Philip Goetz  wrote:
>
> > On Tue, Jun 4, 2013 at 11:27 AM, Richard Hipp  wrote:
> > > Try adding the command:
> > >
> > >  .log stdout
> > >
> > > before running the CREATE INDEX and see what errors you get back.
> >
> > sqlite> .schema
> > CREATE TABLE taxon (gi INTEGER, taxon INTEGER);
> > sqlite> .log stdout
> > sqlite> create index taxon_gi_index on taxon(gi);
> > (14) os_win.c:34063: (3)
> > winOpen(/var/tmp/etilqs_PIREaghry4bPES8\etilqs_02LTi9u3HO3cx0g) - The
> > system cannot find the path specified.
> > (14) cannot open file at line 34071 of [cbea02d938]
> > (14) statement aborts at 21: [create index taxon_gi_index on taxon(gi);]
> > Error: unable to open database file
> >
> > Not finding paths often has to do with windows vs. unix vs. cygwin
> > file specifications. The above was running sqlite from the cygwin
> > command prompt.
> > But running it from the MS DOS command prompt with
> > E:\data\db\SQLite>C:/bin/os/cygwin/bin/sqlite3 gi2taxonNt
> > gives almost the same error (just a different /var/tmp filename).
> > I have write permission on /var/tmp and can make files in it.
> >
>
> But apparently it is trying to create a file in a subdirectory.  I don't
> quite understand that.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> 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] An "unable to open database file" error that has nothing to do with opening database file

[Richard Hipp]

On Tue, Jun 4, 2013 at 11:59 AM, Philip Goetz  wrote:

> On Tue, Jun 4, 2013 at 11:27 AM, Richard Hipp  wrote:
> > Try adding the command:
> >
> >  .log stdout
> >
> > before running the CREATE INDEX and see what errors you get back.
>
> sqlite> .schema
> CREATE TABLE taxon (gi INTEGER, taxon INTEGER);
> sqlite> .log stdout
> sqlite> create index taxon_gi_index on taxon(gi);
> (14) os_win.c:34063: (3)
> winOpen(/var/tmp/etilqs_PIREaghry4bPES8\etilqs_02LTi9u3HO3cx0g) - The
> system cannot find the path specified.
> (14) cannot open file at line 34071 of [cbea02d938]
> (14) statement aborts at 21: [create index taxon_gi_index on taxon(gi);]
> Error: unable to open database file
>
> Not finding paths often has to do with windows vs. unix vs. cygwin
> file specifications. The above was running sqlite from the cygwin
> command prompt.
> But running it from the MS DOS command prompt with
> E:\data\db\SQLite>C:/bin/os/cygwin/bin/sqlite3 gi2taxonNt
> gives almost the same error (just a different /var/tmp filename).
> I have write permission on /var/tmp and can make files in it.
>

But apparently it is trying to create a file in a subdirectory.  I don't
quite understand that.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

On Tue, Jun 4, 2013 at 11:27 AM, Richard Hipp  wrote:
> Try adding the command:
>
>  .log stdout
>
> before running the CREATE INDEX and see what errors you get back.

sqlite> .schema
CREATE TABLE taxon (gi INTEGER, taxon INTEGER);
sqlite> .log stdout
sqlite> create index taxon_gi_index on taxon(gi);
(14) os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_PIREaghry4bPES8\etilqs_02LTi9u3HO3cx0g) - The
system cannot find the path specified.
(14) cannot open file at line 34071 of [cbea02d938]
(14) statement aborts at 21: [create index taxon_gi_index on taxon(gi);]
Error: unable to open database file

Not finding paths often has to do with windows vs. unix vs. cygwin
file specifications. The above was running sqlite from the cygwin
command prompt.
But running it from the MS DOS command prompt with
E:\data\db\SQLite>C:/bin/os/cygwin/bin/sqlite3 gi2taxonNt
gives almost the same error (just a different /var/tmp filename).
I have write permission on /var/tmp and can make files in it.

$ ls -l /var/tmp
total 4.0K
drwxrwxrwt+ 1 phil None 0 Jun  4 11:56 ./
drwxr-xr-x+ 1 phil None 0 May 28 22:10 ../
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Richard Hipp]

On Tue, Jun 4, 2013 at 11:22 AM, Philip Goetz  wrote:

> "unable to open database file" errors are usually caused by incorrect
> file protection settings or directory protection settings, but I don't
> think this one is.
>
> This is a 5.0G database with one table that I created in Windows 7
> 64-bit with sqlite3 3.7.16.2 from Perl. I can connect to the DB, read
> from the db, write to the db, and retrieve back what I wrote to it,
> but I can't create an index on it.  I was able to create an index on
> it by copying it to a Linux system and creating the index there. I
> have write permission on the directory. (You can never be sure, with
> the madness of the Windows 7 file security and read-only settings, but
> I am able to create and index other databases in the same directory in
> the same way when they are not so large.)
>
> $ ls -l gi2taxonNt
> -rwxrwxrwx+ 1 phil None 5.0G Jun  4 11:01 gi2taxonNt
> $ sqlite3.exe gi2taxonNt
> SQLite version 3.7.16.2 2013-04-12 11:52:43
> ...
> sqlite> .schema
> CREATE TABLE taxon (gi INTEGER, taxon INTEGER);
> sqlite> insert into taxon (gi, taxon) VALUES (1, 1);
> sqlite> select * from taxon where gi=1;
> [very long wait...]
> 1|1
>

Try adding the command:

 .log stdout

before running the CREATE INDEX and see what errors you get back.


> sqlite> create index taxon_gi_index on taxon(gi);
> Error: unable to open database file
>
> Same error if I make the CREATE INDEX call thru the Perl DBI.
> Any idea what causes this error?
> Is it caused by using a 32-bit sqlite3?  How does a 32-bit app access
> a 5G file?  Is there a 64-bit Windows or Linux SQLite available?
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] An "unable to open database file" error that has nothing to do with opening database file

[Philip Goetz]

"unable to open database file" errors are usually caused by incorrect
file protection settings or directory protection settings, but I don't
think this one is.

This is a 5.0G database with one table that I created in Windows 7
64-bit with sqlite3 3.7.16.2 from Perl. I can connect to the DB, read
from the db, write to the db, and retrieve back what I wrote to it,
but I can't create an index on it.  I was able to create an index on
it by copying it to a Linux system and creating the index there. I
have write permission on the directory. (You can never be sure, with
the madness of the Windows 7 file security and read-only settings, but
I am able to create and index other databases in the same directory in
the same way when they are not so large.)

$ ls -l gi2taxonNt
-rwxrwxrwx+ 1 phil None 5.0G Jun  4 11:01 gi2taxonNt
$ sqlite3.exe gi2taxonNt
SQLite version 3.7.16.2 2013-04-12 11:52:43
...
sqlite> .schema
CREATE TABLE taxon (gi INTEGER, taxon INTEGER);
sqlite> insert into taxon (gi, taxon) VALUES (1, 1);
sqlite> select * from taxon where gi=1;
[very long wait...]
1|1
sqlite> create index taxon_gi_index on taxon(gi);
Error: unable to open database file

Same error if I make the CREATE INDEX call thru the Perl DBI.
Any idea what causes this error?
Is it caused by using a 32-bit sqlite3?  How does a 32-bit app access
a 5G file?  Is there a 64-bit Windows or Linux SQLite available?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users