Re: [sqlite] Column types "safe" changes

>Why not just > > update tbl set col1 = col1; > >or perhaps > > update tbl set col1 = cast(col1 as text); > >I'm not sure the former will actually change anything, but the latter >should. Yes my untold question was merely if simpler col = col way could be simply ignored. You're right

Re: [sqlite] Column types "safe" changes

Jean-Christophe Deschamps wrote: > Beside the obvious update with every changed column mentionned, > > update tbl set col1 = (select col1 from tbl y where y.rowid = > tbl.rowid), >... >coln = (select coln from tbl y where y.rowid = >

Re: [sqlite] Column types "safe" changes

>And, of course, you'll have a table where some rows (old ones) contain >integers and others (new ones) contain text. SQLite is fine with this, >but your client software might not be prepared to deal with it. Some >comparisons might behave in surprising ways. I imagine that in such case, the

Re: [sqlite] Column types "safe" changes

Max Vlasov wrote: > As I recall sqlite probably doesn't case about string types included > in the CREATE TABLE field list, so TEXT, VARCHAR, VARCHAR(200) are > identical from its point of view. Today I needed to increase the > number of chars in VARCHAR statement since the

[sqlite] Column types "safe" changes

As I recall sqlite probably doesn't case about string types included in the CREATE TABLE field list, so TEXT, VARCHAR, VARCHAR(200) are identical from its point of view. Today I needed to increase the number of chars in VARCHAR statement since the library that uses sqlite actually does care about