Data Template Guide Version 2.0(2)

RSBY EDVASP User’s Guide

Minimum System Requirements:

1. Pentium 4 processor or equivalent processor

2. 1 GB RAM

3. 200 MB free space in C drive

4. Windows XP (The software is not compatible with Windows Vista)

5. Office XP 2003 or higher

6. .Net Framework 2.0 or higher (Please download using this link:

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-

4B0D-8EDD-AAB15C5E04F5&displaylang=en )

7. J# framework 2.0 or higher (Please download using this link:

http://www.microsoft.com/downloads/details.aspx?familyid=f72c74b3-ed0e-4af8-

ae63-2f0e42501be1&displaylang=en )

1. Introduction to RSBY EDVASP

RSBY EDVASP checks many things and can be broadly divided into 3 categories. Checks that ensure that

the data are in correct template—unless the data are in correct template, you will not be allowed by

the program to proceed for data verification. The second set of checks that RSBY EDVASP conducts is

checks on the internal consistency of the data. No data can be completely internally consistent, so the

program will allow you to submit these data and will identify “problem data” in a separate file. The third

set of checks is external consistency checks that verify whether the village codes in the database match

the census village codes. Village codes that do not match the census are stored in a separate file. Once

your template is determined to be correct, you are allowed by the program to submit the data for GOI

clearance at any time. For your convenience, all the checks are detailed below.

A. Table Structure checks: This is a template check.

B. Table’s Column available checks: This is a template check.

C. Table’s Column Data Type checks: This is a template check.

D. Table’s relationship checks: This is a template check.

E. Check for Content within specified column in Tables

F. Unsuitable Data Checks: This is an internally consistency check.

G. Check for State and District Codes against Census codes: This is an external consistency

check.

The following lists all checks RSBY EDVASP performs:

A. Table Structure checks:

1. Check whether the database has any other table apart from the following tables:

I. MstBlock

II. MstDistrict

III. MstPanchayatTown

IV. MstState

V. MstVillage

VI. MstRelation

VII. TxnDependents

VIII. TxnEnrollment

In case the structure is not in the correct format (any additional/ less than required tables are

found), RSBY EDVASP will not permit submission. Please note that all table names are case

sensitive.

B. Table’s Column available checks:

1. Check whether MstState table have the following columns:

I. SerialNo

II. StateCode

III. StateName

2. Check whether MstDistrict table have the following columns:

I. SerialNo

II. StateCode

III. DistrictCode

IV. DistrictName

3. Check whether MstVillage table have the following columns:

I. StateCode

II. DistrictCode

III. BlockCode

IV. Panchayat_TownCode

V. VillageCode

VI. VillageName

VII. Status

4. Check whether MstBlock table have the following columns:

I. SerialNo

II. StateCode

III. DistrictCode

IV. BlockCode

V. BlockName

VI. Status

5. Check whether MstPanchayatTown table have the following columns:

I. StateCode

II. DistrictCode

III. BlockCode

IV. Panchayat_TownCode

V. Panchayat_TownName

VI. Status

6. Check whether MstRelation table have the following columns:

I. SerialNo

II. RelationCode

III. RelationDescription

7. Check whether TxnEnrollment table have the following columns:

I. FamilyID

II. EName

III. VernacularName

IV. Father_HusbandName

V. Door_HouseNo

VI. VillageCode

VII. Panchayat_TownCode

VIII. BlockCode

IX. DistrictCode

X. StateCode

XI. BPLCitizen

XII. Status

8. Check whether TxnDependents table have the following columns:

I. FamilyID

II. MemberID

III. MemberName

IV. Gender

V. Age

VI. RelationCode

VII. Status

In case the column structure not in the correct format (any additional/ less than required

columns are found), RSBY EDVASP will not permit submission. Please note, all column names are

case sensitive.

C. Table’s Column Data Type checks (Data Types specified in brackets):

1. Check whether MstState table have the following Data Type:

I. SerialNo (AutoNumber)

II. StateCode (Number)

III. StateName (Text)

2. Check whether MstDistrict table have the following Data Type:

I. SerialNo (AutoNumber)

II. StateCode (Text)

III. DistrictCode (Text)

IV. DistrictName (Text)

