On 13 Sep 2011 at 17:03, Simon Slavin <slav...@bigfraud.org> wrote: > On 13 Sep 2011, at 4:38pm, Tim Streater wrote: > >> In general the row could get moved around any number of databases and then >> back to the original one. > > That's one reason I think making absid unique then manually manipulating absid > values is a bad idea. Labelling which system each row originated in, and > including that column in the unique key, is enough for you to avoid all > collisions. Then you no longer have to worry about changing any absids: leave > the absid exactly as it is. Move your rows from one database file to another > with a simple INSERT, never worrying about changing anything in the record.
Mmmm. Looks like there's no elegant way to do it. I looked into this a couple of years ago when designing the setup. So: 1) Leave things as they are. Downside is the unexplained error every few months and it's a slightly clumsy method. Upside is if the schema changes there's no extra work to do. 2) Gerry suggests listing out the columns explicitly. Upside is this simplifies the move operation, downside is extra maintenance. I suppose I could get clever and store the column names in a Settings database I already have and use that to generate the SQL. 3) Use your suggestion. Upsides as you describe - simple move. Downside is an extra column with the same value in it for all rows. The irritating part is that there is a unique value for each database stored in another table in the same db. But it appears I can't do: PRIMARY KEY (OTHERTABLE.ORIG, ABSID) which would have been nice. > I believe the latter. Five columns will be copied into five columns in column > order, regardless of column names. If that's the case I can't see where the occasional error is coming from. Thanks for your responses. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
