>this size of DB is tiny as things go - I wouldn't suspect the db size at all
>as being something which causes a problem.
>
>running out of memory may only come into play where you use tables and not
>queries - is this the case? or even lazy select all queries with no "where"
>filtering clauses - is this case?
>
>And in what circumstances would deleting the gdb file and replacing it with
>an emtpy file do anythign constructive? Does th app have all the ability to
>create all metadata from scratch when it finds missing tables?
>
>Alan

I agree about the DB size. But you must understand that the application has
been
converted (and not even fully converted) from DBF tables, 100MB is HUGE. :-D]

No tables are used at all. I try to put as much as possible into Stored
Procedures;
otherwise queries are used. All queries have a "where" clause, and
furthermore, each
and every query takes place within a transaction context. As soon as the
user is
finished with the query, it is close and committed. I try to make it as
atomic as possible,
and have, where at all possible, only one active transaction at any one
time. In some
cases, as soon as the client screen form loses focus, the transaction is
committed and
the query closed, to be re - opened again when the form regains focus.
However, none of these
occur when the problem occurs.

The DB size may be tiny. But so is the RAM.

Deleting the GDB makes the engineers feel like they are actually
accomplishing something,
even if it's the wrong thing. You know the old saying - "when all you have
is a hammer,
everything looks like a nail". Well, they know how to delete a file. And
the app comes with
the metadata, so they can recreate the GDB at will. And the problem does go
away, although
not for long. :-)

Regards

Tim


[Non-text portions of this message have been removed]