Thanks very much for your advice.  When I checked the MSysConflicts
table, the reason for all the conflicts (and yes, the 'deleted' records
were on conflicts tables and the Conflict Viewer didn't pick them up)
was that the data was in a corrupted database.  I had to manually merge
the data changes, no fun with more than 800 records in a dozen tables!

I will try indirect replication - am I right in that I have to use
Replication Manager?
The network guy was there today and claims no problems with the
network, but found damaged files on the notebook's hard drive, so they
will probably replace that machine...fingers crossed!

I would strongly disagree with this diagnosis.

1. first, make sure that both machines have Access 2K SR1 or later
(it may be called a service pack, I can't remember). Second, make
sure that you apply Jet 4 SP6 or later (the last I knew about was 8;
6 was stable, 7 was pulled quickly for bugs, and 8 added in some
additional security to avoid exposure to exploits that could execute
arbitrary code through the Jet expression service). Without that
scenario, you're guaranteed to have continued corruption issues, no
matter how stable your network.

2. I can't see how network issues could possibly cause corruption,
in any case, since if you're using the network to update the db on
the other computer, why in the world is replication needed in the
first place? Of course, you say you're using a Win98 workstation as
the peer-to-peer server, and a Win2K desktop connecting to it. I'm
pretty sure that's a problematic scenario. I don't remember the
details, but I think there were problems with Win2K connecting to
Win98 machines. And I always found the Win98 networking
infrastructure very hard to keep running well. So, you may need to
upgrade the peer-to-peer server to a real version of Windows (Win2K
would be just fine), or replace that workstation with a different
workstation running Win2K or WinXP (or NT 4, for that matter). On
the other hand, I had a client running with Win95 on the
peer-to-peer server and Win2K on their laptop, and it worked just
great. But, again, that just supports my experience that Win98 is an
outlier in terms of ease of networking.

3. I assume the basics, that you have a split front end/back end,
with forms, reports and so forth in the front end and only data
tables in the back end, and that you're only replicating the back
end. I also assume that you have some reason for replicating the
back end -- your explanation doesn't make clear to me why you'd have
any need for replication at all. Could it perhaps be that when the
laptop is in the office, it connects to the back end on the Win98
box, and when the laptop is on the road, it uses a replica on the
laptop's hard drive? That would justify replication and that's the
only replication scenario I use any longer with any of my clients
(all remote application sharing for my clients is now done via
hosting on Windows Terminal Server). If you have replicated the
front end project, that's likely to be your problem, as opening and
closing a form updates certain properties (especially if your users
are doing sorting and filtering, for instance, which are saved with
the form when it is closed), and these could automatically be
causing real conflicts in the data describing the structure of the
forms. To repeat: replication works only for pure Jet objects. That
means, data tables and queries only. All other objects are stored in
Jet, but are not Jet objects, but Access objects (forms, reports,
macros, modules), and should not be replicated.

4. more on conflicts: assuming that you are replicating only the
back end, let me address your assertions about the "unreal"
conflicts. Keep in mind that Jet replication uses not a
"human-sensical" definition of edits, but a mechanical count of
number of edits (i.e., generations of changes, where each generation
is an individual change). Here's a scenario that would produce a
conflict for the Jet replication system, but would not appear to a
human being to be a real conflict:

Replica A and B have the same replica priority (all replicas have
certain priorities for the resolution of conflicts; for instance, a
design master has a higher priority than any of its replicas; this
priority is used to resolve ties between changes in records). In
Replica A, you change the zip code of a record from 1135 to 01135.
Someone working in Replica B sees the same error in the same record
(probably from an import that didn't insert leading zeros into a zip
code column stored as numeric instead of as text), and changes 1135
to 01135. Now, both records have been changed, but both have been
changed to precisely the same value. But they both have incremented
generation numbers for the zip code field. Thus, the change needs to
be propogated. Assuming the replicas have the same priority (which
is not always a correct priority), this has to be a conflict for the
Jet replication system, even if it's *not* a conflict for a human
being (since the records have the same data). The key is: the
synchronization process ignores the actual data values and uses
nothing but generation numbers and replica priority to resolve
conflicts.

Now, another cause of "phantom" conflicts could be an application
that is unnecessarily dirtying and saving records. Say you've got a
form where, for whatever reason, your programmer has decided that
it's necessary for some reason to dirty the form. The easiest way to
do this is to set a field equal to itself:

 Me!MyField = Me!MyField

The record then gets saved afterwards, one way or the other.

Now, this isn't a real data change, but for replication, it
increments the generation number for that field. If it's part of the
application, it's going to happen for the records in every copy of
the application, so it's absolutely guaranteed to produce conflicts.

Another source of annoying conflicts is if you replicate temp
tables. These will constantly have data recycled, so you really
don't want the changes in them propagated to the other members of
the replica set. I recently converted an old app that had a flag
field in it that was used for marking records according to certain
kinds of complex criteria not easily implemented with SQL. When the
app was replicated, I moved the flag field to a separate 1:1 table
that was *not* replicated so that changes to it wouldn't propagate
to the replicas (as it wasn't meaningful data except for a certain
search context, and had no value in persistence).

5. invisible conflicts: this could be caused by a number of
problems, but I think the most likely is perhaps empty or erroneous
conflict tables. When there's a conflict, a conflict table is
created with the name BaseTable_Conflict, and if somehow the
conflicts in that table have somehow been resolved, but didn't get
deleted from the conflict table, you can get continued reports of
conflicts. So, you need to check these conflict tables to see if the
conflicts reported still exist (and you have to check all the
replicas in the replica set to be sure). If they no longer exist,
then you can delete the conflict table, and that should take care of
the problem.

In short, your report of corruption tends to suggest to me that your
problem is that you're using one of the horrendously buggy early
versions of Jet 4, and/or the initial release of Access 2K. Bring
those up to spec (as outlined at the top of this long message) and
see if that gets rid of the problem.

Last of all, for issues of corruption, you can't go wrong by
starting here:

 http://www.granite.ab.ca/access/corruptmdbs.htm

You'll find that this page walks you through all the causes for
corruption in the various versions of Access with pointers to all
the documentation and resources you need to troubleshoot the
problem.

But I'm not entirely certain you've identified corruption in the
conventional sense (though I suspect a corrupted PK index -- you
have compacted your replicas, right?). You may have a corrupted data
set, though, in terms of replication synchronization, where the
replicas are not identical after a synchronization.