Arev 3.12 on Using Novell 4.11

I?m having difficulties in getting a Cross Reference Index to find Items now.

Index delimiters are Space . - , / ( )

I have a Sales Order system with a Customer Purchase Order field CUST_PO

The data in question is:

PRU49322-00

First:

In looking at the CUST_PO_XREF I?m not able to find an Index of 00. but there is an index 0

So here is the first problem.

How can I get the index to index 00 or 000 etc ???

Second:

It seem as though data entered would go thru and input pattern that would look for a index delimiter if present then would convert the delimiter to a space then prefix data with an & (ampersand). I could build an routine that would do this however when the user uses

Ctrl-F10 | Indexed Columns, the routine would not be in use.

In my old Arev 1.16 system I could enter this just as type above and the record would be found.

How do I fix or what work around must I do ?

Bob,

I've tried in vain to replicate your problem. All delimiter options in cross-reference indexing work as they should.

Given that you know the key of the record as well as the CUST_PO, if you do the following, do you come up empty?

SELECT !filename STARTING "CUST_PO_XREF"

SELECT !filename WITH F5 CONTAINING key

If so, remove and recreate the index and try the SELECTs again. Do you still have a problem?

Bill

Well Bill your right :(

Ok I made a new table and set it up as I describe

I now have an index of PRU49322 and 00

Only thing is if I enter the search data as PRU49322-00 then no records found. But if I replace the ?-? with a space then the record is found. Which is kind of silly. The data should be run through the same input pattern (convert delimiters to spaces and trim) as the Index delimiters.

If someone know of a trick or workaround ???

So what this probably means is that it has something to do with how old this table is. What I mean by that is that it was created back when Arev 1.0 or it might even of been a Rev-G to Arev import/update. I can?t remember but somewhere along the way (in later releases) something changed in the tables. The reason why I say this is because some tables (Arev 1.16) I would get the status bar indicator as records where being sorted and other tables the indicator never appeared.

Bob,

Cross-reference indexing creates a btree index of every appropriately delimited element in a column's data. Btree indexing creates an index of the entirety of the data. It looks like your users need access to both, or the equivalent of both, through a single lookup.

I'd recommend creating a symbolic called CUSTOMER_PO as follows:

ORIG_DATA=@RECORD ; * PRU49322-00

NEW_DATA=ORIG_DATA

CONVERT "-" TO " " IN NEW_DATA ; *CONVERT HYPHEN TO SPACE

@ANS=ORIG_DATA : " " : NEW_DATA ; *PRU49322-00 PRU49322 00

Create a cross-reference index on CUSTOMER_PO using only SPACE as a delimiter. Remove the indexing on CUST_PO to remove it from the windows "Browse Options | Indexed Columns" window unless you need to keep it for other reasons.

This - or something equivalent to it - should provide what you're looking for.

Bill

The "00" vs "0" problem in xref's has been with us for a very long time indeed. AREV and OI (I think) see these two as being equal. The only choice is to make them into strings .. this is not very easy. I have used an additional symbolic that appends a 'x' to the "00" to make it a string. On display, I strip out the 'x'.

here is a UDC that does this. If you're willing to modify the dict item xref code, you can do the same thing… SUBROUTINE NumToChar_CONV(TYPE, InVal, Branch, ReturnVal) /* ÷ VERSION : Advanced Revelation 3.1 ÷ PURPOSE : Force numbers to strings ÷ AUTHOR : ÷ CREATED : March 24, 1993 ÷ PROCEDURES : Called as a user defined conversion ÷ WARNINGS : The output conversion does not check the first char. If greater security is desired, check the first character before stripping it off. ÷ THEORY OF OPERATION : On ICONV, stiff a non-numeric character on the front of the string. On OCONV, strip the first character off. This conversion should be used whenever strings that look like numbers need to be treated as strings. For example, if you have codes like: 1 1.0 01.0 They are treated as being equal if they're seen as numbers. This conversion forces the system to treat them as strings, while allowing the user see them in their numeric form. ÷ REVISION HISTORY (Most CURRENT first) : DATE IMPLEMENTOR FUNCTION ——– ———– ——– MM-DD-YY initials Modification */ *÷ EQUATE Variables (Terminate with '$') : EQU TRUE$ TO 1 EQU FALSE$ TO 0 EQU YES$ TO 1 EQU NO$ TO 0 EQU OTHERWISE$ TO 1 EQU NULL$ TO "" EQU SPACE$ TO \20\ *÷ COMMON Variables (Terminate with '%') : *÷ LABELED COMMON Variables (Terminate with '@') : *÷ MESSAGES called (Terminate with '$') : *÷ DECLARED - FUNCTIONS called : *÷ DECLARED - SUBROUTINES called : /* ÷ INDIRECT - FUNCTIONS/SUBROUTINES called if known (Make COMMENTS) : ***/

*÷÷ PROGRAM TOP

IF Type=ICONV" THEN

 ReturnVal=x" : InVal

END ELSE

• ReturnVal=InVal1, LEN(InVal)

 ReturnVal=InVal2, LEN(InVal)

END

RETURN

HTH ..

Don Miller

View this thread on the forum...