This is a notification from the Help Desk.
On Mar 07, 2014 @ 03:26 pm, [email protected] 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, [email protected] 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, [email protected] 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]
