Re: [sqlite] Unable to open database file
>I have found out that using UNC paths vs a mapped drive to a server, is >much slower. Specially if you are going to use a database shared amoungst >other folks. I would suggest a test on both scenario (UNC path and mapped >drive) and place some times on the same calls and you'll see the differences. >Heck, you can see the difference by copying a file. Ihth. That is likely because using a UNC path is not persistent. Try mapping the UNC Path first (same as you would do mapping to a drive letter, just leave out the drive letter) and see if that makes a difference. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unable to open database file
"Steve Rogers" wrote... On 9/23/2014 10:57 PM, Joe Mistachkin wrote: Steve Rogers wrote: Reading in order, it says that: SQLiteDb.LDb3.PrepareCommand threw an exception with the message 'unable to open database file' Is the database file name a UNC path? If so, the number of leading backslashes must be doubled (i.e. four leading backslashes are now required), e.g.: // // NOTE: The C# compiler itself needs the backslashes escaped // as well, hence there are 8. // string fileName = "server\\share\\path\\to\\database.db"; -- In my test today, the path was C:\Users\Public because I was installing on the machine that will be the machine to hold the database file. I'll need to take these comments into account when I get to a fully qualified UNC name on the other computers. I have found out that using UNC paths vs a mapped drive to a server, is much slower. Specially if you are going to use a database shared amoungst other folks. I would suggest a test on both scenario (UNC path and mapped drive) and place some times on the same calls and you'll see the differences. Heck, you can see the difference by copying a file. Ihth. josé ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unable to open database file
On 9/23/2014 10:57 PM, Joe Mistachkin wrote: Steve Rogers wrote: Reading in order, it says that: SQLiteDb.LDb3.PrepareCommand threw an exception with the message 'unable to open database file' Is the database file name a UNC path? If so, the number of leading backslashes must be doubled (i.e. four leading backslashes are now required), e.g.: // // NOTE: The C# compiler itself needs the backslashes escaped // as well, hence there are 8. // string fileName = "server\\share\\path\\to\\database.db"; -- In my test today, the path was C:\Users\Public because I was installing on the machine that will be the machine to hold the database file. I'll need to take these comments into account when I get to a fully qualified UNC name on the other computers. I haven't tested that scenario yet, but I will do soon. But the problem remains that the failure I describe in my message was when the database file was on the same machine. I'm hoping that when I get the problem resolved that when the user uses a file picker to pick the file, that the path I get back from the file picker will be properly "decorated" with all the necessary slashes. If not I can handle that problem. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4025/8264 - Release Date: 09/23/14 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unable to open database file
Steve Rogers wrote: > > Reading in order, it says that: > SQLiteDb.LDb3.PrepareCommand threw an exception with the message > 'unable to open database file' > Is the database file name a UNC path? If so, the number of leading backslashes must be doubled (i.e. four leading backslashes are now required), e.g.: // // NOTE: The C# compiler itself needs the backslashes escaped // as well, hence there are 8. // string fileName = "server\\share\\path\\to\\database.db"; -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to open database file - sqlite jdbc
Am 16.05.2011 07:56, schrieb Christoph P.U. Kukulies: > Am 15.05.2011 16:04, schrieb Christoph P.U. Kukulies: >> I keep getting an SQL error >> "unable to open database file" I solved it: The problem is netbeans (7.0 in this case). When I run the application outside netbeans from the DOS prompt C:\Users\kuku\testsuite>java -jar "C:\Users\kuku\Documents\NetBeansProjects\testsqlite\dist\testsqlite.jar" it works fine. So something must lock the database from within netbeans. -- Christoph ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to open database file - sqlite jdbc
Am 15.05.2011 16:04, schrieb Christoph P.U. Kukulies: > I keep getting an SQL error > "unable to open database file" > > after doing some 20 inserts into two tables of my database in a loop > in a java function. > > In the main code I have > String sql="INSERT INTO part(name,md5sum,size,pfad) VALUES (?,?,?,?)"; > String sql1="INSERT INTO > candidate(md5sum,basename,prob_ref,suite,tag,customer) VALUES > (?,?,?,?,?,?)"; > pstmnt = conn.prepareStatement(sql); > pst1 = conn.prepareStatement(sql1); > > Furtherdown in a loop I'm doing > try { > pst1.setString(1, md5); > pst1.setString(2, file.getName()); > pst1.setString(3, p_r); > pst1.setString(4, suite); > pst1.setString(5, mmp); > pst1.setString(6, customer); > pst1.executeUpdate(); >} > and subsequently in the same inner loop another try >with INSERTS in another table. > > and > try { > pstmnt.setString(1, file.getName()); > pstmnt.setString(2, md5); > pstmnt.setLong(3, file.length()); > pstmnt.setString(4,s); > pstmnt.executeUpdate(); > > } > > I have no clue ay to why the program chokes with that error. > > -- > Christoph > Do I need some Autocommit? This is under Win7/64. I read somewhere that this message can have many meanings. One cause could be /var/tmp not being writable. -- Christoph ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to open database file/Disc I/O error
On Thu, Oct 7, 2010 at 1:03 PM, Serena Lien wrote: > > If you find any vista OS patches that solve this problem, please let > me know, we are looking ourselves in the hopes that microsoft has > resolved this issue.. > > Serena, How about this patch : http://support.microsoft.com/kb/935366/en-us(kb935366)? They mentioned FoxPro and Access, but actually looks like a Vista-related bug in SMB protocol used for network access in Windows. Max ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to open database file/Disc I/O error
Hi, Just wanted to say we have the same issue, using sqlite v3.6.15 (not java) running on *some* windows vista machines accessing databases on *some* networked drives. I don't think this is an sqlite problem, because vista is obviously randomly locking files and this can be seen when using microsoft word or excel. Occasionally these programs report that the files are in use and open them as read-only, when in fact they are not. Reopening the file always makes the errors go away. With our sqlite program, we also see these errors occur - typically we get SQLITE_BUSY (the file is locked) errors compiling or executing statements, but as you said, the errors are random. Some statements accessing a database will work, and then another statement accessing the same database will fail a second later. Exiting our application and restarting it makes the problem go away for a while. If you find any vista OS patches that solve this problem, please let me know, we are looking ourselves in the hopes that microsoft has resolved this issue.. thanks, Serena. - Ferdinand wrote: Hi, we have a java application ( with sqlitejdbc-v056/windows vista) which runs only once on every PC to fill a new database. On most machines everything works perfectly, but on some machines the application fails with either "Unable to open database file" or " disk I/O error". The database is of course there . This errors occur on different locations in the code(with execute() or executeBatch()), even when previous calls to this functions were successfull.. In most cases the problems vanish when we run the apllication again (but this is not really an option we have). I searched the internet and found that this errors might be caused by locks on temporary files(we run Kaspersky Anti Virus on every machine) Are there any other explanations for this behaviour? Thanx Ferdinand Krämer ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unable to open database file
Timo wrote: > OperationalError: unable to open database file Note that there is a group specifically for using Python with SQLite: http://groups.google.com/group/python-sqlite Unfortunately SQLite's error reporting isn't particularly detailed when opening databases. There are a lot of things that have to happen beyond just opening the database file. For example the journal needs to be checked for, applied and deleted if present. Windows especially has issues with tag alongs - other programs like virus checkers, backup applications, TortoiseSVN etc that track file activity and then grovel in the files. These can prevent the programs actually using the files from doing things like deleting them (the tag along has the file held open). SQLite does have code to retry some number of times hoping the tag along has finished, but if the system has enough of these installed it may not be sufficient. Note that tag alongs may not be the cause, but rather an example of behaviour similar to what you are seeing. Ultimately you'll need to take an inventory of the machines looking for what is common and what is different. If you can reproduce the problem then use Process Monitor from Sysinternals to see what programs are accessing the file/directory and what error codes are being returned. Roger ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
D. Richard Hipp wrote: > > (2) Formal and detail requirements that define precisely what SQLite > does. > > http://www.sqlite.org/draft/tokenreq.html > http://www.sqlite.org/draft/syntax.html > These look great. I noticed a few typos, but on the whole they are very good. I noticed that in many places you specify that sqlite will fail with an error, but you do not specify what the error will be (i.e. the error code and or message isn't specified). Perhaps these details should be added. BTW, have you noticed how much closer these documents are to the style of the SQL standard than your previous, less formal and more more ambiguous, documents were? :-) > > (6) New test harnesses and requirements-based test cases that give > 100% branch coverage and that can be run on embedded systems. > Will this test system be written in C instead of TCL to make it portable to a wider variety of system? Dennis Cote ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
On Aug 12, 2008, at 2:32 PM, Dennis Cote wrote: > What kind of fish are you frying now, or is it top secret? (1) Improvements to memory allocation performance, measurement, and control and documentation of the memory allocation subsystem. http://www.sqlite.org/draft/malloc.html (2) Formal and detail requirements that define precisely what SQLite does. http://www.sqlite.org/draft/tokenreq.html http://www.sqlite.org/draft/syntax.html (3) Split up the pager subsystem into separate modules for handling page cache and transaction control. Provide infrastructure so that unpinned page cache lines can be taken over by the operating system and reassigned to other processes when the system is under memory pressure. (4) Additional optimizations on VIEWs so that the queries that Firefox does against the places.sqlite database can be cleaner and easier to read and maintain. (5) Break out all static and global variables into a single "sqlite3Global" structure and provide macros that facility compiling and use SQLite on platforms where separate processes share a common address space. (Yes, I know that most people define a "process" as having its own address space - but not everybody does - and there are people who don't that really want to be able to run SQLite on their systems.) (6) New test harnesses and requirements-based test cases that give 100% branch coverage and that can be run on embedded systems. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
D. Richard Hipp wrote: > > Adding new result codes is complicated. There exist applications that > only check for the current set of result codes. So if new result > codes are added, those applications might fail. Hence adding new > result codes can lead to compatibility problems in legacy applications. > Oh, that again. :-) It still seems to me that most applications embed the source of a particular version of sqlite, and those applications are safe until the developer updates them to a newer version. That developer is then responsible for ensuring his application code works correctly with the new version of sqlite he is updating to. He is also free to continue to use the older version of sqlite in his application if he doesn't want to make any sqlite related changes for a particular release. This sort of compatibility problem would only be an issue for updates to an sqlite shared library that multiple applications are linking to at run time. So this is perhaps another good reason not to do this. Perhaps the next major release should address this by specifically reserving the right to add new error codes in future versions, and requiring application developers (who are using a shared library) to be prepared to handle new, unknown, error codes. They can still call sqlite3_errmsg to get a string to report the new error, they just won't be able to assume that they can do anything in particular to recover from the new error. If they aren't prepared to do that, they can always eliminate the concern by statically linking to, or embedding, a particular version of sqlite, for which they can handle every possible error. > We have bigger fish to fry. > What kind of fish are you frying now, or is it top secret? Dennis Cote ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
On Aug 12, 2008, at 1:37 PM, Dennis Cote wrote: > Igor Tandetnik wrote: >> "Robert Latest" <[EMAIL PROTECTED]> >> wrote in message >> news:[EMAIL PROTECTED] >>> $ sqlite3 /cygdrive/d/cl_hist_dat/clhist.sqlite >>> SQLite version 3.5.1 >>> Enter ".help" for instructions >>> sqlite> create view y as select * from tools; >>> sqlite> create temporary view z as select * from modules; >>> SQL error: unable to open database file >> >> SQLite can't write to your temp directory. That's why you can >> create a >> regular view, but not a temporary view (which requires opening a temp >> database). >> > > I see this has come up yet again. > > Richard, have you given any more thought to implementing a better > error > message for this situation? We discussed this error a while ago in > this > thread > http://thread.gmane.org/gmane.comp.db.sqlite.general/38797/focus=38825 > but you never commented on the viability of the changes I suggested. > Adding new result codes is complicated. There exist applications that only check for the current set of result codes. So if new result codes are added, those applications might fail. Hence adding new result codes can lead to compatibility problems in legacy applications. We would need to add a new extended result code to handle this case. #define SQLITE_CANTOPEN_MAIN (SQLITE_CANTOPEN | (1<<8)) #define SQLITE_CANTOPEN_TEMP (SQLITE_CANTOPEN | (2<<8)) This is feasible, but doing it will require a fairly large effort in making sure that the appropriate error message text is generated in each case, verifying that behavior is unchanged when extended result codes are disabled, fixing legacy test cases, writing new test cases, and so forth. This is at least one full day's worth of uninterrupted work to get right. And the benefit does not seem worth the effort right now. We have bigger fish to fry. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
Igor Tandetnik wrote: > "Robert Latest" <[EMAIL PROTECTED]> > wrote in message > news:[EMAIL PROTECTED] >> $ sqlite3 /cygdrive/d/cl_hist_dat/clhist.sqlite >> SQLite version 3.5.1 >> Enter ".help" for instructions >> sqlite> create view y as select * from tools; >> sqlite> create temporary view z as select * from modules; >> SQL error: unable to open database file > > SQLite can't write to your temp directory. That's why you can create a > regular view, but not a temporary view (which requires opening a temp > database). > I see this has come up yet again. Richard, have you given any more thought to implementing a better error message for this situation? We discussed this error a while ago in this thread http://thread.gmane.org/gmane.comp.db.sqlite.general/38797/focus=38825 but you never commented on the viability of the changes I suggested. Dennis Cote ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
Thanks, that was it. I don't know exactly how the errors were interrelated, but once I told sqlite (via the PRAGMA thing) to use memory for tmp stuff, all was fine. I'm working under a cygwin environment which seems to be a bit shaky when it comes to system-specific stuff like permissions. robert ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
"Robert Latest" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > $ sqlite3 /cygdrive/d/cl_hist_dat/clhist.sqlite > SQLite version 3.5.1 > Enter ".help" for instructions > sqlite> create view y as select * from tools; > sqlite> create temporary view z as select * from modules; > SQL error: unable to open database file SQLite can't write to your temp directory. That's why you can create a regular view, but not a temporary view (which requires opening a temp database). Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
On Mon, Aug 11, 2008 at 1:42 PM, P Kishor <[EMAIL PROTECTED]> wrote: > ahhh... I did misread the question. Yes, the above explanation seems > logical. Your app is probably tying up the db, so you can't drop the > table from the command line. No it ain't. That's of course the first thing I checked. I fact I re-booted the machine just to make sure that no rogue process was holding a lock ono the db. Check this out: $ sqlite3 /cygdrive/d/cl_hist_dat/clhist.sqlite SQLite version 3.5.1 Enter ".help" for instructions sqlite> create view y as select * from tools; sqlite> create temporary view z as select * from modules; SQL error: unable to open database file sqlite> drop view y; sqlite> .quit $ So I may create a view, y. Then I'm not allowed to create a temporary view, z (I never am when mucking around with this particular db). After that I want to drop view y (which I just created) and can't, either. This is really puzzling. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
On 8/11/08, Mihai Limbasan <[EMAIL PROTECTED]> wrote: > Robert Latest wrote: > > > Hello people, > > > > why is it that I can look at the ".schema" of a db with the sqlite3 > > command line tool, but can't drop a table or view? After all, if the > > db file weren't open, I couldn't even see the schema. > > > > My problem is that I've written an app that uses views to access data. > > After usage, I don't want those views no more. Unfortunately I can't > > DROP them, so I create more and more views with different names and > > keep littering my db with an increasing number of usesless views that > > I can't delete. > > > > CREATE TEMPORARY VIEW produces an "unable to open database file" error as > well. > > > > I'm up a bit of a stump here because re-creating the database (which > > contains millions of lines but is only about 140M total file size) > > takes about a week. > > > > Here's a screenshot that should tell the whole story. I happened to > > try to drop a table, but it really doesn't matter what I drop. > > > > $ sqlite3.exe clhist.sqlite > > SQLite version 3.5.1 > > Enter ".help" for instructions > > sqlite> .schema > > CREATE TABLE Batches ( > >Id TEXT PRIMARY KEY, > >Moves_V1 INTEGER, > >Moves_V2 INTEGER, > >Moves_V3 INTEGER, > >Moves_V4 INTEGER, > >Moves_V5 INTEGER, > >Moves_R1 INTEGER, > >Moves_R2 INTEGER, > >Moves_R3 INTEGER, > >Moves_R4 INTEGER, > >Moves_R5 INTEGER > > ); > > CREATE TABLE Logs ( > >Shortname TEXT PRIMARY KEY, > >Status INTEGER > > ); > > CREATE TABLE Modules ( > >Name TEXT > > ); > > CREATE TABLE Moves ( > >Batch TEXT, > >SlotNo INTEGER, > >Tool TEXT, > >Module TEXT, > >TimeStart INTEGER, > >Duration INTEGER, > >ZipDate TEXT > > ); > > CREATE TABLE Tools ( > >Name TEXT > > ); > > CREATE VIEW "B470330" AS SELECT * FROM Moves WHERE Batch="470330"; > > CREATE VIEW BatchMoves AS SELECT * FROM Moves WHERE Batch="P"; > > CREATE VIEW "R1" AS SELECT * FROM "B470330" WHERE Tool="R1"; > > CREATE INDEX MovesBatch ON Moves(Batch); > > sqlite> DROP TABLE "Batches" ; > > SQL error: unable to open database file > > sqlite> .quit > > ___ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > Is it possible that the database file is at the same time in use from a > different process? If yes, try shutting down the other database consumers > and retry then. ahhh... I did misread the question. Yes, the above explanation seems logical. Your app is probably tying up the db, so you can't drop the table from the command line. > > -- > Multumesc, > Mihai Limbasan > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
Robert Latest wrote: Hello people, why is it that I can look at the ".schema" of a db with the sqlite3 command line tool, but can't drop a table or view? After all, if the db file weren't open, I couldn't even see the schema. My problem is that I've written an app that uses views to access data. After usage, I don't want those views no more. Unfortunately I can't DROP them, so I create more and more views with different names and keep littering my db with an increasing number of usesless views that I can't delete. CREATE TEMPORARY VIEW produces an "unable to open database file" error as well. I'm up a bit of a stump here because re-creating the database (which contains millions of lines but is only about 140M total file size) takes about a week. Here's a screenshot that should tell the whole story. I happened to try to drop a table, but it really doesn't matter what I drop. $ sqlite3.exe clhist.sqlite SQLite version 3.5.1 Enter ".help" for instructions sqlite> .schema CREATE TABLE Batches ( Id TEXT PRIMARY KEY, Moves_V1 INTEGER, Moves_V2 INTEGER, Moves_V3 INTEGER, Moves_V4 INTEGER, Moves_V5 INTEGER, Moves_R1 INTEGER, Moves_R2 INTEGER, Moves_R3 INTEGER, Moves_R4 INTEGER, Moves_R5 INTEGER ); CREATE TABLE Logs ( Shortname TEXT PRIMARY KEY, Status INTEGER ); CREATE TABLE Modules ( Name TEXT ); CREATE TABLE Moves ( Batch TEXT, SlotNo INTEGER, Tool TEXT, Module TEXT, TimeStart INTEGER, Duration INTEGER, ZipDate TEXT ); CREATE TABLE Tools ( Name TEXT ); CREATE VIEW "B470330" AS SELECT * FROM Moves WHERE Batch="470330"; CREATE VIEW BatchMoves AS SELECT * FROM Moves WHERE Batch="P"; CREATE VIEW "R1" AS SELECT * FROM "B470330" WHERE Tool="R1"; CREATE INDEX MovesBatch ON Moves(Batch); sqlite> DROP TABLE "Batches" ; SQL error: unable to open database file sqlite> .quit ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users Is it possible that the database file is at the same time in use from a different process? If yes, try shutting down the other database consumers and retry then. -- Multumesc, Mihai Limbasan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "unable to open database file" on DROP
On 8/11/08, Robert Latest <[EMAIL PROTECTED]> wrote: > Hello people, > > why is it that I can look at the ".schema" of a db with the sqlite3 > command line tool, but can't drop a table or view? After all, if the > db file weren't open, I couldn't even see the schema. I have no idea what you are talking about... of course, you can drop a view or a table. Here you go... [04:23 PM] ~$sqlite3 SQLite version 3.5.9 Enter ".help" for instructions sqlite> CREATE TABLE foo (a, b); sqlite> CREATE VIEW bar AS SELECT * FROM foo; sqlite> .s CREATE TABLE foo (a, b); CREATE VIEW bar AS SELECT * FROM foo; sqlite> DROP VIEW bar; sqlite> .s CREATE TABLE foo (a, b); sqlite> DROP TABLE foo; sqlite> .s sqlite> Maybe I didn't understand your question. > > My problem is that I've written an app that uses views to access data. > After usage, I don't want those views no more. Unfortunately I can't > DROP them, so I create more and more views with different names and > keep littering my db with an increasing number of usesless views that > I can't delete. > > CREATE TEMPORARY VIEW produces an "unable to open database file" error as > well. > > I'm up a bit of a stump here because re-creating the database (which > contains millions of lines but is only about 140M total file size) > takes about a week. > > Here's a screenshot that should tell the whole story. I happened to > try to drop a table, but it really doesn't matter what I drop. > > $ sqlite3.exe clhist.sqlite > SQLite version 3.5.1 > Enter ".help" for instructions > sqlite> .schema > CREATE TABLE Batches ( > Id TEXT PRIMARY KEY, > Moves_V1 INTEGER, > Moves_V2 INTEGER, > Moves_V3 INTEGER, > Moves_V4 INTEGER, > Moves_V5 INTEGER, > Moves_R1 INTEGER, > Moves_R2 INTEGER, > Moves_R3 INTEGER, > Moves_R4 INTEGER, > Moves_R5 INTEGER > ); > CREATE TABLE Logs ( > Shortname TEXT PRIMARY KEY, > Status INTEGER > ); > CREATE TABLE Modules ( > Name TEXT > ); > CREATE TABLE Moves ( > Batch TEXT, > SlotNo INTEGER, > Tool TEXT, > Module TEXT, > TimeStart INTEGER, > Duration INTEGER, > ZipDate TEXT > ); > CREATE TABLE Tools ( > Name TEXT > ); > CREATE VIEW "B470330" AS SELECT * FROM Moves WHERE Batch="470330"; > CREATE VIEW BatchMoves AS SELECT * FROM Moves WHERE Batch="P"; > CREATE VIEW "R1" AS SELECT * FROM "B470330" WHERE Tool="R1"; > CREATE INDEX MovesBatch ON Moves(Batch); > sqlite> DROP TABLE "Batches" ; > SQL error: unable to open database file > sqlite> .quit > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to open database file
"Francesco Andrisani" <[EMAIL PROTECTED]> wrote: > Hi comunity, > i'm writing CGI pages (writeen in ANSI C) with SQLITE3 support, all work fine > using "SELECT" statement, but when i try to exec "UPDATE" or "INSERT" > statement i've the follow error: > > unable to open database file > > I've set all data base fle permission, but it don't work. > Make sure your CGI process has write permission on the directory that contains the database file. Write permission on the directory is necessary in order for SQLite to create a temporary rollback journal. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Unable to open database file
Thanks Clay, It's definitely Starteam - I used FileMonitor from SysInternals to identify it. My database is running on a removable drive, which may be the cause I guess. If it gets temporarily disconnected or something (or this is usually displayed on the screen). You are right in the last paragraph, that as Starteam is not even interested in the file, it is unlikely to be the cause, although empirical evidence suggests otherwise. I shall keep investigating. Thanks for the help. Regards, Steve -Original Message- From: Clay Dowling [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 9:42 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Unable to open database file Drew, Stephen said: > Yet Starteam (version control system) is still interfering with the > file > - causing unexpected errors while the application is running. Is this > because the locking in Windows is below-par in comparison with the > Unix locking? The thing is that Starteam is not even interested in > the file, only the directory (I guess it is scanning the file to check > it's not been added to version control). First, verify that it's really StarTeam touching the process and fouling it up. You might also want to make sure that you're only using timestamps and not md5 sums to verify file integrity. Trust me, as a fellow StarTeam victim, that using md5 sums in StarTeam is not a reliable way to determine file changes (having nothing to do with md5 and everything to do with StarTeam). Second, check if this thing is running on a local or network drive. SQLite isn't recommended for network drives, and StarTeam most assuredly isn't suitable for network drives. The truth is that StarTeam probably isn't causing the problem, since it isn't interested in writing to the file. If it is causing the problem, consider one of the free source control systems. I've found CVS at least to be a lot less problematic than StarTeam. Clay -- Lazarus Notes from Lazarus Internet Development http://www.lazarusid.com/notes/ Articles, Reviews and Commentary on web development
Re: [sqlite] Unable to open database file
Drew, Stephen said: > Yet Starteam (version control system) is still interfering with the file > - causing unexpected errors while the application is running. Is this > because the locking in Windows is below-par in comparison with the Unix > locking? The thing is that Starteam is not even interested in the file, > only the directory (I guess it is scanning the file to check it's not > been added to version control). First, verify that it's really StarTeam touching the process and fouling it up. You might also want to make sure that you're only using timestamps and not md5 sums to verify file integrity. Trust me, as a fellow StarTeam victim, that using md5 sums in StarTeam is not a reliable way to determine file changes (having nothing to do with md5 and everything to do with StarTeam). Second, check if this thing is running on a local or network drive. SQLite isn't recommended for network drives, and StarTeam most assuredly isn't suitable for network drives. The truth is that StarTeam probably isn't causing the problem, since it isn't interested in writing to the file. If it is causing the problem, consider one of the free source control systems. I've found CVS at least to be a lot less problematic than StarTeam. Clay -- Lazarus Notes from Lazarus Internet Development http://www.lazarusid.com/notes/ Articles, Reviews and Commentary on web development