3. Check whether MstVillage table have the following Data Type:

I. StateCode (Text)

II. DistrictCode (Text)

III. BlockCode (Text)

IV. Panchayat_TownCode (Text)

V. VillageCode (Text)

VI. VillageName (Text)

VII. Status (Yes/No)

4. Check whether MstBlock table have the following Data Type:

I. SerialNo (AutoNumber)

II. StateCode (Text)

III. DistrictCode (Text)

IV. BlockCode (Text)

V. BlockName (Text)

VI. Status (Yes/No)

5. Check whether MstPanchayatTown table have the following Data Type:

I. StateCode (Text)

II. DistrictCode (Text)

III. BlockCode (Text)

IV. Panchayat_TownCode (Text)

V. Panchayat_TownName (Text)

VI. Status (Yes/ No)

6. Check whether MstRelation table have the following Data Type:

I. SerialNo (AutoNumber)

II. RelationCode (Number)

III. RelationDescription (Text)

7. Check whether TxnEnrollment table have the following Data Type:

I. FamilyID ( Number)

II. EName (Text)

III. VernacularName (Text)

IV. Father_HusbandName (Text)

V. Door_HouseNo (Text)

VI. VillageCode (Text)

VII. Panchayat_TownCode (Text)

VIII. BlockCode (Text)

IX. DistrictCode (Text)

X. StateCode (Text)

XI. BPLCitizen (Text)

XII. Status (Yes/No)

8. Check whether TxnDependents table have the following Data Type:

I. FamilyID ( Number)

II. MemberID (Number)

III. MemberName (Text)

IV. Gender (Number)

V. Age (Number)

VI. RelationCode (Number)

VII. Status (Yes/No)

In case the column Data Type is not in the correct format, RSBY EDVASP will not permit

submission.

D. Table’s relationship checks (PK = Primary Key):

Note: All relationships are composite and hence more than one Primary Key is present in many

tables. Please be careful in implementing the indexing options in design view of each table else

data might be lost or relationship creation might not be possible.

1. Check whether MstState table have the following relationships:

I. SerialNo

II. StateCode (PK)

III. StateName

2. Check whether MstDistrict table have the following relationships:

I. SerialNo

II. StateCode (PK)

III. DistrictCode (PK)

IV. DistrictName

3. Check whether MstVillage table have the following relationships:

I. StateCode (PK)

II. DistrictCode (PK)

III. BlockCode (PK)

IV. Panchayat_TownCode (PK)

V. VillageCode (PK)

VI. VillageName

VII. Status

4. Check whether MstBlock table have the following relationships:

I. SerialNo

II. StateCode (PK)

III. DistrictCode (PK)

IV. BlockCode (PK)

V. BlockName

VI. Status

5. Check whether MstPanchayatTown table have the following relationships:

I. StateCode (PK)

II. DistrictCode (PK)

III. BlockCode (PK)

IV. Panchayat_TownCode (PK)

V. Panchayat_TownName

VI. Status

6. Check whether MstRelation table have the following relationships:

I. SerialNo

II. RelationCode (PK)

III. RelationDescription

7. Check whether TxnEnrollment table have the following relationships:

I. FamilyID (PK)

II. EName

III. VernacularName

IV. Father_HusbandName

V. Door_HouseNo

VI. VillageCode (PK)

VII. Panchayat_TownCode (PK)

VIII. BlockCode (PK)

IX. DistrictCode (PK)

X. StateCode (PK)

XI. BPLCitizen

XII. Status

8. Check whether TxnDependents table have the following relationships:

I. FamilyID (PK)

II. MemberID (PK)

III. MemberName

IV. Gender

V. Age

VI. RelationCode

VII. Status

In case the Table Relationship is not in the correct format (any additional/ less than required

relationships are found), RSBY EDVASP will not permit submission.

E. Check for Content within specified column in Tables:

1. Check within masters i.e. MstState, MstDistrict, MstBlockCode, MstPanchayatTown,

MstVillage respectively:

I. StateCode (Value >0 and <=2 ; )

II. DistrictCode (Value >0 and <=2 ;)

III. BlockCode (Value >0 and <=7; )

IV. Panchayat_TownCode (Value >0 and <=10; )

