I'm running into a serious problem with EDB 2 as it raises an exception if a
string field gets a value longer than the field size.

So if I have this field:

MyField VARCHAR(5)

and assign a more than 5 char long string to that field like
Table1MyFiled.Value := 'xxxxxxxx' it raises the error 1011. In DBISAM or any
ohter DBMS I know, this string gets simply truncated with no error. This is
what I expect from EDB too. This behaviour as it is, is very bad and I
wonder if I can disable that check somehow.

I have some dataimport routines which now don't work anymore, as they now
raise this error on some import values. It is absolutly the job of the DBMS
to save the max length of data to the DB without to raisen an error and
should not be the job of the client application. This looks like a very
disapointing feature for me.

If we now must truncate any string our self to the max fieldsize this is a
big step back against DBSIAM. So I can't believe there isn't a switch for
this behaviour somewhere, but where?

Regards
Rolf

Rolf

>I'm running into a serious problem with EDB 2 as it raises an exception if a
>string field gets a value longer than the field size.

According to Tim its part of the SQL:2003 spec. He has the choice of raising a warning or an exception, but there's no way in Delphi to raise a warning and continue all you can do is raise an exception. I've never tried it but I don't think you can eat it in the OnPostError event.

I presume you're using querys, or something other than Delphi, since TDataset which TEDBTable inherits from does still truncate.

Also, if you haven't already noticed ElevateDB will no longer TRIM VARCHARs so you'll have to handle that as well. I mainly use tables and I've built the necessary functionality into a table component and posted it to the binaries. I'm not sure how or where I could do it in a generic way for a query.

Roy Lambert [Team Elevate]

Rolf,

<< I have some dataimport routines which now don't work anymore, as they now
raise this error on some import values. It is absolutly the job of the DBMS
to save the max length of data to the DB without to raisen an error and
should not be the job of the client application. >>

Actually, the job of the database engine is the exact opposite - it is not
supposed to add data to a table that has been truncated and will result in
missing data, but rather is supposed to notify the developer/user of such a
condition and allow them to take the appropriate action.

<< If we now must truncate any string our self to the max fieldsize this is
a big step back against DBSIAM. So I can't believe there isn't a switch for
this behaviour somewhere, but where? >>

There is no switch, but I'll see what I can do for an upcoming minor
release.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


To reintroduce the behaviour I wanted I subclassed TEDBTable. Is there a way to do it with a query and script - if so can you give a few hints?

Roy Lambert

Roy,

<< To reintroduce the behaviour I wanted I subclassed TEDBTable. Is there a
way to do it with a query and script - if so can you give a few hints? >>

Which behavior - the string trimming or avoiding the truncation error ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Which behavior - the string trimming or avoiding the truncation error ?

Both really. If I was only using SQL the fact that strings aren't RTRIMed wouldn't matter because you ignore the trailing spaces, but if you compare in Delphi there's a problem, and I often assign a string to a field anticipating its going to be truncated eg I may have a field which indicates status and all I'm going to store is 1 character (say the first character from Live, Dead, Hold) so I just assign the string knowing that I'll end up with L, D or H stored.

I can do that with tables but it would be nice to use SQL as well. I think I could probably do something with a query but I don't think anything would be possible with a script.

Roy Lambert