Mark,

> i suppose you could build a container object that would own several little
> SQL statement objects. then you could build the collection and stream the
> whole thing to a persistent file.
>
> then just build a mechanism that would load be able to open up the file /
> container object and index to each of the SQL statement objects and then
> submit each of them to your API.

I think is all that needs to be done is feed off of a TStream of any kind
and keep in a buffer anything it needs to refer back to. As each statement
is executed it just works its way through the contents of the TStream. Thus
no more than one statement at a time needs to be held in the buffer. Also,
when I design the ability to do more things, it can store reference points
on a stack, etc.

> ironically - the script that i am producing is coming from a hierarchical
> container object that i use to collect the data from oracle. each of the
> different object in the container has (among other things) an InserSQL
> property, UpdateSQL property and so on. then i built a TIterator object
> that knows how to iterate the hierarchy. to dump everything out - i just

to

> this:
>
> MyIterObject.Iterate;
>
> the object has an event handler for each level in the hierarchy. this is
> where you can selectively capture the sql at every level.
>
> until you mentioned it - i never thought about streaming the hierarchical
> object container. i should probably do this too.

How about skipping the step of even producing a script and just directly
create the database?

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