Roy,

You should be able to either trap this error or make it occur in a
friendlier manner. Something along these lines:

Add an error flag to the TDataset descendant:

FInitError: Boolean;


Override InitRecord

try
  FInitError := False; // shouldn't really be necessary
  inherited InitRecord(Buffer)
except
  FInitError := True;
end;

override DoOnNewRecord, which is executed inside an exception handler in
   EndInsertAppend

if FInitError then begin
  FInitError := False;
  raise exception.create('Error initializing record values');
end;
inherited;

you could also get fancier and keep track of the exception class and
message.

Sean


Tim Young [Elevate Software] wrote:
> Roy,
>
> << Forget this specific example, concentrate on the general principle. There
> is an error which I cannot trap for being allowed out into the wild. >>
>
> Yes, because there's really no way of interrupting the process of assigning
> the default values other than via an exception.  The TDataSet architecture
> is such that we get one method call (InternalInitRecord) to initialize a
> row, and we use it to assign the default values from the columns so that
> they are visible at insert time.  Now, you may want to suppress this
> exception, but I still think that's a bad idea since it simply kicks the can
> down the road and causes the user to wonder where the default value has
> gone, or why it is truncated for no apparent reason.
>
> In summary, even if there were an event handler that trapped such an
> exception, it would be forced to:
>
> 1) Simply adjust the column default value so that it fit the column (not
> exactly easy to do since you would need to know what the default expression
> is to start with, and have a method of evaluating the SQL to generate a
> value).
>
> 2) Exchange the real exception for a silent abort exception, thus
> encountering the same grid display issues that you're seeing elsewhere.
>
> You simply cannot have an exception in the InternalInitRecord without it
> causing weird issues with the TDataSet component.  The design is such that
> is does not expect exceptions in this method, and there's nothing I can do
> about that short of telling you how to modify the db.pas to have it trap for
> such an occurrence and handle it properly:
>
> procedure TDataSet.Append;
> var
>   Buffer: PChar;
> begin
>   BeginInsertAppend;
>   ClearBuffers;
>   Buffer := FBuffers[0];
>   InitRecord(Buffer);  <<<<<<<<<< This is where the exception occurs.
> Notice that there is *zero* exception handling here and that the buffers are
> already moved around in a way that assumes that there won't be any
> exceptions
>   SetBookmarkFlag(Buffer, bfEOF);
>   FRecordCount := 1;
>   FBOF := False;
>   GetPriorRecords;
>   InternalInsert;
>   EndInsertAppend;
> end;
>
> It seems to me that you should be using the OnNewRecord event instead of the
> built-in SQL defaults if you want to assign default values to columns that
> exceed the column length.  The built-in defaults must issue an exception if
> there is truncation, and that isn't what you want.  You're also free to make
> a descendant of TEDBTable that simply eats any exceptions in the
> InternalInitRecord method.
>

Tim

>but I still think that's a bad idea since it simply kicks the can
>down the road and causes the user to wonder where the default value has
>gone, or why it is truncated for no apparent reason.

After 30+ years messing with computers I cannot bring to mind an occurrence of someone asking me about a field being truncated. I'm sure there must have been gazillions of such incidents, possibly resulting in software being rejected, otherwise why would the great and good who formulated the sql standards have mandated it?

(Tim please note this, at least partially, a joke/sarcasm and does not require rebuttal or defence)

>You simply cannot have an exception in the InternalInitRecord without it
>causing weird issues with the TDataSet component. The design is such that
>is does not expect exceptions in this method, and there's nothing I can do
>about that short of telling you how to modify the db.pas to have it trap for
>such an occurrence and handle it properly:

How about telling CodeGear? Do you think there's a chance they may listen? Altering their or your source code is not something I really want to do.

>It seems to me that you should be using the OnNewRecord event instead of the
>built-in SQL defaults if you want to assign default values to columns that
>exceed the column length.

I don't WANT to assign default values that are larger than the column length, its just that this is what brought the problem to light.

To save me a lot of testing I have a simple question to which a yes/no answer would be appreciated, with additional explanation if the answer is no, but non needed if its yes. Is an oversized DEFAULT value the ONLY way that this exception can be generated without it being handleable with the current events/trigger etc.