V. VillageCode (Value>0 and <=8; )

VI. If more than one entry is present in MstState table

VII. If more than one entry is present in MstDistrict table

In case there is any deviation from the rules mentioned above, RSBY EDVASP will not permit

submission.

Note: The following checks are internal consistency checks. There will always be some errors—if your

data is in the correct template, you can submit to GOI through RSBY EDVASP at any time.

F. Unsuitable Data Checks:

1. On Table TxnEnrollment:

1. FamilyID should not be blank

2. Ename should not be blank

3. VernacularName should not be blank

4. Father_HusbandName should not be blank

5. VillageCode should not be blank

6. DistrictCode should not be blank

7. StateCode should not be blank

8. BPLCitizen should not be blank

9. Status should be blank always

10. BPLCitizen should always be equal to Y

11. FamilyID should be unique

2. On Table TxnDependants:

1. FamilyID should not be blank

2. MemberID should not be blank

3. MemberName should not be blank

4. Age should be greater than zero.

5. Gender should be 1, 2 or 3.

6. RelationshipCode should not be blank

7. Status should be blank always

8. Combination of Family ID, Member ID should be unique

9. No more than 2 duplicate MemberNames should refer to the same FamilyID

10. No duplicate RelationCode=1 for one familyID

11. At least one instance of RelationCode=1 should exist for each FamilyID

12. The MemberID should be ‘1’ for the Member with Relationcode = ’1’ in

TxnDependent

13. The EName in TxnEnrollment for a familyID should be same as MemberName

in TxnDependents where RelationCode = ‘1’ in TxnDependent

Finally, the only external consistency check ensures that the village codes used match the census village

codes. Again, if there are villages that do not match, these records will be identified and saved in a

separate file, but submission will be permitted.

2. Implementing RSBY EDVASP

Requirements to run the software are as follows:

1. Computer processor P4 or above

2. Windows XP

3. MS office 2003 or higher

4. .NET framework 2.0 or higher

5. Visual J# 2.0

Please download RSBY EDVASP software from RSBY website and install it to your computer. After

installation, choose “start” then “All Programs”, you should see “RSBY” entry on the menu.

Before you click it to proceed with the validation, you need to modify one default setting in your .mdb

file. This is a necessary step if we want to check referential integrity of the data across tables.

Step 1: Selecting “System Objects” option.

1. Open the mdb file.

2. Click on “Tools” in the menubar and click on “Options”.

3. In the “Options” dialog box, select “View” tab on the top if not selected.

4. In the “View” tab, inside the “Show” frame, check the “System Objects” check box & click “Apply &

Ok”.

Step 2: Changing default setting.

1. Open the mdb file.

2. Click on “Tools” in the menubar and click on “Security” then select “User & Group Permissions”.

3. In the “User & Group Permissions” dialog box, select “Permissions” tab if not selected.

4. In the “Object Name” list box locate “MSysRelationships” & select it.

5. Then in the “Permissions” frame check “Read Data” check box & click “Apply & OK”.

Step 3: restoring “System Objects” option setting.

1. Open the mdb file.

2. Click on “Tools” in the menubar and click on “Options”.

3. In the “Options” dialog box, select “View” tab on the top if not selected.

4. In the “View” tab, inside the “Show” frame, uncheck the “System Objects” check box & click “Apply

& Ok”.

Note: Please note that the process differs on Office 2007. The process followed should allow the

system table called MSysRelationships to be given read permissions.

You can now close your database and start RSBY EDVASP. You will see the following window:

Please find your .mdb file using “Browse File” and then click “Validate Now”. You will be asked to

confirm that your .mdb file is not being used by another software and the setting for MSysRelationships

is correct. Click “Yes” for both. The verification process follows the above steps :

1. Table structure check

2. Column structure check

3. Data type check

4. Column length check

5. Primary key and relationships check

6. Data Verification

7. Census code consistency

8. Unsuitable data Export

9. Upload of data

10. Prompt for 30 village code verification

After each step, you will be prompted with an information window and please click “OK” to

continue. For example, after the table structure of your .mdb file is checked, you will see the

following information window. Please click “OK” only once.

