>>What kind of crash? Any messages in the log?
>>Creating/activating indexes for millions of records may require large
>>temporary files - maybe this space was not availbale?

> The server itself does not crash.

I should have paid more attention to the wording in your post!
But, you wrote:

> The updates did not crash, however activating the indices again did.

This is why I indicated that you should check whether you temp areas were
large enough to hold temporary sort files that may be used when indexes are
created/avtivated. There may be mention of sort files in the log if the
process does not end successfully.

> The rebuild is taking up to 18 hours to complete.

This seems excessive. Is this only 1 index?
You are using Fb/1.5 ?
What kind of hardware? Does changing Page Size or Page Buffers help?
Will generating indexes benefit from turning ForceWrites OFF ?

> Even with indices a single query took 82 minutes on 11 million records.

Did the plan look ok? Sometimes it is more efficient to have a table scan
(plan NATURAL) than utilizing an index.

> I will routinely be inserting millions of rows into the database and
> be updating and deleting them.

Updating indexed field with _lots_ of duplicates _is_ very slow. Same
problem with deletes.


<<
I don't know the exact amount of time since even when it
has completed, *and* set the inactive flag to false in RDB$INDICES, the
programs are not continueing with the execution of their code. I am by no
means an expert with the background operations of ADO, but I am assuming
that some sort of information is being passed back from the server when a
commit transaction is called. I beleive the programs are waiting for this
information that is never being sent from the server.

>>

After issuing COMMIT, your program (or thread) will wait for the server to
do its thing - no matter what tool you are using (ADO or whatever
else). If it's a longish operation your program will appear to be "hung".


--
Aage J.