Trim a count??

[realm174]

Howdy friends and neighbors!

Here's my problem... which I sorta fixed for now, but I'm curious to know if anyone knows anything about this...

I have a dfb that has multiple records of all types. One of the field is called

calltype

which is of C(5).

At one point, I need to know how many of those 14000 records contain something specific (for example, "01.A0&quot

So I had

store space(5) to m.searchstring
@10,10 say "Enter the search string: " get m.searchstring picture "@!"
count all for calltype=m.searchstring to m.nbfound

It always returned 0. Yet, I knew some records matched the search string... so I started playing around a little... and what I found was that I had to

alltrim

my field.

ltrim

or

rtrim

were not sufficient, it had to be

alltrim

.

Any idea why?? Am I not comparing a C(5) memory variable to a C(5) field?? Should it not match without the

alltrim

?



Cheers,

Realm174

 

[rob444]

Your example missed a read statement..
If you use calltype=m.searchstring you do not have to get an exact match.
= only looks for an occurance of m.searchstring in calltype.
If you use calltype==m.searchstring you will get an exact match and count.

If m.searchstring is less than 5 characters you'll have to (all)trim m.searchstring unless you want to look for spaces at the unfilled positions.

Rob.

 

[AnanthaP]

What happens if the user entered less than 5 characters? How would the compare behave? Would it count all like a * - say.

I think there's a SET command (SET EXACT ?) that controls this. Secondly, it might be the m. prefix. In the FP examples m. is always used for SCATTERED variables. Is the CR the user enters (presumably) changing the string? Can you try without the m. like so:

store space(5) to MySearh
@10,10 say "Enter the search string: " get MySearch picture "@!"
count all for calltype=MySearch to MyFound

Don't have access to FoxPro right now so please post the result.

End

 

[realm174]

Rob: You're correct, my example here was missing the read statement, but yes, I do have that in the program. I will try with the == and see if that works.. but regardless, but strings being of equal sizes, I though it would find them regardless...

AnanthaP: The validation process prevents less than 5 characters. So what's entered in the search string will always be 5 characters exactly, and the field is always filled with 5 characters as well, excluding spaces.

I'm at work now, so I'll experiment a little more and see where that takes me.

thanks for the responses guys!



Cheers,

Realm174

 

[dbMark]

AnathaP:
In FoxPro the general format using a dot or period is table_alias.table_field. The tables opened in the first 10 work areas can also use that pattern by using the shorthand single characters specifically reserved for those 10 work areas (a.{field} to j.{field}). There is a special provision for memory variables wherein you can specifically refer only to a memory variable by referring to it as m.{variablename} and this is needed in cases where you may be in a work area and the table has a field name identical to the memory variable name. Therefore ANY memory variable can use the "m." method.

Of course, the above description is totally separate from filename construction in which Windows allows filenames such as "my.data.today.am.dbf". That's a non-issue in FP and FPW since they require adherence to the 8.3 DOS filename conventions. When using such a table in VFP , the default alias has underscores rather than periods and is often shortened to eight characters or less.