> 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.
4. Use one of the myriad code generators available on the web to generate the code for this specific task. When the schema changes, regenerate the code. 5. Dynamically build your SQL statement based on the schema as it exists in the copy of the database you're using. This has the advantage of allowing the same code to service multiple database versions. Reading the schema and building the query could be done when the DB is opened and saved, perhaps even in the DB itself, rather than doing every time the query is called. /bs _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
