create table test
(
 col1 char(1),
 col2 varchar(1),
 col3 smallint,
 col4 integer
);
insert into test values ('abc','abc',32768,2147483648);

select * from test

The character string values have silently been truncated to 'a' and the
numeric values to 0.

I'd expect that string data truncation and numeric overflows in assignments
would raise proper exceptions.

Ole Willy Tuv

Ole,

<< I'd expect that string data truncation and numeric overflows in
assignments would raise proper exceptions.>>

Only in CLI-level access (ODBC) do we give warnings regarding string
truncation, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Only in CLI-level access (ODBC) do we give warnings regarding string
truncation, etc. >>

Yes, but would you consider to raise it at the SQL engine level ?

Silent data loss ain't pretty

Ole Willy Tuv

Ole,

<< Yes, but would you consider to raise it at the SQL engine level ? >>

I'll have to think about this a bit more.  There is no "SQL Level" in EDB,
so that means that it would get raised during simple assignments from a
TEDBTable, TEDBQuery, also.   I don't want to introduce another 8708 type of
situation that is just a giant pain in the ass for everyone.

<< Silent data loss ain't pretty >>

Yes, but it's not like EDB is doing so on its own - someone is trying to
assign a value that is incompatible with the defined column as it exists.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

IMO, data loss *always* can be reported to the user but you can introduce a
new event to developer deal with.
I think this is a very good way to deal with different point of view from
developers. The behavior of some operations can be customized by developer.
You just point the standard behavior.

For example:

procedure TEDBDataset.OnSpecialSituation(Sender: TObject: KindOfError:
String; RaiseException: Boolean);
begin
       if KindOfError = 'bla bla bla' then begin
           RaiseException := False;
       end;
end;

Eduardo