GNOME Bugzilla – Bug 333550
Exception from Non-ASCII characters in tags
Last modified: 2006-03-06 19:39:25 UTC
Steps to reproduce: 1. Create a tag with non-ASCII characters (e.g. "München") 2. Restart f-spot Stack trace: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in <0x000bd> TagStore:LoadAllTags () in <0x0005c> TagStore:.ctor (Mono.Data.SqliteClient.SqliteConnection connection, Boolean is_new) in <0x000f9> Db:Init (System.String path, Boolean create_if_missing) in <0x0008d> FSpot.Core:.ctor () in <0x00337> FSpot.Driver:Main (System.String[] args) Other information: Version: 0.1.10-0ubuntu1 I didn't see a bug for this issue, but I originally found it reported here: http://mail.gnome.org/archives/f-spot-list/2005-November/msg00086.html This thread suggests the problem is caused by mono converting all queries to ASCII before sending them to sqlite, and that this would be solved with mono 1.1.0. I am currently using mono 1.1.13.4 however, and still experience this issue. I will forward this bug to mono after this. This should be a critical blocker in my opinion, as I ran into this problem as an English-speaking user. I can't imagine how frustrating it would be for others...
I just noticed that f-spot is creating sqlite 2.x database files instead of 3.x, even though the f-spot package in ubuntu depends on libsqlite3-0. Perhaps the package was built wrong on Ubuntu and this is the cause of the problem? I'm not quite sure how to figure out which library f-spot is using as ldd is useless (no .net complaints today :). Mono.Data.SqliteClient.dll contains references to both sqlite and sqlite3 functions, so I assume it can use either library, and is defaulting to sqlite2. If I remove libsqlite0 (leaving only libsqlite3-0 installed) and delete my photos.db, the new database is created in sqlite3 format and this bug goes away. I therefore don't know if this bug belongs to f-spot, mono or the Ubuntu package in determining whether to use sqlite 2 or 3, but it seems like it should default to the highest version available if it can use both. At least f-spot should not allow users to write tags with extended characters when using sqlite 2.x. Bug cross-posted to mono-project at http://bugzilla.ximian.com/show_bug.cgi?id=77711
They are working on moving towards SQLite 3. The update (for database changes between releases) function have just been completed, which was needed for this transition as far as I understand.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. Regarding Bengt's note, the database upgrade code he mentions is not related to upgrading between sqlite versions but upgrading the database schema itself (eg adding a new column for new functionality). *** This bug has been marked as a duplicate of 329488 ***
Gabriel: Is this one really a duplicate of #329488? That is purely for upgrade from sqlite 2 to 3. The original description of this bug is Steps to reproduce: 1. Create a tag with non-ASCII characters (e.g. "München") 2. Restart f-spot Also, when Ryan removed old SQLite2 and only used SQLite 3 the problem went away. Perhaps change to Will be fixed with SQLite 3, (F-Spot is still on SQLite 2 I think, even if the Ubuntu package might indicate SQLite 3?)
It's definitely not a duplicate in that bug. Once I figured out the problem, I had no issues with upgrading my database to sqlite 3 format manually with sqlite 2/3 tools, which bug #329488 is dealing with. This actual bug is that *mono* can't retrieve extended characters stored in an sqlite 2 database. As a result, f-spot should detect which DB you're using and not let you set them, otherwise you will no longer be able to even start f-spot unless you know how to use the sqlite database admin program to remove the extended characters. It would be ideal if f-spot could refuse to create sqlite 2 databases but that belongs in the other bug. :)
Try upgrading your mono to mono-1.1.13.4 the mono sqlite binding keep chaning and causing us problems.
Perhaps you didn't read my initial entry, however I AM using 1.1.13.4 already.
Ryan, did you try to reproduce this bug without using non-ASCII characters? I'm still not convinced it's not simply an issue of f-spot trying to read a sqlite 3 db as sqlite2 or vice versa. If that is not the case, then this bug should be reclassified as a duplicate of a different bug that dealt with sqlite bindings having this issue (I can't find the # right now).
I must not be expressing myself well. I'll try to be more clear: I have both libsqlite2 and libsqlite3 installed. When I start f-spot, it will create a new photos.db in sqlite2 format. If I then create a tag with extended characters and exit f-spot, when I restart f-spot won't start with the exception I pasted above. This is because (apparently) there is a bug in mono when reading sqlite2 format files with extended characters. This has nothing to do with sqlite 3. If I use the sqlite2 command-line utility to remove the extended characters from my tag in photos.db, f-spot will start normally. If I remove libsqlite2 and my photos.db and run f-spot again, it creates a new photos.db in sqlite3 format. Now if I create a tag with extended characters, I am able to quit and restart f-spot sucessfully with no problems at all. This is NOT an issue of sqlite2/3 interacting, but a bug in mono using only sqlite2. It looks like this will be solved by forcing f-spot to use sqlite3 only as is being discussed in bug #329488. Then the only problem will be for old users with sqlite2 db's, but they are easily convertable to sqlite3 format (as I did with mine).