>>Hi all,
>>
>>I did a quick search of the archive but could not find a definitive answer.
>>
>>Can CASE statements be nested in VFP6?
>>
>>I have some IFs in a CASE that are not doing what I want and I thought a CASE inside a CASE would give me the control that I need.
>
>Yes. You can nest case statements. What is it that you're expecting to happen that doesn't? Have you stepped through the code in the debugger and checked the value of the variables?

There are some IFs that deal with actions based on user security level. The actions do not seem to be terminating when they should and there is some bleed into an action after the IF..ENDIF where a lower level user should not even be executing a particular function. It is some legacy code that I am trying not to get too involved with because I need to concentrate on the next generation app.

It is an @SAY..@GET prg based ui using VFP6 runtime. A series of CASE statements layout what will happen when various buttons are clicked. All buttons have a VALID btn_val('somestring')

PROCEDURE btn_val
   PARAMETER m.btnname
     CASE m.btnname = 'somestring'
         do some things
     CASE m.btnname = 'someotherstring'
         do some thing different
*** and so on for 20 buttons or so
     ENDCASE

In one CASE the the user is marking the order complete so that the billing clerk can audit the order and send it to accounting.

CASE  m.btnname = 'W_FINAL'
		SELECT CDM30WRK
		IF cmp_custid = 0
			SELECT CDM10CMP
			LOCATE FOR cmp_code = mCMP_CODE
			IF cmp_custid <> 0
				STORE cmp_custid TO lnCustID
				SELECT CDM30WRK
				LOCATE FOR wrk_order = mWRK_ORDER
				REPLACE NEXT 1 cmp_custid WITH lnCustID
			ENDIF
		SELECT CDM30WRK
		ENDIF
		IF SUBSTR(WRK_STAT,1,1) = "9"
*** Audit this work order. If it is status complete,
*** change to Accounting or COD
			DO CD300AUD
			IF sw_035 = "Y"
				@ 0.385,78.833 GET WRK_STAT PICTURE "@^" FROM ar_wstat;
					SIZE 1.538,11.333 ;
					DEFAULT "1-SCHED" ;
					FONT "MS Sans Serif", 8 ;
					STYLE "B" ;
					COLOR ,,,,,,,,RGB(255,255,255,128,128,0),RGB(255,255,255,128,128,0)
				DO CD017WAI
				sw_300 = "C"
				m.bailout = .T.	&&this is needed if used with FoxApp
				CLEAR READ
				RETURN
			ENDIF
		ELSE
*** if this is a normal user change the status to complete after popup
*** change the status without a popup if user level is greater than 5
			IF xUSR_LEVEL < "5"
				DO CD300FNL
			ELSE
				REPLACE NEXT 1 WRK_STAT WITH "9-COMPLT"
				REPLACE NEXT 1 pers_updt WITH xUSR_CODE
			ENDIF
		ENDIF
		mWRK_ORDER = WRK_ORDER
		SEEK mWRK_ORDER
		mWRK_PAGE = WRK_PAGE
		mITM_LINE = 1
		DO save_old
*** make sure we have a custid
		IF cmp_custid = 0
			SELECT CDM10CMP
			LOCATE FOR cmp_code = mCMP_CODE
			IF cmp_custid = 0
				DO client_export_to_mdb && exports to Access
			ENDIF
			STORE cmp_custid TO lnCustID
			SELECT CDM30WRK
			LOCATE FOR wrk_order = mWRK_ORDER
			REPLACE NEXT 1 cmp_custid WITH lnCustID
		ENDIF
*** send the work order information to accounting.
		IF SUBSTR(WRK_STAT, 1, 1) = "A" OR SUBSTR(WRK_STAT, 1, 1) = "C"
			DO export_workorder_to_mdb && exports to Access
		ENDIF
		KEYBOARD "{ALT+1}" PLAIN

So what is happening is that the routine is trying to export a client while the lower level user is executing the program. They do not have rights on that directory. They get a logon box from Access ODBC which fails, a wait window regarding a variable not found (since the export routine fails) that they can click though and the routine completes successfully.

I would have thought that the ENDIF would terminate the lower level users participation in the code. But it does not. I figured I could better compartmentalize the security with a CASE rather than an IF. I've had the block that does the client export in various places within this CASE without the desired result, and most always the unsecured user try to make the export. Maybe if I didn't get interuppted quite so often :)