On Sun, May 15, 2011 at 10:05 PM, Nico Williams <n...@cryptonector.com>wrote:
> Right, well, SQLite3 doesn't support renaming columns. Internally > SQLite3 only stores the CREATE statements for all schema elements > (plus actual b-trees for tables and indexes). Specifically SQLite3 > does not store schema elements in any sort of parse and normalized > form, which means that changing the names of schema elements that are > embedded in others is quite difficult, as it would mean parsing the > stored CREATE statements, editing them, then writing them back to the > DB. > I think that if external SQLite management tools' developers have been able to provide this feature, SQLite devs could add this feature too to make it easier for everybody. > If you must use Jay's method at all, I recommend that you do something > like what Jay described, but, first take some steps to make sure you > get the edits right: > I would just use a standalone tool to do this in order to save time and prevent errors. > I don't see an analogy there. Here's one using Word and OpenOffice: To you and another person who didn't agree with my analogy. You're analyzing it on a the wrong level. My point was this: if there's an easier way to do something, I'd prefer to do it that way. Let's not get into a rat's hole. > > Secondly, if I executed the above SQL code, what would happen to > triggers, > > etc. that are associated with the original table? > > You have to fix your triggers and views -- that's what SQLite3 doesn't > have the code to do. It's missing. > Thanks. That's more support to justify using a tool that handles these details automatically. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
