Mysterious error: "Uniqueness of index...is violated"

[Jim Walsh]

I'm getting an error message saying "Uniqueness of index SESSIONID is
violated". The error comes when my form attempts to execute the following
statement:

lFound = SEEK(lSessionID, 'Sessions', 'SessionID')

SessionID is the primary index of the Sessions table.

I don't understand how the SEEK function could be modifying the index of
this table.

Any ideas?

Thanks,
Jim

[Cindy Winegarden]

In news: uPb3IcFa...@TK2MSFTNGP09.phx.gbl,

Hi Jim,

Any chance the record pointer is on an uncommitted record when you issue the
Seek()? If the pointer is on an uncommitted record having a duplicate key
and the Seek() moves the record pointer then you might get this error,
although I can't make it happen in a quick test.

--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
cindy.wi...@mvps.org www.cindywinegarden.com

[Lee Mitchell]

Hi Jim:

Does the error occur if you use an INDEXSEEK instead of a SEEK() function?
I found one reported case where disabling UseWriteBehind, Opportunistic
Locking, and CacheOpenLimit on the server and disabling redirector and NT
Caching on the workstations fixed the problem. Could you have a corrupted
index? Have you tried recreating the index from scratch? (Don't use the
REINDEX command for this task.)

I found these articles that mention this error in one context or another.

142283 PRB: Uniqueness of Index Violated When Creating Primary Index
http://support.microsoft.com/?id=142283

139756 PRB: Cannot Reuse Deleted Primary Key Values in Visual FoxPro
http://support.microsoft.com/?id=139756

190318 PRB: BINTOC() Fails with SET COLLATE TO "GENERAL"
http://support.microsoft.com/?id=190318

317364 FIX: A Second TABLEUPDATE After Failure Due To "Uniqueness of Index
http://support.microsoft.com/?id=317364
170148 FIX: Cannot Trap Error Number 1884 on Form
http://support.microsoft.com/?id=170148

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003

[Jim Walsh]

Cindy,

Thanks for your quick response to my posting. I have been trying to see
today if that is the case, but it appears not.

I didn't include much detail in my original posting for fear of confusing
things. However, I may not have given enough information to help myself.
Here is what I'm doing.

I have a main form (VISITS) that calls a second form (ReassignPicture) as a
subroutine. The VISITS form includes a listbox which is populated with a
list of dates. When the user selects a date, the InteractiveChange method of
the listbox makes the SEEK call (shown below) to find the corresponding
record in the SESSIONS table. Before the call to the second form, the user
can select any item in the listbox without error. After the return from the
second form, an attempt to select a different item in the listbox causes the
error.

The ReassignPicture form edits a second table, WoundImages. It currently
modifies one field in one record in that table. That field is the value of
the SessionID for that WoundImage record. No records are added to either the
WoundImages or Sessions tables. No changes are made to the Sessions table.

SessionID is the primary index of the Sessions table, and also a regular
index in the WoundImages table. There are no relations between the two
tables in the data environments of either of the two forms.

The ReassignPicture form uses a Default data session so that it is working
with the same tables as the VISITS form. It executes a TableUpdate(0, .T.,
'WoundImages') call before returning to VISITS.

When the error occurs I can click ignore, and then close the VISITS form.
When I reopen it, it behaves normally until I make the call to the second
form.

I hope this clarification helps.

Thanks for your help.

Jim

"Cindy Winegarden" <cindy.wi...@mvps.org> wrote in message
news:efDF0IHa...@TK2MSFTNGP11.phx.gbl...

[Jim Walsh]

Lee,

Thanks for your response to my posting.

1. IndexSeek() produces the same error as does the Seek call.

2. I don't see how the server/workstation case applies here.

3. I suspected corrupted index. So have deleted it and recreated it 2 or 3
times. That didn't help.

4. The article about not reusing a primary key seems like it might relate,
but I don't see exactly how. I am editing a record, but in another table,
and I am not changing the primary key in that table.

Is there any chance that I could set a breakpoint on an attempt to change
the primary key, SessionID, or create a new record with a duplicate key? Or,
is there someway to visualize the content of the CDX file that contains the
index?

Thanks for your help.

Jim

"Lee Mitchell" <Le...@online.microsoft.com> wrote in message
news:Jt9BbcQa...@cpmsftngxa06.phx.gbl...

[Jim Walsh]

I think I found the source of my problem.

The form that is being called has a Listbox that allows the user to select a
new Session to be assigned to the selected image. I had set the
ControlSource of that listbox to Sessions.SessionID so that it would be
synchronized with the current settings on entry. However, it appears that
when the user selects a new date (i.e. SessionID) from the listbox this is
getting reflected back to the Sessions table index somehow.

I really don't understand that. However, if I change the controlsource for
the listbox in the called form to <None>, the problem goes away.

Could you explain what is happening here?

Thanks,
Jim

"Jim Walsh" <Dr...@newsgroups.nospam> wrote in message
news:%23t3pcmR...@TK2MSFTNGP12.phx.gbl...

[Jack Jackson]

ControlSource is a two-way street.

When you set the listbox's ControlSource to sessions.sessionid, then
the listbox will show the record with a matching sessionid. However,
when you change the listbox to another record the controlsource will
also change - the sessionid field of the currently selected record in
the sessions table will be changed to the sessionid of the newly
selected record in the listbox.

On Tue, 13 Jul 2004 18:04:51 -0400, "Jim Walsh"

[Jim Walsh]

Jack,

Thanks for your follow-up.

I do understand what you said. The mystery to me is why this seems to cause
the index for that table to get mixed up to produce the error described in
my original posting.

Jim

"Jack Jackson" <jackn...@pebbleridge.com> wrote in message
news:dsj9f0tu59u9io7td...@4ax.com...

[Lee Mitchell]

Hi Christian_yt:

>Is there any chance that I could set a breakpoint on an attempt to change
the primary key,
>SessionID, or create a new record with a duplicate key?

There is a DataSessionID property. Can you watch this in the Debug window?

>Or, is there someway to visualize the content of the CDX file that
contains the
>index?

Have you looked at the CDX(), TAG(), SYS(14) functions?

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003

>Lee,

[Jack Jackson]

If session.sessionid is changed by the listbox to a value that already
exists in some other record in the table, then when you move the
session table record pointer (by executing a SEEK) VFP will commit the
change (assuming you are using record buffering) and at that time will
notice that there is a duplicate primary key entry.

On Wed, 14 Jul 2004 10:55:52 -0400, "Jim Walsh"

[Jim Walsh]

Jack,

I see now.
Thanks,
Jim

"Jack Jackson" <jackn...@pebbleridge.com> wrote in message

news:a8uaf0lrcvju780mf...@4ax.com...

[Jim Walsh]

Lee,

Thanks for your continuing follow-up.

I discovered that I could set a breakpoint on any changes to
Sessions.SessionID. That helped me to identify the culprit.

But, I'll keep those functions in mind for future debugging.

Jim

"Lee Mitchell" <Le...@online.microsoft.com> wrote in message

news:MJNqqzca...@cpmsftngxa06.phx.gbl...

[Lee Mitchell]

Hi Jim:

Yes. I am glad you found the cause. I read the post about the listbox.

I am glad the newsgroup was helpful. As long as we are offering useful
ideas and helping other make progress, I think we serve our purpose well.