> I think I have a larger problem. Deactivating the indices worked
> wonderfully. The updates did not crash, however activating the indices
> again did. Point in fact, I cannot seem to do any large operations on

the

> database anymore without crashing period. That includes gbak. My

question

> now is whether or not anybody else out there has tried something like

this

> with more than 10 million rows.


>>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?


>>--
>>Aage J.

The server itself does not crash. Its the programs being used to manipulate
it. Also, crash
may not be the best word. "Hung" may be more appropriate. I have used
IBWorkbench, M$ Access, and VB6 to activate and deactivate the indices. At
the same time I am pulling a select statement on RDB$INDICES for that
particular index to check its inactive flag with a separate connection. I
am sure that the following situation is essentially true with IBWorkbench as
well as VB within Access and VB6. I start the transaction, execute the
statement "ALTER INDEX BLAH_BLAH_BLAH ACTIVE", and then commit the
transaction. The execute obviously comes back very quickly. The commit
however is where all the programs seem "hung". They never receive a
commitcomplete event. I noticed with the server itself, that even though I
stopped the program after a period of time, it was still rebuilding the
index in an attempt to carry out the commit. I was able to see this with
the select statement on the RDB$INDICES. The rebuild is taking up to 18
hours to complete. 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.

This is a very big problem for me. I will routinely be inserting millions
of rows into the database and be updating and deleting them. With no
indices it would of course be faster now that I understand its rebuilding
the indices after every update. However, at many times I will be performing
reports on this data and indices are crucial to getting them in a viable
time period. Even with indices a single query took 82 minutes on 11 million
records.