| Subject | Re: [IBO] IBO rev 2785 and default values |
|---|---|
| Author | Robert Martin |
| Post date | 2018-08-07T21:05:33Z |
This isn't an issue for me but I believe the wider issue is that if you write and test code around the existing functionality and it changes a significant amount of code might now broken and require re-testing. When we run out changes like this in our software we try to make the old functionality the default and add a switch to enable the new functionality. That might be tricky in this case :)
Just my 2c :)
Cheers
Rob
On 8/08/2018 6:37 AM, 'Jason Wharton' jason@... [IBObjects] wrote:
Marcin,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.Thanks,Jason Wharton
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Tuesday, August 07, 2018 1:51 AM
To: IBObjects@yahoogroups.com
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
parameters.
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? :-)
Thanks
Marcin