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

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Richard Hipp-3
On Tue, Jun 4, 2013 at 11:22 AM, Philip Goetz <[hidden email]> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Richard Hipp-3
On Tue, Jun 4, 2013 at 11:59 AM, Philip Goetz <[hidden email]> wrote:

> On Tue, Jun 4, 2013 at 11:27 AM, Richard Hipp <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

> On Tue, Jun 4, 2013 at 11:59 AM, Philip Goetz <[hidden email]> wrote:
>
> > On Tue, Jun 4, 2013 at 11:27 AM, Richard Hipp <[hidden email]> 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
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
<[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Warren Young
In reply to this post by Philip Goetz
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Warren Young
In reply to this post by Philip Goetz
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Philip Goetz
On Wed, Jun 5, 2013 at 4:51 PM, Warren Young <[hidden email]> wrote:
>
> Bottom line, I suspect there is a bug in SQLite here.  It shouldn't be using
> backslashes in a Cygwin build.

I think the problem is that the Cygwin distribution has the wrong
version of SQLite, one built for unix. I downloaded a Windows
executable SQLite command shell, and it worked fine with that same
database.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users>
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Philip Goetz
In reply to this post by Warren Young
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 <[hidden email]> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Keith Medcalf
In reply to this post by Philip Goetz

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: [hidden email] [mailto:sqlite-users-
> [hidden email]] 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Warren Young
In reply to this post by Philip Goetz
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Warren Young
In reply to this post by Stephen Chrzanowski
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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.
12