Helen,

thanks, but it doesn't work, I still get the error message about the FK
violation. If I set the RaiseException to False, then I get the "Record was
not located for delete" error. Here's my code exactly:

procedure TCustomerForm.CustomersQueryError(Sender: TObject;
const ERRCODE: Integer; ErrorMessage, ErrorCodes: TStringList;
const SQLCODE: Integer; SQLMessage, SQL: TStringList;
var RaiseException: Boolean);
begin
if ERRCODE = isc_foreign_key then
begin
ShowMessage(rsForeignKeyViolation); // the error message
TIB_Query(Sender).Cancel;
// RaiseException := False; // If this is uncommented, "Record was not
located to delete"
end;
end;

I get my own message ok (and I'm not interested (for now) in catching other
errors), but still there is another error message thrown. Any ideas?


Antti Kurenniemi

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, September 21, 2006 9:37 AM
Subject: Re: [IBO] Handling a FK violation in OnError


> At 03:47 PM 21/09/2006, you wrote:
>>Thank you, Helen. I have two additional questions: how exactly do I cancel
>>the delete in the OnError, to prevent the exception from being displayed?
>
> case ERRCODE of
> isc_foreign_key:
> begin
> ShowMessage('Cannot delete Whatever because it contains Whatever');
> Sender.Cancel;
> end;
> another_symbol: blah
> ...
> else
> RaiseException := true;
> end;
>
>
>>And, is there a way to "ask" the database via IBO (or any other way) if a
>>record can be deleted? The way I do it now is first ask the user if they
>>really want to delete the record, then attempt to delete it and then throw
>>an error if the delete fails, which is sort of clumsy.
>
> No, because they are two altogether different things. In the first
> case, it's entirely a matter between the application and the user -
> it has nothing to do with the database. In the second, you're
> intercepting a database error condition and handling it. Besides
> that, isc_foreign_key is not the only possible exception condition
> that will prevent the cancel from succeeding.
>
> Helen
>
>