> there are no NULLS in my example and I don't believe in a frontend-problem (I > wouldn't interpret the SQL.LOG this way).
If you don't believe that it's your frontend problem then go ahead and reproduce it in sqlite3 command line utility. If you were able to reproduce it there then it would be indeed an SQLite library problem. Otherwise it's frontend problem believe it or not. Pavel On Mon, Jun 28, 2010 at 4:29 AM, Oliver Peters <oliver....@web.de> wrote: > Darren Duncan <dar...@...> writes: > > [...] > >> What efforts have you made in trying to fix the front-end instead? >> > > > Nothing because I'm not a programmer but I reduced complexity: > > > example_01: > ---------- > CREATE TABLE doesntwork( > id INTEGER PRIMARY KEY AUTOINCREMENT, > someint INTEGER, > sometext TEXT, > UNIQUE(someint) > ); > > > INSERT INTO doesntwork(someint,sometext) VALUES(2,'Douglas Adams'); > > > example_02: > ---------- > CREATE TABLE works( > id INTEGER PRIMARY KEY AUTOINCREMENT, > someint INTEGER, > sometext TEXT > ); > > > INSERT INTO works(someint,sometext) VALUES(1,'Hitchhikers guide to galaxy'); > INSERT INTO works(someint,sometext) VALUES(2,'Douglas Adams'); > > > I use OpenOffice 3.2.1 in connection with http://www.ch-werner.de/sqliteodbc/. > If I try to delete or change records in the example_01 this doesn't work. I > just use tables not even a form. > > >> If the front-end complains about doing something as common and proper as >> using >> UNIQUE constraints (which are the best solution for the job), then I >> wouldn't be >> surprised if its also going to give you trouble with other reasonable things >> you'd want to do. >> >> Are you having problems with all UNIQUE constraints or just some of them? >> Perhaps the difference is whether or not the column in question has nulls >> in it. > > there are no NULLS in my example and I don't believe in a frontend-problem (I > wouldn't interpret the SQL.LOG this way). > > [...] > >> >> An alternate thing you could do is split your tables so each column you want >> unique is in its own table and then you can make that a primary key. >> Not that I >> actually advise this since then you're just gaining a new problem or two in >> place of the one you lost, such as ensuring there's not more than one row >> in the >> other table per row in the parent. >> > > I use Triggers now but that is just a workaround - as you write: UNIQUE > constraints are something very common in DBMs and should work > > thx for your thoughts > Oliver > > _______________________________________________ > 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
