[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Non-existent Record! (AREV Specific) ====
=== At 30 OCT 1998 07:21:05AM Andy Hart wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
We have very peculiar situation on one file in a specific copy of our application. The file is indexed and if you search for a specific record (previously identified through an error message in the app.) the select returns 1 row found but on editing that record you get the message 'keyvalue' is a new record in the file! 



Removing the indexes and reattaching the volume, recreating the indexes and then repeating the seach gives the same result. 



Removing the indexes and searching also gives the same result!



How can a non-existent record appear to be there (or indeed an record appear to be non-existent)?



Any ideas gratefully welcomed!!!



Thanks 



Andy Hart
</QUOTE>
----

=== At 30 OCT 1998 11:11AM Victor Engel wrote:  ===

<QUOTE>Perhaps you have a delimiter in a key somewhere. What happens if you do this?



SELECT file_name BY indexed_field

* Note the record count

* While the previous select list is still active do this:

SELECT file_name WITH SIZE

* Note the record count again (did it match?)

CLEARSELECT

SELECT file_name

* Note the record count again (all three should match, but may not if you have delimiters in keys or if the index is not in sync)

</QUOTE>

----

=== At 30 OCT 1998 11:11AM Matt Sorrell wrote:  ===

<QUOTE>Andy,



I have run across this problem before, and it turned out that one of the key values in my table had a system delimiter (@VM or @SVM) in it.



This really screws up the indexes and selects return very unpredictable results.



If you'd like, I can e-mail you a utility that I've written that cleans up the table, and flushes the indexes.  You'll probably still have to do a complete index rebuild if there is a system delimiter in the key value, but at least it will get the record out of the table.



Also, it has been my experience that the only way to find those records is through code.  Selects from the TCL won't get it.



Matt Sorrell

</QUOTE>

----

=== At 30 OCT 1998 04:23PM Steve Smith wrote:  ===

<QUOTE>From TCL, if you do have a null key, say on the JUNK file,



EVAL OPEN 'JUNK' TO J THEN DELETE J,""



If the problem persists, write a symbolic on DICT.VOC called KEYJUNK with the following formula



ANS=0

FOR C=255 TO 247

IF INDEX(@ID,CHAR(C),1) THEN ANS=1

NEXT C

@ANS=ANS



then from TCL 



list FILENAME with KEYJUNK=1



any records that have delimiters in the key will show up. DICT of VOC can be used where you want dictionary items to be available on any file, not just VOC.



Steve











</QUOTE>

----

=== At 01 NOV 1998 03:36PM Larry Wilson wrote:  ===

<QUOTE>Victor!  A much faster way than I've been doing it! (the old readnext and checking the ID)  Does it work with all delims GE @STM?

</QUOTE>

----

=== At 02 NOV 1998 08:59AM Victor Engel wrote:  ===

<QUOTE>Actually, I've never given that much thought. My thinking was that if the index was built with an extra leaf because of a delimiter, then the counts would be messed up. OTOH, I can also visualize a situation where such over-counts are balanced out by updates not being properly maintained and dropping off of the index. I can't clearly formulate when this would happen, but perhaps you know what I'm talking about.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=53EEECF5542875E9852566AD003E5AE6|View this thread on the  forum...]]