>You're also free to make
>a descendant of TEDBTable that simply eats any exceptions in the
>InternalInitRecord method.

I'll investigate that one. I've already pretty much decided that I'll remove the facility for user to set defaults.

Roy Lambert

Roy,

<< How about telling CodeGear? Do you think there's a chance they may
listen? Altering their or your source code is not something I really want to
do. >>

They may, or may not.  This code has been in place since at least D5,
however, so new fixes won't really help the older versions of Delphi.

<< To save me a lot of testing I have a simple question to which a yes/no
answer would be appreciated, with additional explanation if the answer is
no, but non needed if its yes. Is an oversized DEFAULT value the ONLY way
that this exception can be generated without it being handleable with the
current events/trigger etc. >>

Well, it's the only way that an InitializeRecord would fail.  As for a
comprehensive survey of the TDataSet architecture cross-referenced against
the entire ElevateDB engine and all of the possible failure points, I'll
have to leave that for another day.

<< I'll investigate that one. I've already pretty much decided that I'll
remove the facility for user to set defaults. >>

Is there any particular reason that you don't just handle such defaulting in
before insert triggers instead ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Well, it's the only way that an InitializeRecord would fail.

Good that gives me options

>As for a
>comprehensive survey of the TDataSet architecture cross-referenced against
>the entire ElevateDB engine and all of the possible failure points, I'll
>have to leave that for another day.

I would have thought laying in bed with nothing to do you would have become bored enough to do this

><< I'll investigate that one. I've already pretty much decided that I'll
>remove the facility for user to set defaults. >>
>
>Is there any particular reason that you don't just handle such defaulting in
>before insert triggers instead ?

If it was just me typing as part of an app no reason. If its allowing the users to enter this sort of stuff then it means a more complicated editor and knowing users they'd find a way to break it.

Roy Lambert

Roy,

<< I would have thought laying in bed with nothing to do you would have
become bored enough to do this >>

It was all I could do not to throw up, let alone think about work stuff.

<< If it was just me typing as part of an app no reason. If its allowing the
users to enter this sort of stuff then it means a more complicated editor
and knowing users they'd find a way to break it. >>

Well, I was thinking more along the lines of just allowing simple default
constants, and then just putting them in place using SQL in a trigger within
the scope of a BEGIN..EXCEPT block.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>It was all I could do not to throw up, let alone think about work stuff.

Ah. Sam said flu when she sent out the "poor little man's not well" emails. I now see more sympathy is required <vbg>

Roy Lambert

Roy,

<< Ah. Sam said flu when she sent out the "poor little man's not well"
emails. I now see more sympathy is required <vbg> >>

Yes, unfortunately it was the stomach flu (viral gastroenteritis).  All the
doc could do is give me some anti-nausea pills and some headache pills with
some sedative in them, and tell me to wait it out.  

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Yes, unfortunately it was the stomach flu (viral gastroenteritis). All the
>doc could do is give me some anti-nausea pills and some headache pills with
>some sedative in them, and tell me to wait it out.

I remember once when my wife had food poisoning the doctors comment was along the lines of: you have 23 feet of intestine - you'll just have to wait until they're all empty.

Roy Lambert

Tim,

I am glad you'r back

Regards,
Hüseyin

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> skrev i en
meddelelse news:00D67D4A-E43A-48E5-AC00-9418EEA91DAF@news.elevatesoft.com...
> Roy,
>
> << Ah. Sam said flu when she sent out the "poor little man's not well"
> emails. I now see more sympathy is required <vbg> >>
>
> Yes, unfortunately it was the stomach flu (viral gastroenteritis).  All
> the doc could do is give me some anti-nausea pills and some headache pills
> with some sedative in them, and tell me to wait it out.  
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Roy,

<< I remember once when my wife had food poisoning the doctors comment was
along the lines of: you have 23 feet of intestine - you'll just have to wait
until they're all empty. >>

Yes, I've had food poisoning before, and fortunately this wasn't it.

--
Tim Young
Elevate Software
www.elevatesoft.com