Maybe this will help someone else later on down the road when dealing with defaults and how the library handles them.
My intention was to see about changing the behavior of SQLite Expert when it came to generating the SQL statement to create a new table. Currently, Expert takes whatever is in the default form field and drops it in with little to no mutation of what I entered. Bogdan raises a good point that it should be up to me to explicitly decide what precisely the field should contain as a default and as what type the application should expect. What SearchMask is intended for in my application is a colon delimited file mask. *.txt:*.exe:TextFile_*.txt, etc. (I picked colon because it isn't a valid character in a file name in Windows, while coma and semicolon is, and I'm not concerned with drives as 'ApplicationMonitorPath' handles that). Needless to say, when I went to enter an unquoted * in Expert as a default value, it threw an exception when I went to apply the changes because of the unquoted star. So I thought that regardless of whether or not the library cares about field types, *TO ME* if I specify a field as a char type, maybe Expert could take a jump at logic and say "You know, he's decided this is a character field, and he put something in the default field. Maybe I should make that a literal entry since the library defines a string default with single quotes." Needless to say, Bogdan raises the excellent point that the I-D-TEN-T (My words, not his) designing the table should specifically dictate what the default should be. He's right. Expert shouldn't, make assumptions as to what needs to be put in place. The four schemas I was looking at were as follows, and what made me raise my brow: CREATE TABLE [tApplicationPaths] ( [AppID] INTEGER PRIMARY KEY, [ApplicationName] CHAR, [ApplicationMonitorPath] CHAR, [SearchSubDirs] BOOL DEFAULT 1, [SearchMask] CHAR DEFAULT *); CREATE TABLE [tApplicationPaths] ( [AppID] INTEGER PRIMARY KEY, [ApplicationName] CHAR, [ApplicationMonitorPath] CHAR, [SearchSubDirs] BOOL DEFAULT 1, [SearchMask] CHAR DEFAULT '*'); CREATE TABLE [tApplicationPaths] ( [AppID] INTEGER PRIMARY KEY, [ApplicationName] CHAR, [ApplicationMonitorPath] CHAR, [SearchSubDirs] BOOL DEFAULT 1, [SearchMask] CHAR DEFAULT 8*8); CREATE TABLE [tApplicationPaths] ( [AppID] INTEGER PRIMARY KEY, [ApplicationName] CHAR, [ApplicationMonitorPath] CHAR, [SearchSubDirs] BOOL DEFAULT 1, [SearchMask] CHAR DEFAULT '8*8'); As far as the library is concerned, the first schema threw an exception, which is 100% acceptable. The second works as I desire. The third one is a calculable value, so when I insert a new row with nothing defined in SearchMask it returns 64, not 8*8 even though the schema is defined with 8*8 and shows in the master table as such. I wasn't totally surprised by that behavior. The fourth entry works the same as the second. Then, as I was typing the email this AM, I tried adding just a series of characters, then I got the new error I'd never seen about constants. So tried a field name, and it surprised me that it accepted the new schema, but got a wildly different answer to what I was expecting, which is why I came here since it looked like this issue was the library's intention of what should be going on more so than something wrong with Expert. Bogdan; if you're reading. Thanks for sticking to your guns. I appreciate SQLite Expert tremendously. :] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
