Re: Quickfinder stops with C042 error on user db

[Dave Parkes]

C042 is what you get from concurrent access that the system can't cope
with very well. I'd guess from the way you describe the system, the two
POAs are squabbling over which one is controlling the db.

I'd try just letting the indexer run on the main one, ensuring you have
the /qflevel-999 in that startup file and see if that gets round the problem

Cheers Dave

--
Dave Parkes [NSCS]
Occasionally resident at http://support-forums.novell.com/

[Dave Parkes]

But as the main POA processes an incomng message or deletes an existing
one, then the secondary POA will get out of step as it caches the user.db
to some extent - hence the C042 error.

The indexer running on a single user.db really shouldn't take hours except
if the db is huge or the machine is really overworked. The single POA
should be able to cope with the task of indexing provided that the
indexing process is run sufficiently frequently to keep the indexer ahead
of the incoming traffic. that's where the /qflevel-999 flag comes in handy
if the server is very high traffic.

I'm still puzzled though by how the indexer is getting so behind on
certain accounts on your system, I know we've been through the details
before, but I can't recall all of them <g>. What was the problem with the
single POA, say index every couple of hours, again ?

[Dave Parkes]

But what still gets me is precisely why the indexes are breaking down
occasionally, that is still the root problem that is to be resolved here.

[Dave Parkes]

Well, I've never been a fan of having two post office agents accessing the
same files, as that at least opens the door for things to get locked.

Definitely no chance of the GW accounts using direct access ?, or any
other outside processes interfering with the GW files

I'd guess the accounts that go strange are either the big ones, the busy
ones or both. I'd always put the /qfevel-999 switch in the main poa
startup file, and possibly bump up the indexing frequency a bit, say every
2 hours instead of 3 for example. That would hopefully at least increase
the time between problems occurring.

[Dave Parkes]

Don't let the indexing process clash with any scheduled GWChecks. Those
file sizes are pretty big though, if you ever get any user.db rebuilds
then the entire indexing process for that account starts from scratch.

Set the indexer to run fairly frequently and have the -999 switch in your
standard poa startup file.

I'd take a stab at user.db rebuilds being the cause of your index
problems, that can happen occasionally if a message comes in while a
GWCheck is processing that user.db, and the bigger the user.db the bigger
the time window in which that sort of clash can occur.