Tim

Is there any chance of you revisiting this issue. I have lots of places in my code where I assign a string to a varchar column in the expectation that surplus characters will be discarded.

Its an exercise that will make sorting out nulls vs empty strings look like a walk in the park.

Roy Lambert

Roy,

<< Is there any chance of you revisiting this issue. >>

Nope - it's a standards issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< Is there any chance of you revisiting this issue. >>
>
>Nope - it's a standards issue.

In that case does the standard, or anyone else have a sensible suggestion as to how to handle it in real life.

Roy Lambert

Roy,

<< In that case does the standard, or anyone else have a sensible suggestion
as to how to handle it in real life. >>

The only way to handle it is via a trigger.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< In that case does the standard, or anyone else have a sensible suggestion
>as to how to handle it in real life. >>
>
>The only way to handle it is via a trigger.

Whilst I can admire the theoretical purity of the standard I have difficulty in believing that even the individuals who set the standard intended for the programmer to validate the length of every string field before assigning it. Unfortunately that would appear to be what you suggest.

From an earlier post of your's

<<No, according to the SQL 2003 standard, any time a value assignment is
truncated or out of range, an exception or warning should be raised.>>

Why not a warning which can be responded to in some way and potentially ignored (and I appreciate the mechanics might be a bit awkward) rather than an error which can not, as far as I can determine, be handled.

BTW if you continue with raising the error your message is totally wrong. The value was not truncated, the insert or update was aborted/ignored

Roy Lambert

Just a question that went through my mind. I'm not a hacker so I don't know, but does this approach have anything to do with buffer overflow
attacks?

Tim


Considering how I feel about this particular feature I'm not sure I should tell you this, however, there is an inconsistency on how this issue is treated. In sql it bombs, but, if you update the field using field.AsString it happily truncates.

There is (as always) a kicker to this. The field I'm testing on is _ID in Users (my users table not yours) and after my other tests I set its default to CURRENT_USER.

_ID is a varchar(5) and CURRENT_USER in my test app is Administrator.

This

procedure TForm1.Button4Click(Sender: TObject);
begin
users.Open;
users.Insert;
users_id.AsString := '123456';
users.post;
end;

works with _ID defaulted to '' but when defaulted to CURRENT_USER it bombs.

Roy Lambert

Roy,

<< Whilst I can admire the theoretical purity of the standard I have
difficulty in believing that even the individuals who set the standard
intended for the programmer to validate the length of every string field
before assigning it. >>

I'm not sure what you mean by "validate the length" ?  Do you mean check for
trailing blanks ?  Remember, trailing blanks are not considered when doing
VARCHAR/CHAR comparisons.

<< Why not a warning which can be responded to in some way and potentially
ignored (and I appreciate the mechanics might be a bit awkward) rather than
an error which can not, as far as I can determine, be handled. >>

Because the language/compiler that we use only has the ability to raise
exceptions, not warnings.  Warnings and errors both surface via exceptions
in EDB, just like they did with DBISAM.

<< BTW if you continue with raising the error your message is totally wrong.
The value was not truncated, the insert or update was aborted/ignored >>

I'm not sure what you're talking about here - are you specifically referring
to the mechanics of the OnPostError, etc. type of functionality ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Just a question that went through my mind. I'm not a hacker so I don't
know, but does this approach have anything to do with buffer overflow
attacks? >>

I doubt it.  As far as I know, it's just considered the proper way of
handling the data.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Considering how I feel about this particular feature I'm not sure I
should tell you this, however, there is an inconsistency on how this issue
is treated. In sql it bombs, but, if you update the field using
field.AsString it happily truncates. >>

It's the TDataSet layer doing the truncation, and it does it before the data
ever gets to EDB:

From D7 db.pas:

procedure TStringField.SetAsString(const Value: string);
var
 pBuff: PChar;
 Temp: String;
 Buffer: array[0..dsMaxStringSize] of Char;
begin
 if DataSize > dsMaxStringSize then
 begin
   SetLength(Temp, strlen(PChar(Value))+1);
   pBuff := PChar(Temp);
   StrLCopy(pBuff, PChar(Value), strlen(PChar(Value)));
   if Transliterate then
     DataSet.Translate(pBuff, pBuff, True);
   SetData(pBuff);
 end else
 begin
   StrLCopy(Buffer, PChar(Value), Size); <<<<<<<<<<<<<<<<<<
   if Transliterate then
     DataSet.Translate(Buffer, Buffer, True);
   SetData(@Buffer);
 end;
end;

There's nothing I can do about this.

--
Tim Young
Elevate Software
www.elevatesoft.com