On Mar 19, 2009, at 3:46 AM, zhenchen17 wrote:

It depends on where adc_lenchk is being called. If it's being called
with the second (adc_is_usr) parameter TRUE, then the supplied length
should be the "user visible" length (8 in the float case), and the
lenchk routine will adjust for the null indicator. If it's being
called with adc_is_usr FALSE, which is more common, then the supplied
length needs to be the true internal length and must be
sizeof(f8)+1 for nullable.

Upon looking through the user defined functions that we used
at Datallegro, I see that the FI's do indeed have the true
length set even for nullable FI's -- they do not add one
for the null byte. I missed that completely the first time
I looked. I would prefer that the FI reflect the true length,
but I guess this is the way it works and it's probably too
late to "fix" it.

Karl

Hi Karl,
Thanks,
But i suspect whether this situation happens? when return a nullable
value while the last bit of the data happens to be set 1, will the
DBMS treat it as NULL?
For example i want to return char(5) -- 'ab123' , the last character
'3' is '110011' which make the macro adf_isnull_macro to be true.


Chenzhen


On 3ÔÂ19ÈÕ, ÏÂÎç8ʱ31·Ö, Karl & Betty Schendel <schen... (AT) kbcomputer (DOT) com>
wrote:

On Mar 19, 2009, at 9:28 AM, zhenchen17 wrote:

The DBMS shouldn't be looking at '3', it should be looking at the
next byte for the null test.

For your user defined function, adc_lenchk when called with is-user
TRUE, should increase the length by one to allow for the null.

Try setting a breakpoint where your function is called and see what
the result DB_DATA_VALUE is at the point of call. I expect you
will find that db_datatype is -DB_FLT_TYPE (ie II_FLOAT) and the
length is 9. If not, then we will have to track down where this
is getting mixed up.

Karl