ISQL returns illegal NULLs as zeroes [CORE1087] #1508
Comments
Modified by: @pcisarWorkflow: jira [ 11500 ] => Firebird [ 15486 ] |
|
Commented by: @dyemanov With NULLs never appearing in NOT NULL columns (in FB 3.0), shouldn't we close this ticket as well? Or is it exclusively about ISQL intelligence? |
|
Commented by: @paulvink Not exclusively, but "also". Detecting illegal nulls is dead easy to implement, so I see no reason not to fix isql on this point, preferably as early as 2.5.1 ;-) Many users don't know of this problem, and only discover it when they try to restore a backup that contains nulls in NOT NULL columns. If isql would show illegal nulls as e.g. <ILL_NULL> (or *ERROR*, or something else that gives the user a good fright) and print a warning |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submitted by: @paulvink
When a NOT NULL column contains NULLs, isql reports these as zeroes (0, emptystring, etc.) to the user.
The heart of the problem is in the engine, which allows these illegal NULLs to exist in the first place, and in the way the API is set up (describing a column as NOT NULL through the same structure that is later used to fetch the output rows).
Still, a good client should be aware of this and always assume that a column may contain NULLs. In the case of illegal NULLs it's even more important that the user be aware of them, so s/he can do something about it. At present, most users assume that Firebird has somehow automatically applied a default value when they add a NOT NULL column or change an existing column to a NOT NULL domain. This leaves them with corrupted data, and unrestorable backups later.
The text was updated successfully, but these errors were encountered: