Very strange (AREV Specific)
At 31 MAY 2002 06:19:44PM a newman wrote:
AREV 2.11
NLM 1.5
Have a cross-ref index on a lastname field in one of our main tables. Dedictated indexer. Only cross-ref index keeps corrupting (btree's, relationals always fine). Deletion/Rebuild breaks with FS466 message with workstation(s) talking to NLM. Wrote program to copy all records with only the lastname field to a temporary table. Deletion/rebuild of cross-ref index works fine on temporary table. Same number of records in temp. table and same field (and contents) being indexed in temp. table. Any idea why cross-ref deletion/rebuild doesn't work in main table with workstation(s) talking to NLM?
At 02 JUN 2002 05:22PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Any delimiters in the data or in the keys? Your program may have filtered these out during the record copying to the temp file.
World Leaders in all things RevSoft
At 03 JUN 2002 02:12AM a newman wrote:
No delimiters in the data or in the keys. Index will delete/rebuild on main table if workstation(s) not talking to NLM. Any suggestions?
At 03 JUN 2002 09:44AM Dave Bennett wrote:
Check for a blank key using selecting by @id, then edit.
At 03 JUN 2002 10:41AM Victor Engel wrote:
A xref index is, in fact, a btree index. When you set up a xref index, you create a symbolic field which turns the data of your target field into a multivalued field using the delimiters you specified to mark the values. This symbolic field is then given a btree index.
Rather than simply rebuilding your index, I would suggest trying to remove the index and setting it up again. This will correct a problem that may exist with one of the index control records.
At 03 JUN 2002 10:50AM Victor Engel wrote:
A couple more thoughts:
* Why use xref instead of btree for a last name field?
* Normally FS466 messages are related to some sort of connectivity/bandwidth issue. Since xref indexes typically have more work associated with them than btree indexes have, an FS466 error may just be statistically more likely. This will, of course, depend upon your data, but it's worth considering as another way of looking at your problem.
I suggest also searching the board for other discussion os FS466 messages. There are several scenarios that can cause them, ranging from workstation configuration, to router configuration, and network usage.
At 04 JUN 2002 05:38AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
You can also get to a blank key by using
EDIT FILE ""
[i]Celebrate CeBIT with Sprezz Local![/i]
At 04 JUN 2002 08:24AM Don Miller - C3 Inc. wrote:
That won't work if there's a B-Tree on @ID or if there's a Quickdex on the table. That caused me some head-pounding a while back.
Don M.
At 04 JUN 2002 11:50AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Good point. I've forgotten I was working on a slightly non-standard system.
[i]Celebrate CeBIT with Sprezz Local![/i]