PROBLEM: TO ENTER SURVEYS IN BATCHES!!!!

[gbos]

I wish to enter my data in batches. Each Batch has 20 Household Surveys. What is common to each of the batches of survey are: LGA, District, Settlement, Area and EaNum. These variables remain Constant for each Survey of Batches. My problem:
1.) Is to write a logic that will check for values entered for these variables in a lookup table and display error if the values are found in the table or inconsistent. These I have largely succeeded with the following coding:

LGACODE = LGA;
DCODE = DISTRICT;
STCODE = SETTLEMENT;
ACODE = AREA;
EACODE = EANUM;

if not loadcase(GEOCODE_DICT,LGACODE,DCODE,STCODE,ACODE,EACODE) then
errmsg(6, LGA, District, Settlement, Area, EANum);
Select("Change LGA",LGA, "Change District", District,"Change Settlement", Settlement,
"Change Area", Area, "Change EANum", EANUM)
endif;

2. Ensure that for each batch, Only EaNum will be entered and if entered the corresponding values for LGA, District, Settlement and Area be displayed from the lookup table in their respective fields, protected and constant until the 20 households in the batch have been entered.

3. After entering complete information about a household there should be a message to display giving you the option of either continuing with the batch or end it. If the option is to end the batch then , all existing information (LGA,District, Settlement and Area should be automatically cleared making way for new values to be entered.

I am new to CSPRO and I have no idea how to proceed with solutions to these problems. I don’t even know how CSPRO handles this situation. Is there any help from anybody? I have included an attached copy of my survey for your attention.

[josh]

You could try making the id fields up through EA persistent. Persistent items will remain the same between questionnaires.

You would need to reset the id-items from logic if the interviewer tells you that the batch is complete. Instead of doing that at the end of questionnaire I would do it at the beginning of the questionnaire. If you do it at the end then you would clear the ids for the case you just entered. So I would try something like the following in the preproc of the questionnaire (before you get to the first field):

// Clear persistent id-items if this is a new batch
if accept("Start new batch", "yes", "no") = 1 then
LGA = notappl;
DISTRICT = notappl;
SETTLEMENT = notappl;
AREA = notappl;
EANUM = notappl;
endif;

You probably don't want to do this if you are in modify mode since at that point the id-items should not be changed so you could use the demode() function to only ask if this is a new batch if you are in add mode.

To automaticly fill in the LGA, DISTRICT, SETTLEMENT and AREA based on the EANUM you would use loadcase in a similar way to what you are doing now except that in your external dictionary you would make EACODE the single id-item and you would put the other variables (LGACODE, DCODE, STCODE, ACODE) as regular variables on the record. Then when you call loadcase you would use EACODE as the lookup and if successfull then DCODE, STCODE and ACODE will be filled in with the appropriate values by loadcase. Your code in EANUM would then look like:

EACODE = EANUM;

if not loadcase(GEOCODE_DICT,EACODE) then
errmsg("Invalid EA code %d", EANUM);
select( "Change EANum", EANUM)
endif;

// Copy from lookup file to fields on form
LGA = LGACODE;
DISTRICT = DCODE;
SETTLEMENT = STCODE;
AREA = ACODE;

If you do that then you would only make EANUM be persistent and you would make the fields LGA, DISTRICT, SETTLEMENT and AREA protected. You would also need to change the order on the form so that EANUM comes before LGA, DISTRICT, SETTLEMENT and AREA so their values get filled in before the interviewer gets to them.

[gbos]

Thanks Josh, once again for your invaluable suggestion. I found it handy and the problem is almost solved. However, there still remain some issues which I will need you to clarify:

Having implemented the suggestions, now I can get variables, lga, district, settlement , Area automatically filled by entering an eanum. However, select function could not compile initially because EANUM is persistent. I will want a walk around this.
EACODE = EANUM;
if not loadcase(GEOCODE_DICT,EACODE) then
errmsg("Invalid EA code %d", EANUM)
//select( "Change EANum",EANUM);
endif;
// Copy from lookup file to fields on form
LGA = LGACODE;
DISTRICT = DCODE;
SETTLEMENT = STCODE;
AREA = ACODE;
Secondly, after completing a questionnaire just as test, if you, don’t want to start a new batch, the program works perfectly. However, if you test, for a new batch to start, in add mode, it complains that eanum is out of range and doesn’t go any further except crash.
Am not sure if I put the program codes in its right place?? I put the following codes in the preproc of the IHS1_quest. I also try it in the preproc of the Household_Identification. Both yielded the same result after the test. Find below the codes and the attached survey. Any work around??

preproc

// Clear persistent id-items if this is a new batch


if Demode()=add then
if accept("Start new batch", "yes", "no") = 1 then

EANUM = notappl;
LGA = notappl;
DISTRICT = notappl;
SETTLEMENT = notappl;
AREA = notappl;

endif;
ENDIF;

[josh]

My apologies. I haven't worked with persistent ids much and I assumed that if you cleared them by setting them to notappl in logic that CSPro would let you enter them again but apparently it does not work that way. This is why you are getting the out of range error and also why you can't use select.

CSPro expects the user to manually reset the id items using F7 and I don't a way to reset them from logic.

My workaround would be to add another field to the form that is not persistent to capture the EA code for new batches. When the user wants to start a new batch they fill in this field, you validate it in logic using loadcase and if it is valid you copy into the persistent EANUM field. If the user isn't starting a new batch then you would just skip this new EA field. You could call the variable NEW_BATCH_EANUM. Add it to the dictionary, put it on the form and drag it up in the form tree so that it comes before the persistent EANUM field. Then in the preproc you ask the user if they want to start a new batch. If they don't want to start a new batch then you skip the NEW_BATCH_EANUM field which will send the user to the persistent EANUM field that will still contain the code for the previous household and the survey will continue with that old EA code. If the user chooses to start a new batch then you don't anything in the preproc, allowing the user to enter the new batch code. Then in the postproc, which only gets executed if the user is starting a new batch, you validate the new EA code and if successfull you set the persistent EA code field to be the code the user entered. The logic would like:

PROC NEW_BATCH_EANUM
preproc
// Check if user wants to start a new batch
// Only do this in add mode since id-items should not change
// in modify.
if demode() = 1 then
    if accept("Start new batch", "yes", "no") = 2 then
        // Not starting new batch so skip NEW_BATCH_EANUM and continue with
        // data entry for same batch.
        skip to EANUM;
    endif;
endif;

postproc
// If we get here then we are starting a new batch.

// Verify that new EA code is valid
EACODE = NEW_BATCH_EANUM;
if not loadcase(GEOCODE_DICT,EACODE) then
    errmsg("Invalid EA code %d", NEW_BATCH_EANUM)
    select( "Change EANum",NEW_BATCH_EANUM);
endif;
// Copy from lookup file to fields on form
EANUM = NEW_BATCH_EANUM;
LGA = LGACODE;
DISTRICT = DCODE;
SETTLEMENT = STCODE;
AREA = ACODE;

Using this approach you wouldn't need any of the logic that you currenty have in the EANUM field or in the IHS1_quest preproc. You would need to make LGA, DISTRICT, SETTLEMENT and AREA persistent so that in the case where they are not starting a new batch you don't need to do the loadcase.

If you are using CSPro 6.2 beta there is a new prompt function that you could use to get the EA code without adding a new field to the form. Prompt puts a dialog box (like accept or errmsg) that prompts the user to enter text and it returns what the user enters. You could get the EA code using prompt and then if the code is valid you could set the persistent EA code field to it. You would then replace the logic in the IHS1_quest preproc with the something like the following:

// Only do this in add mode since id-items should not change
// in modify.
if demode() = 1 then
    if accept("Start new batch", "yes", "no") = 1 then
        // Keep asking for EA code until we get a valid one
        while 1 do
            EACODE = tonumber(prompt("Enter EA", numeric));
            if loadcase(GEOCODE_DICT,EACODE) then
                // Got a valid EA, exit loop
                break;
            else
                // Invalid EA, continue loop and ask for EA again
                errmsg("Invalid EA code %d", EACODE);
            endif;
        enddo;
    endif;
endif;

[gbos]

Thanks Josh once again and this time is a big big thank you. I cannot imagine a solution more than that which you presented. So thanks josh and my hug.

Now, only one thing remained how to display the label for the settlement? This I have been working on with little or no success. I will keep you posted if I will need assistance. But thanks.

[josh]

Glad it is working. What is the issue with displaying the label for the settlement?

[gbos]

Josh, thanks once again. I was trying to display the the label for the settlement code. This, I managed to solve after closely looking at your solution by creating an external dictionary and a loadcase. so far so good.

Now, a new question, is it possible to make a sequential id to start numbering sequentially from any number, say 20. other than the default 1 when you set it equal to curroc().? If so, how?

eg
idnum =curocc(); but I idnum which is sequential to start numbering sequentially from 20 instead of 1?

[josh]

For that I wouldn't make the field sequential. I would just make it a regular field and use idnum=currocc() + 20 in the preproc.

[gbos]

Thanks once again. I tried something exactly like this. Having, tested it is working fine. All credit goes to you. Thanks for the timely support.