SEEK'ng a String prefixed with a space 1

[David Higgs]

I have a Table that has a field that contains two characters which identify an area code. The area code can be 1 or 2 characters wide. If the area code is a single character a space is prefixed to the search string. This is necessary because the two characters are used to form a 4 character code in another table where the format is Character,Character,Number, Number i.e "SP83" OR " H93".

search_area =" H"
SEEK search_area

The above code finds the first instance of the Area Code that contains "H" and not " H".

Any help in resolving this issue would be much appreciated.

Regards,
David

 

[Olaf Doschke]

Please double check that, double chek what index is set and maybe change to using the SEEK() function to have no side effect of any changing current order.
Seeking a space works as any other character, there's nothing special to it. Your observation could lead to thinking about some automatic trimming, but that doesn't happen, even not in varchar fields.

Simple example:

CREATE CURSOR crsTest (cCode C(2))
INDEX on cCode TAG cCode

INSERT INTO crsTest VALUES ("HA")
INSERT INTO crsTest VALUES (" H")
INSERT INTO crsTest VALUES ("ZZ")
? ">>"+cCode+"<<", RECNO()
SEEK " H"
? ">>"+cCode+"<<", RECNO()

You're making any false step or assumption. Do you have anything else in place also influencing the active record like a filter or a relation?

Bye, Olaf

PS: Is it perhaps variable name identical to field name? If you SEEK var, but var also is a field name, you seek the field value, not the variable value. You could try SEEK m.search_area, then. I assume though, your field is area.

 

[David Higgs]

Hello Olaf,

Thank for you reply.

I must admit my thoughts were beginning to suspect the “Space” was being stripped by the SEEK Command. However, I looked at another routine in my 4-character Code searching for 3 characters (space + 3 chrs) which worked.

I tried your example and of course it worked ok. So I wrote a small PRG file to open the database and select the appropriate Index File then search for “ H” and it found it ok. So it looks like there is a problem with my code. I will take a look to see if there is a possibility of a problem with a variable name and see where we go from there.

Thanks again for your input, it encourages me to look further with my code


Regards,
David

 

[Olaf Doschke]

Add a breakpoint and debug the situation, look at current workarea ALIAS(), current filter SET('FILTER'), current index setting SET('ORDER'). Open the datasession and look out on the right side, if any relations are displayed in there.
You can make all of these expressions permanently watched, so they display in the watch window whenever you debug. Also your locals window will show you variables currently in scope and hovering over search_area it's value will display as tiptext, if you wait for it, and this might then not be H with a space prefix, but whatever a currently accessible field named search_area contains.

If you have a IDX index, this can get out of sync with data, rather only use CDX indexes today, with multiple TAGs in one main CDX file, that's always and automatically updated with DBF, no matter if you SET INDEX or not. You don't SET INDEX, you SET ORDER TAG tagname, then, to make use of an index tag. Also look at SEEK() function, it enables you to use an index tag without a browse or grid sorting by that index tag, or better yet, you may sort one way for display and still SEEK by any other index, too.

Bye, Olaf.

 

[David Higgs]

Hello Olaf,

I always forget to make use of the "DEBUG" facility, however it came to my help today. I use a pop-up form to Input the "Two Digit" Code; "Debug" showed that the Input was as expected which prompted me to look at the "calling" form. I found some code that was stripping the prefixed space from the "Two Digit" Code.

All is now working as expected.

Thanks again for your help.

Regards,
David