Subject | Re: [IBO] How to get the IBO object that caused the error? |
---|---|
Author | Helen Borrie |
Post date | 2002-10-03T08:04:44Z |
At 10:13 AM 03-10-02 +0300, you wrote:
exception. I agree with your opinion expressed in another message that
this is a pain if you are trapping all of your exceptions in the OnError
event of the connection object. I haven't found a better way than to trap
dataset errors in their own OnError event and pass a "callsign" to a custom
property of the datamodule, which can be read by the connection-level
handler when it responds to an error event.
go the whole hog with inheritance and inherit your own custom sub-class
that has a callsign property which updates itself when the dataset catches
an error. Yes, it would be nice if both the TIBO* and TIB_ datasets
already had such a property.
was too chancy if I wanted to get at client-side info. Anyway, I prefer an
OO solution to layers and layers of re-parsing. Somewhere in my long
agenda is an intention to do a sample app with centralised error handling.
Helen
>"Helen Borrie" <helebor@...> wrote in messageThe Sender parameter gets the pointer to the object that raised the
>news:5.1.0.14.2.20021002180845.0f1f1ea0@......
> > At 09:00 AM 02-10-02 +0300, you wrote:
> > >How to get the IBO object that caused the error?
> > >
> > >When we have an error in TIB(O)Database we have the also, as string, the
> > >full path of one (or two) IBO objects which triggered the error.
> > >
> > >How can we have a pointer to that object?
> >
> > All object references in Delphi are pointers.
> >
>
>Of course, but how can I get _that_ pointer?
exception. I agree with your opinion expressed in another message that
this is a pain if you are trapping all of your exceptions in the OnError
event of the connection object. I haven't found a better way than to trap
dataset errors in their own OnError event and pass a "callsign" to a custom
property of the datamodule, which can be read by the connection-level
handler when it responds to an error event.
>For example, I have a Unique Key violation because the user entered aAgreed. You can either define a callsign mechanism in your datamodule or
>duplicate value 'somewhere' in the system.
>It sould be very nice for me to have that dataset available in the error
>handler to do a <that dataset>.Cancel
go the whole hog with inheritance and inherit your own custom sub-class
that has a callsign property which updates itself when the dataset catches
an error. Yes, it would be nice if both the TIBO* and TIB_ datasets
already had such a property.
> >Sure. I had several attempts at parsing the message strings and decided it
> > >Why we have two objects sometimes? The second one is the encapsulated
> > >TIB_query of TIBO component?
> >
> > Yes. The InternalDataset property gives you run-time access to the
> > TIB_BDataset wrapper of the TIBOQuery.
>
>Perhaps I wasn't clear in my message. For example I have the following error
>caused by an TIBOQuery:
>
>Err: ISC ERROR CODE:335544349
>
>ISC ERROR MESSAGE:
>attempt to store duplicate value (visible to active transactions) in unique
>index "IDXNAME"
>
>STATEMENT:
>TIB_Statement:
>"<TApplication>.frmMain.fraAFinder1.ibtViwAcc.IBOqribtViwAcc.<TIB_UpdateSQL>
>.<TIB_Statement>."
>
>
>STATEMENT:
>TIBOInternalDataset:
>"<TApplication>.frmMain.fraAFinder1.ibtViwAcc.IBOqribtViwAcc."
>
>I need, as I stated before, the object(s) which are represented by the above
>string(s) in order to issuse an appropiate centralized action (based on the
>user choice), something like 'Do you want to rollback your edit?'
was too chancy if I wanted to get at client-side info. Anyway, I prefer an
OO solution to layers and layers of re-parsing. Somewhere in my long
agenda is an intention to do a sample app with centralised error handling.
Helen