Subject Re: [IBO] IBO rev 2785 and default values
Author Carlos H. Cantu
Re: [IBO] IBO rev 2785 and default values I suffered a bit with this change too. Legacy code does not expect fields/params to be initialized with the server defaults, because when it was coded, the behavior in IBO was different. In my case, I had some code (client side) that checked if the field was null and, if so, take some action... with the change, the field was never null anymore, since IBO initialized it with the server default.

I think you were too optimistic to implement such change expecting no side effects for your customers. I had to do a full code review to detect points that could be affected by this change. I found no more than 4 points, but it took me several hours reviewing legacy code to find them.

Carlos H. Cantu
eBook Guia de Migração para o FB 3 - - -

My intent was for these changes to be an improvement.  IBO's core philosophy is to have all of the aspects possible from the server be a part of things on the client.  I want server declared default values to be utilized on the client.  Perhaps you could explain to me why you want a NULL default rather than the server declared default.  I probably just don't understand why this would cause a problem instead of being appreciated.
Jason Wharton

From: []
Sent: Tuesday, August 07, 2018 1:51 AM
Subject: [IBO] IBO rev 2785 and default values

Hello Jason

It seems that you modified the way IBO works with columns' default
values. And it also seems that you made a step too far ;-).
If a column is based of domain with default value this default value is
taken when adding new record (previously IBO was keeping null value),
but what is more annoying that IBO sets the default value for
I have a stored procedure that has and integer parameter based on domain
with 0 as default value. Procedure is prepared to accept null value in
this parameter and 'behave' accordingly. What was my surprise when IBO
set 0 for this parameter 'without asking'

So, could you reconsider your changes? :-)