Before the second last step – check state, district, and village codes matching with census codes – starts,

you will be asked to locate the census code file, which you can download from RSBY website and save it

on your computer.

Locate downloaded census.mdb using “Browse File” button, and then click “Validate Now” to compare

the Census village codes with “VillageCode” in your database. Incase you don’t have the file, please

download the same from your state administrative page on www.rsby.in .You may see the following

window if there is any unmatched case. You can still proceed with the unmatched villages, which will be

saved to C:/DBErrors.txt for your reference. Please note that the message from the most recent run will

be appended at the end of this file along with the exact time and date you run this verification.

Now the software will proceed with the last step on “unsuitable data”. It may take some time, so please

be patient. At the end, you will be prompted a window with validation details similar to the follow one.

“Percentage of clean families” is the most important indicator on how ready your BPL data are. The

higher this percentage, the better shape is your database.

After click “OK”, if the percentage is not 100%, a new Access database will be created at C:\ with a name

by default in the form of “UD_yourdatafilename.mdb” to assist further investigation. It contains one

table called “UnSuitable”, which lists all problematic records that need closer inspection and correction

in your database. The following table lists 20 field names in the new database, each corresponding to a

specific check, and the explanation for the check. For example, when the value of “EnrFIDBlank” equals

to “Y”, it means that “FamilyID” is blank in table “TxnEnrollment”.

S.No UD Checks Explanation

1 EnrFIDBlank FamilyID should not be blank in

TxnEnrollment

2 ENBlank Ename should not be blank in TxnEnrollment

3 VNBlank VernacularName should not be blank in

TxnEnrollment

4 FHNBlank Father_HusbandName should not be blank in

TxnEnrollment

5 VCBlank VillageCode should not be blank in

TxnEnrollment

6 DCBlank DistrictCode should not be blank in

TxnEnrollment

7 SCBlank StateCode should not be blank in

TxnEnrollment

8 BPLCBlank BPLCitizen should not be blank in

TxnEnrollment

9 EnrStatusBlank Status should be blank always in

TxnEnrollment

10 BPLCAlwaysY BPLCitizen should always be equal to Y in

TxnEnrollment

11 EnrFIDUnique FamilyID should be unique in TxnEnrollment

12 DpnFIDBlank FamilyID should not be blank in

TxnDependent

13 MIDBlank MemberID should not be blank in

TxnDependent

14 MNBlank MemberName should not be blank in

TxnDependent

15 RCodeBlank RelationshipCode should not be blank in

TxnDependent

16 DpnStatusBlank Status should be blank always in

TxnDependent

17 AgeUD Age should not be zero or less than zero in

TxnDependent

18 GenderUD Gender should be 1, 2 or 3 always

19 FMIDUnique Combination of Family ID, Member ID should

be unique in TxnDependent

20 FMNameRepeating

No more than 2 duplicate MemberNames

should refer to the same FamilyID in

TxnDependent

21 FRelationCodeRepeating

Atleast one instance of RelationCode=1

should exist for each FamilyID in

TxnDependent

22 FIDRCode1 No duplicate RelationCode=1 for one familyID

in TxnDependent

23 MIDRcode1 The MemberID should be ‘1’ for the Member

with Relationcode = ’1’ in TxnDependent

24 MNENRCode1

The EName in TxnEnrollment for a familyID

should be same as MemberName in

TxnDependents where RelationCode = ‘1’ in

TxnDependent

One frequently observed unsuitable data is due to the English name of household head in

“TxnEnrollment” is not the same as his/her member name in “TxnDependents” (or “MNENRCode1” field

has value of ”Y” in the “UnSuitable” table). For example, in the following family, “EName” of household

head from “TxnEnrollment” is “RAMSANEHI” while it is “RAMSAHENI” in “TxnDependents”. It is very

likely one of them is a data entry error and need to be corrected.

Another frequently observed unsuitable data is due to missing household head in table

“TxnDependents” (or “FRelationCodeRepeating” filed has value of “Y” in the “UnSuitable” table). In the

following example, its household head is not included in table “TxnDependents” as no record with

“RelationCode” equals to 1. You will need to go back to the original BPL data to find this household

head’s gender and age in order to add him/her to table “TxnDependents”.