O7: Duplicate keys and segment issues in a native datafile

[Jean Marc AZERAD]

Hi Geir,
>
>
> So they have a few questions:
>
> 1. When moving the datafiles from one location to another, how does  
> Omnis
> know where the second segment is? Is there something you must do to  
> update
> the segment table (or wherever the information is stored) when  
> moving a
> database like that?

Moving a datafile including more than one segment may be a pain, I did  
an answer on this list on the very same subject a few years ago. You  
may be able to find it in the archive.
Omnis seems to have some kind of "double link" to the second segment,  
one seems to be a pointer inside the first segment to the second  
segment (hard coded path), the other is a way of looking for a second  
segment beside the first one, but the pointer seems to have priority.
This means that if you move your segments to a new server or a new  
folder and the old path is still active, you may be writing in the NEW  
first segment and into the OLD second segment.
Moreover, if some users have access to the old path and other no, you  
may end up with a mixture of some writing into the new and other in  
the old second segment.
The fact that the date of the second segment is unchanged is in favor  
of everyone being in the same situation (new first, old second).

For sure this does messes up the indexes and this is when your get  
duplicate RSN numbers.
By the way, remember NEVER to reorganise a file with corrupted indexes  
or you'll loose data, always repair and check the indexes at least  
twice before a reorg.


>
> 2. They are referring to the datafile using UNC paths rather than  
> computer
> names. Can this cause problems with multiple segments, especially when
> relocating the datafile?

As far as I know, no problem, its the best solution

> 4. It is of course entirely possible that the new server has  
> Opportunistic
> Locking etc turned on. Which would be a bad thing. But could that  
> cause
> users to get duplicated values back?

Yes, it could be a cause
>

JM