At 21:33 09.02.2001, you wrote:

> > >Just add an ID field to the record. It is a lot easier to manage. The
> > >alternative
> > >is to use the generator number, * 100 + User ID, but it is a lot easier
> > >to find
> > >all the mods done by ID=X if you can just filter on that field!
>
> > Why is this easier to manage?
>For the reason stated - if you have a separate ID field you can filter
>on that and find all the mods by user X. Trying to apply MOD in a filter
>HAS to be slower.

Yes, but I did mention that I would almost never need this but use the
additional ID
field I use to mark who edited the record last.
It is just that I have this possiblity should I need it.

> > And about the generator number * 100 + UserID... Why do you think that
> > is any better or easier?
>
>Because you only increment the generator by one, and there is no chance
>of it getting 'corrupted' by not being a multiple of 100.

That is true. Generator corruption is the most dangerous thing I see in my
model.
That's why I need a clean application and no manual entry except where
triggers fire.
(For scripts this works great)

> > The ID would give me an additional field and my pk would be 2 fields >
> wide.
> > Is the mod UDF so slow
> > that it will seriously degrade performance if I ever need to check that?
>
>Anything that can not be indexed or easily filtered will be slow.
>
> > (Like I said there is more stuff to this peer to peer, I have a UserID
> > field that is used on every Edit/Insert,
> > but is changable so is not suitable for a PK, but is the only one I should
> > be needing when updating)
>
>The PK is STILL the Generator output, you do not need to add the user ID
>to it as only one user can add one number. If anything it prevents the
>situation where you COULD have the same top number with different users.
>123433 and 123444 are unique and will not be trapped by PK,
>While 1234 ID 33 will prevent 1234 ID 44 from being allowed.

Actually this states why your model won't work for me!
1234 ID 33 and 1234 ID 44 will not be allowed like you siad unless ID is part
of the primary key. Now I want clean merges, so any value generated by any
User should be allowed to merge. So this would work ONLY if ID was part of PK.
Because the Key is the generator number + ID. That would be the only way to
uniquly identify a record in the 'system' (=all peer to peer clients). And
that is the
criteria for a PK.

Now to the big drawback with this model is that I would have to link all
relations
to 2 fields. Any yes I do have a lot of relations. Most of my tables have
links to
other tables and some have multiple FK's.

So your point about Generator curruption is very true and well thken because a
single corrupted generator could prevent clean merges. The rest I don't
quite aggree with :)

Still thanks for advice :)