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
