Ted I finally tracked it down - it was a control on the form that had its ControlSource set to a field in ztax. Setting the ControlSource to None resolved the problem. Thanks again
Paul -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ted Roche Sent: 29 April 2015 15:17 To: profoxt...@leafe.com Subject: Re: Error 1884 - Uniqueness of index ZTAX1 is violated On Wed, Apr 29, 2015 at 3:37 AM, Paul Newton <paul.new...@pegasus.co.uk> wrote: > I am getting an error 1884 and stepping through the code the line of code > that produces it is a call to the SEEK function. This seems very strange > because the data is not being changed ... anybody have any ideas/suggestions? When you SEEK, you move the record pointer. If you're on a table with an uncommitted buffered record and optimistic record buffering, moving the record pointer attempts to save the buffer to disk. If you haven't generate a key value, or duplicated an existing one, you get the Uniqueness error. Is it possible you've got some misbehaving code that's APPENDING a record, and the SEEK is throwing an error as you move off that record. Alternatively, check the existing table for values of ZTAX1 that are already blank or zero. One record is fine, but the second throws the uniqueness error. > Also, in the debugger, if I Set Next Statement on that line immediately after > it has caused the error, then the SEEK works WITHOUT generating an error. Whenever I see Heisenbugs (bugs that behave differently when using the debugger), I have to assume the original error message is likely valid, but the line number and code is likely bogus. Instead of stepping through the code, try using DEBUGOUT to display the values of the current ALIAS(), RECNO() and key values before and after that line of code and see if you can detect a difference. Also, there's a function that shows a string of flags for the state of the record -- I can't recall it at the moment and don't have a VFP handy -- use that to see if you're somehow dirtying the buffer by accident. -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/9a8106afb0ef9b44b69045c4448935a299c03...@nlbawexmbx1.infor.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
