Hi Andrew, there are many problem with empty strings in databases like e.g. that they allow to store empty content in a "not null" field. The question is what is in fact the difference between an empty field and a null value from a logical point of view. Personally I would even go as far as to say "to distinguish empty strings from null does not make sense at all".
In order to avoid many problems inherit in empty strings Empire-db's aim is to treat empty strings equivalent to null. More specifically Empire-db will always replace empty strings by null and thus not allow empty strings to be written to the db. This behavior is by design and brings many benefits especially regarding DBMS independence. In DbRowSet like 680 that you mentioned we do exactly that i.e. we won't accept an empty string for a required field. Allowing that would mean a back-door to bypass the "not null" constraint on the column. So again this works exactly as designed and I perceive this as a benefit and not as a restriction. Regards Rainer andrew cooke wrote: > re: Empty Strings are not Null! > > I almost raised an issue for this, but then I started thinking it was > odd that no-one else had ever mentioned it, so I thought maybe it was > better to ask via email first... > > As far as I can tell, Empire DB will refuse to write an empty string > to a column if it is "NOT NULL". This is true for any database type > since the logic based on a call to ObjectUtils - it's not the > responsibility of a particular engine's driver (in my particular case > the error is coming from DbRowSet line 680 as I add a new row). > > Now I know that Oracle, and perhaps some other databases, store empty > strings as nulls. But not all databases do so! I am pretty sure that > HSQLDB does not, for example, since 1.7.2 - see > http://hsqldb.org/doc/guide/ch06.html#N10F73 And I am also pretty > sure that SQL standards make a distinction. > > So could this be fixed? Alternatively, if it's a known issue that has > a reason, is it documented somewhere? Or if I've messed up, and this > *does* work, please say so I can fix my bug... > > (I'm not really sure why Empire DB is checking this at all. Isn't > this the database's job?) > > Thanks, > Andrew
