Subject | Re: [IBO] can IBObjects help with identifying where an IB script fails ? |
---|---|
Author | Jason Wharton |
Post date | 2001-10-25T16:42:55Z |
I've heard that using my TIB_Script component handled large scripts where
ISQL failed.
I suggest you write a simple IBO program and see if it works for you.
If it still fails, you can turn on logging and use text searching to locate
where in the script it failed to the exact statement.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
ISQL failed.
I suggest you write a simple IBO program and see if it works for you.
If it still fails, you can turn on logging and use text searching to locate
where in the script it failed to the exact statement.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Mark Meyer" <mmeyer@...>
To: "IBObjects@Yahoogroups. Com (E-mail)" <IBObjects@yahoogroups.com>
Sent: Thursday, October 25, 2001 9:43 AM
Subject: [IBO] can IBObjects help with identifying where an IB script fails
?
> hi everyone..
>
> i was referred to this list by someone on the IB-Support list. i am
> unfamiliar with IBObjects and what they can do.
>
> Question:
>
> what is the best way to identify where and why an interbase script failed
> when
> running it inside of either interbase utility ISQL or WISQL. this seems
like
> something that should be very simple to do - right ?
>
> Background:
>
> i have written a delphi utility that produces a VERY LARGE interbase
script
> (several thousand lines). the purpose of the script is to perform mass
> updates/deletes/inserts to an IB schema based on a daily oracle .dmp
(dump)
> file
> that we receive from a vendor.
>
> the intent is to produce the script each day and submit it to either ISQL
or
> WISQL. i also want to bullet-proof this so that our operations group can
> perform this
> task un-assisted.
>
> since the script is so large i need a way of identifying the offending SQL
> line in the script that caused the failure. during testing - i found no
> good way to do this inside of either WISQL or ISQL.
>
> we have identified that the most likely reason the script may fail during
> production - is bad data coming from the vendor.
>
> i realize that i could just fire the sql inside of a delphi app and log
the
> progress/failure points. however - there are several reasons why having
the
> delphi app produce the script and then submitting the script to ISQL or
> WISQL is advantageous.
>
> thx for any help
> mark
> CONFIDENTIALITY NOTICE: The information contained in the transmission is
> considered by TravelCLICK and the sender to be confidential. This material
> is intended only for the use of the recipient(s) named above and may not
be
> disclosed to others without express written consent of the sender.