Well this one has me stumped. I have a program that has been in use for 8 years. Last week we started having a strange problem with retrieving record ids vis a cross ref index.

I have a field called X.LIST which is cross ref indexed. Data in this field is like the following:

WS=ST=1000

WS=ST=1100

BL=CHE=949

BL=GC=11000

etc.

The first 2 letters is a class code then=then types of classes depending on what the first 2 chara are then=then a date in internal format.

Several routines includeing some custom reports use indexes to get results back. Now the funny part: apparently we are only having problems with the WS class code and the only possible choices are: WS=V=…

   WS=ST=...

   WS=WIP=...

   WS=CLS=...

using the following syntax at tcl

select worder with x.list.xref "WS=WIP]" returns the correct number of records (we are using the shorthand of the ] for the phrase "starting" .

and select worder with x.list.xref "WS=CLS]" also returns the correct number

In fact using "WS=W]" & "WS=WI]" & "WS=WIP]" all returnthe same correct number of values.

BUT using any variation of "WS=ST]" "WS=S]" or "WS=V]" returns the

NO RECORDS FOUND. But if we modify the select to read

"WS=S" or "WS=ST" OR "WS=V" (IE change it via on both sides to read CONTAINING) we get the correct number of hits.

This would indicate that for records with a WS=ST or WS=V in that field something extra is being added to the front before it is indexed. But as far as i can tell it is not.

Now as i said everythng was working fine until last fthursday. I have rebuilt the index and it made no difference. I an change all of my code peices to use the form - but i would rather not have to do that.

By the way, my test system works correctly like the production one did until last week. Also 2 other sites are using the same program w/o problems.

Any suggestions?

AREV ver 2.11 on an NT server using NT1.5 the Xref parameters ar to use a SPACE FM,VM,SVM,TM for delimeters (orginally it was just a SPACE but i thought i would try and eliminate a stray character being on the front of the data)

thanks

Ed,

Seems to me that you are taking elements of the index in lieu of the

whole index.

The second part of your field is where the difficulty seems to be.

The ] symbol requests items "starting in" the "S" value but your

index is of the whole value "ST".

When you are using the symbol it looks for items "containing" the

value given.

We have experienced this and have opted for the method which

guarantees a hit in lieu of the ] or methods which are subjective.

This seems to be an issue with cross ref indices but not Btree so that

may be an alternative for you to consider.

Kind Regards,

Kevin Gray

Graycorp

(email [email protected])

Ed,

You indicate the delimeters for cross ref indices but none of the

values that you have indicated are the same as your delimeter

actually used by you!

You use an "= sign as your delimeter so need to include that in

your range of cross ref delimeters in order for your method to work

as you intend.

When you use the ] symbol it will never find the "S" value as none

of your indicated strings actually start in "S"

Curious to know the actual results that you have previously been

achieving as it would seem that they must have been in error unless

in your re-indexing you forgot to include the "= sign as a valid

delimiter.

Regards,

Kevin

I would avoid the use of delimiters (space, tm, @svm, @vm,@fm, @rm ) in any keys. Further, an equals sign may cause certain evaluations to occur on data where you don't want that to happen.

So use $ or ; or something else instead of=.

Some critical event must have happened last week for the problem to arise at that time. Any ideas?

Steve

actually the equal sign is no the real delimter for indexing purposes

it is use for another purpose. The x.list actaully composed of many of the these strings with spaces between each of thse strings so the SPACE is a the real delimter for indexing purposes. I decide to add the @FM@VM@TM values tothe delimiter field inthe index window just to avoif the possiblity of one of those values being included.

However, I did some more testing. Our code actually calls btree extract and we don't actually use the Select statement. On our test system our routines and the TCL select give the same correct results.

on the production system Before i rebuilt the index, our routines and the Select statement gave the same results - no hits!

But now after the rebuild our routines are again returninght e correct results (still using the single ]) but the select satement is not!

really really weird! I did check our code and it uses the single ] form.

At least it is working - but this is unsettling!

View this thread on the forum...