This is a notification from the Help Desk.

On Mar 07, 2014 @ 03:26 pm, milanb@... wrote:
Tetram Corp wrote:
> I thought about this solution but hoped there was a better one because
> of, you're right, in my case the field has a restricted range but i've
> an other similar case where there's no limit in value range
>
> too bad. I will use this trick for my first case, and think again about
> app design for the second one

Do you have a complete control over database and application?

What is the datatype of column?

Here are some ideas: If you have a varchar column, you can solve it by
increasing the column size by 1 character and make sure default uses all
characters. For example, if your field is normally char(3), you can
increase it to char(4) and set 'XXXX' as default. Restrict the data
entry in application to only allow 3 characters.

--
Milan Babuskov

==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================


==Ticket History==

On Mar 07, 2014 @ 03:25 pm, dev@... wrote:
I thought about this solution but hoped there was a better one because
of, you're right, in my case the field has a restricted range but i've
an other similar case where there's no limit in value range

too bad. I will use this trick for my first case, and think again about
app design for the second one

thx all


Le 03/11/2011 21:39, Leyne, Sean a écrit :
>
> Ismael,
>
> > In the trigger:
> >
> > if (new.myfield is null) then
>
> This will not be able to distinguish the condition:
>
> > But now, i'm facing a new challenge: how to detect if the null status I
> > received in new.myfield is because the field was not in the insert
> > statement or because the insert statement set it to null ?
> >
> > well, from
> > insert into mytable (field1) values (:field1)
> > or from
> > insert into mytable (field1, myfield) values (:field1, null)
>
> Doug Chamberlin's solution is the right one, though with a possible
> problem if the full range of values for the field are valid within an
> INSERT statement (in which case no "dummy" default value could be
> defined).
>
> Sean
>
>



[Non-text portions of this message have been removed]

------
On Mar 07, 2014 @ 03:25 pm, sean@... wrote:
Ismael,

> In the trigger:
>
> if (new.myfield is null) then

This will not be able to distinguish the condition:

> But now, i'm facing a new challenge: how to detect if the null status I
> received in new.myfield is because the field was not in the insert
> statement or because the insert statement set it to null ?
>
> well, from
> insert into mytable (field1) values (:field1)
> or from
> insert into mytable (field1, myfield) values (:field1, null)

Doug Chamberlin's solution is the right one, though with a possible problem if the full range of values for the field are valid within an INSERT statement (in which case no "dummy" default value could be defined).


Sean

------
This is an automated response. Your issue has been noted. We'll be in touch soon.



Please reply to this email or visit the URL below with any additional details.

http://DANTOIN:9675/portal/view-help-request/73




[Non-text portions of this message have been removed]