On Tue, 6 Jan 2004 22:32:16 +0000 (UTC), Evelyne Girard wrote:

>
>> This can be a SWEEP (garbage collection). Usually caused by programs that
>> keep transactions open over a long period, using "commit retaining", and
>> not doing preventive garbage collection (sweep, backup (gbak)).
>
> I only found secondary databases for which sweep wasn't set to 0 and these
> DB were tiny and I don't even think they're used on a regular basis.

Well then, there must be something else ...
What kind of activity triggers the 100%CPU problem? Deleting records where
an indexed field has _lots_ of duplicates? Or updating such a
field? Joining where no matching indexes exist (causing table scans)? Any
inactive or missing index?
You wrote that you don't expect the cause to be "bad SQL request", maybe
you'll have to revisit this. Not easy,very time consuming, and tedious (I
know!).
I don't really have other ideas, maybe someone else can see something ?

> By the
> way, how could I know if there is another database on this server ? Is
> there a way to get that list (since every programmer in the shop can create
> databases in a lot of directories) ?

I don't think so. You could scan the server for *.gdb files, but they may
have been named differently.
If you use the new config and alias files it seems you can restrict
creation of databases.

>
>> Which server version are you using?
> 1.5 RC7 but I had the same problem since last summer (don't remember
> which version it was then).
>
>> What kind of middleware (BDE, IBX, IBO, FIB+, ...)
> The main programs are using FIB+ others are working with IBX (Delphi5 or
> Delphi7). The problem was there before our switching from IBX to FIB+.
> The server is Windows Server 2003.
>
> Was I correct about the assumption that a Classic installation would let
> me know which connection is at fault ?

I don't know - I've never used classic.


--
Aage J.