CASE expression problem

[buddyrich2]

I'm going crazy trying to figure out why this (seemingly simple) CASE expression will not work. Since the typevar does not equal "All", this statement should catch it but it is not. What am I doing wrong?

Here is the code:

m.countyvar="Johnson"
m.typevar="Anytype"

DO CASE
CASE ALLTRIM(m.countyvar)=="All"

	DO CASE
	CASE ALLTRIM(typevar)=="All"
			
		DO CASE
		CASE ALLTRIM(pricevar)=="All"
		
			DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * from ...
		
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
			
		
		CASE ALLTRIM(pricevar)<>"All"
		
		    DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * from ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
				
		ENDCASE
		
		
	CASE ALLTRIM(typevar)<>"All"
	
	    DO CASE
		CASE ALLTRIM(pricevar)=="All"
		
		        DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * from ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
		
				
		 CASE ALLTRIM(pricevar)<>"All"
		
		        DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * from ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
					
	     ENDCASE
	    
	 ENDCASE
	
CASE ALLTRIM(m.countyvar)<>"All"


    DO CASE
	CASE ALLTRIM(m.typevar)=="All"
			
		DO CASE
		CASE ALLTRIM(pricevar)=="All"
		
		        DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
                        ENDCASE
			
		CASE ALLTRIM(pricevar)<>"All"
		
		        DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * from ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
		
		ENDCASE
		
	CASE ALLTRIM(m.typevar)<>"All"
	
	    DO CASE
		CASE ALLTRIM(m.pricevar)=="All"
		
		    DO CASE
			CASE ALLTRIM(m.sizevar)=="All"
			
			SELECT * ....
			
			CASE ALLTRIM(sizevar)<>"All"
			.
			SELECT * ....
			ENDCASE
		
		CASE ALLTRIM(pricevar)<>"All"
		
		        DO CASE
			CASE ALLTRIM(sizevar)=="All"
			SELECT * ....
			
			CASE ALLTRIM(sizevar)<>"All"
			SELECT * from ....
			ENDCASE
		
		ENDCASE
		
	     ENDCASE
	
ENDCASE

ENDCASE
RETURN

Thanks in advance.

 

[GriffMG]

Off the top of my head:

Firstly, you seem to have one too many endcase statements, although VFP doesn't complain.

Secondly, whilst your sample initialises two variables and uses a prefix on them (m.) the balance (sizevar and pricevar) are neither initialised or prefixed - so VFP may either be unable to 'see' them or it may be taking a visible reference from a table.

Lastly, although typevar is prefixed with an m. at initialisation, it is subsequently used without the prefix - so again VFP may either be unable to 'see' it or may be taking a visible reference from a table.

I suppose there could be be a conflict with the case of the values - although not as initialised - too, but my guess would be the lack of consistent prefixing.

Good luck



Regards

Griff
Keep [Smile]ing

 

[Mike Lewis]

Buddyrich,

I'd suggest you start by simplifying the whole thing. There are several instances where you've got two mutually exclusive options within a pair of CASEs. It would be better to replace these with a simple IF / ELSE / ENDIF.

For example, instead of this:

DO CASE
  CASE ALLTRIM(sizevar)=="All"
     SELECT * from ...
   CASE ALLTRIM(sizevar)<>"All"
      SELECT * from ....
ENDCASE

you could do this:

IF ALLTRIM(sizevar)=="All"
  SELECT * from ...
ELSE 
  SELECT * from ....
ENDIF

Having done that, you should then make sure the indentation is correct (an easy way to do that is to use Beautify). That will make it easy to see any structural errors. (As Griff says, it looks like you've got a mismatch in the CASEs and ENDCASEs.)

Give that a try and see what happnes.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[fitedgar]

Change all variables as m.countyvar to lc_countyvar
m.typevar to lc_typevar ( do not use m. )

Reference table fields as tablealias->field1
tablealias->field2 etc

I think VFP can't tell ( in your program) if it's a variable or a field name
This way it is more clear to read and follow.

Edgar
IBS

 

[dbMark]

As the others inferred above, if you have a table field name and a memory variable name which are identical, unless you use an identifying prefix such as M. or tableAlias. then it will always default to the table field.

 

[Mike Lewis]

Although I agree with dbMark and Mike Yearwood about the use of m., I was taught that it's bad practice to use it on the left of an equals sign, for example:

m.countyvar="Johnson"

That's because the item in question can't be anything except a variable in that context. It's the same with things like DO FORM ... TO <memvar> and TEXT TO <memvar>.

Then again, I suppose it does no harm.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

No real harm in using m. on the left side of an assignment. Last I knew, it was very slightly slower, but probably not enough to matter except in real-time processing.

Tamar

 

[pthalacker]

Mike,

There is one reason to use m. to the left of an equal sign, if you use Christof Wollenhaupt's intellisense (isx.prg)

pamela

 

[GriffMG]

I have done a little testing.

It makes no measurable difference whether or not you use the prefix of m. - I think the compilation process sorts that out.

If you use the LC stuff then you are going to slow things down a little - but not measurably.

If you develop code according to "Christof Wollenhaupt's intellisense", intensive testing suggests that it will be very difficult to gain an advantage over using the "Paul Merton Nonsense" methodology.

If, however, you use field names that match variable names and do not even try to avoid a conflict, you are stuffed - no one will be able to work out where the fault is - without the full source and the full data.

TQM




Regards

Griff
Keep [Smile]ing

 

[buddyrich2]

I did all the things you guys (and gals) suggested and it works now.

My thanks to all - it is greatly appreciated.