Jim,

Glad we can have some fun with this.

My only objective (as I hope I clearly stated) was to be able to be more
lazy in writing client apps and be able to come up with a working solution
that would be more robust. I know what is already in place can be worked
with.

What I am working on are two modules which heavily impact metadata. They are
tools to setup replication and full text searching. In the process of
setting up all this stuff the developer enters in specific criteria and then
they "load" the information which runs a series of scripts with a bunch of
macro substitution to plug in their desired names and expressions, etc. If
they happen to do something wrong it will result in a failure somewhere
along the way. Because I cannot place all of these metadata alterations in a
single super transaction (unless I faked it by doing backups and restores
which I don't want to get into) I have to write scripts to undo to the point
it succeeded prior to the failure so that when they fix their settings and
try again they will have a clean slate to start with again. This means that
I do a bunch of drops and something may be there or it may not be. If
something isn't there I get different errors depending on what it is I am
dropping. I found it to be a real pain in the rump to sort out all of the
different exceptions and to know which ones to ignore and which ones to make
an issue out of. For example, if it was an object in use error I didn't want
to ignore that because the metadata object was still there.

So, in order to get this working the way I wanted to I had to do a whole lot
of fiddling around and I am not completely satisfied that some user is going
to come up with some combination I did not anticipate and hit a show
stopper.

My suggestion was simply a thought that would have made my job much easier
and it makes perfect sense for such a solution to exist at the server API
level.

I read through Jim's ideas in more detail and it does sound like a more
ideal solution. It's quite a bit more of a shift from the SQL approach
because it is a lot more flexible than even I have suggested. It is so much
more flexible that it would beg an entirely different approach. For example,
I probably wouldn't even worry about starting from a clean slate each time
an attempt was made to load a " replication or full text search index".

Hope this clarifies a little.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <IB-Architect@yahoogroups.com>; <IB-Architect@yahoogroups.com>
Sent: Saturday, June 09, 2001 2:23 PM
Subject: Re: [IB-Architect] DROP [ IF EXISTS ] DOMAIN ...


> At 12:05 PM 6/9/01 -0700, Jason Wharton wrote:
> >
> >Mostly I want the ability to do a DROP and be able to tell it to ignore
> >raising an exception if the object has already been dropped or never
created
> >in the first place. I don't care what the syntax is. I leave that to the
> >rest of you.
> >
> >Jim's comments were to scattered for me to get a clear picture what he
was
> >talking about and how it related to my remarks. In one sense he seemed to
> >agree that a more flexible dialect be used but he seemed to avoid
agreeing
> >with me as much as possible.
> >
>
> I was wondering why you wanted a non-complaining DROP. I mused
> whether in was in preparation for an unconditional CREATE of a
> table of the same name, and wondered whether an UPGRADE TABLE
> was a satisfactory alternative (UPDATE TABLE would create the
> table if it didn't exist and transmogrify it in a generally
> upwards compatible way if it did).
>
> The more general point is that in order to evaluate an extension,
> it is important to understand what problem it purports to solve,
> and that a statement of the problem sometimes leads to a different
> but satisfactory solution.
>
> And, of course, to avoid agreeing with you if at all possible
> (Jason, that's a joke).
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>