On AREV 3.12, I have an indexing problem. Incorrect results are being returned on all but the simplest requests. This file has been in use for years. Occasionally, some issues so we rebuild. This time, I removed all indexing and cleaned up the data file as well (fixlh). No GFEs reported in the index or data. However, still can't get the right counts to come up, especially with the CTRL-F10 brower window. A simple TCL statement seems to work, but an sselect doesn't. Any ideas?

Ok, more info. I've determined that the indexes are fine if I use the TCL window to do my select. However,if I use the Index Browser in the Window, incorrect results are returned. I created a new test window and got the same incorrect results, so I don't think that's it. I can restore the program from backup if necessary (i'll be missing some data in the data file though).

Laurie,

Indexing problems can have many causes, as you know.  It seems, though, that maybe memory corruption is a possible cause.  Are you running on Win98?  If you recently upgraded any OSes, to Win98 or WinNT or a new version of Novell or the client software, that could be it.  I could be that you have one or more IDs in your data file with delimiters in them, though that would usually cause corruption regardless of whether you were in a window or at TCL.

I'd be glad to help your troubleshoot it, for free.  You're welcome to either call me at: 512-470-6973 or use Cahoots (d/l from www.cahoots.com, install then browse to this website to hook up) or use MS Messenger or Yahoo messenger or AOL messenger or NetMeeting or PC Anywhere.  I also have a program available for free download with source code from my website that validates a files IDs and will fix the file if any ID contains CHAR(240) or above characters in it.

Larry

[email protected]

http://rehabsw.tripod.com (go to the AREV forum)

I had a similar problem about 6 months ago when we upgraded to 3.12.

The cause was that for some reason there was an invalid key record/row in the table/file. it looked like this xxxx²yyyy.

It was impossible to remove because when you tried to access it with the @vm arev thought it was a list separated by @vm.

What we did was to create a "…_new" table and copied the dict…. file over the dict…._new table. We then wrote a routine that selected all the records in the table and wrote the records to the new table and then had that routine pause if a particular field had blank data and show the key and ask if it should be copied to the new table. It would force the user to respond (y)es if the record was to be copied.

The tables would be renamed to _old and the regular tablename.

This way the corruption was not able to be copied to the new table.

Hope this helps.

Dale

View this thread on the forum...