Press the Esc key to stop the upload. To continue, restart. If process is terminated abnormally,simply restart the Upload Data process. It will pick up where it left off. Jenzabar recommends that you let the system automatically assign ID Numbers.
|
Press the Esc key to stop the upload. To continue, restart. If process is terminated abnormally,simply restart the Upload Data process. It will pick up where it left off. Jenzabar recommends that you let the system automatically assign ID Numbers. |
This menu option attempts to copy data from holding tables (such as IU_NAME, IU_BIOGRAPH, IU_ADDRESS) into live J1 tables (such as NameMaster, BIOGRAPH_MASTER, AddressMaster) using the following steps:
1. A check verifies that all columns marked as REQUIRED in the UPLOAD_CRITERIA table have non-null values. Records are created in an ERROR_LOG for those that have null values.
2. If there are multiple ID Numbers for a specific temporary ID Number, an error will be displayed. This error forces you to resolve multiple matches. Until there is a one-to-one match, the upload cannot proceed. Therefore, you will need to use the Multiple Matches tab to determine the correct person.
3. Once any multiple matches have been resolved, then for all records in the IU_DUPLICATES table, the ID_NUM from IU_DUPLICATES is inserted into all the IU tables for the corresponding Temp ID. For the remaining IU records that do not have ID Numbers, new ID Numbers are generated.
4. One at a time, a Temporary ID is processed:
a. If there is an error row for the temporary ID, it will be skipped.
b. If there is a duplicate row or the temporary ID,
i. If M is found for a table, it will merge (i.e., overwrite) the existing data with the data in the specified IU table that was defined as USED. During the merging process, the status bar will look similar to the following: "Temp ID: 1 ID number: 99 Merging: John Q. Student. (Esc to cancel)."
ii. If M is not found for a table, the table will be skipped.
5. If errors or duplicates are not found, it will be inserted as a new ID Number using the previously generated ID Number and the columns in the IU tables that have been defined as USED. During the inserting process, the status bar will look similar to the following: "Temp ID: 1 ID number: 99 Inserting: John Q. Student. (Esc to cancel)."
a. Any SQL errors that occur during the insert are written into the ERROR_LOG.
b. Additional processing may occur depending upon the data being imported. See below for details.
c. The row(s) are deleted from the IU tables that held the data that was inserted into or updated in for the current Temp ID Number. If data existed in an IU table for a particular Temp ID but none of the columns in the table were marked as USED or the data was not merged with an existing ID Number, the data will remain in the IU table rather than being deleted.
d. The process repeats for the next Temp ID Number.
In addition, as data is imported from the holding tables into the live J1 tables, the following steps take place for each ID Number as it is being processed:
1. If data is imported into the TEST_SCORES and/or CANDIDACY tables but not into the CANDIDATE table for an ID Number, a row is automatically created in the CANDIDATE table for the specified ID Number. Only the USER_NAME, JOB_NAME, and JOB_TIME columns are updated in this case.
2. If the table currently being processed is IU_CANDIDACY, then a check is made to see if a row exists in IU_CANDIDACY for the current Temp ID Number being processed. If not, the process skips to Step 3. If a row for the current Temp ID Number does exist in the table, the following steps are done:
a. The following columns for the ID_NUM are updated from the IU_CANDIDACY table to the CANDIDATE table:
i. IU_CANDIDACY.YR_CDE to CANDIDATE.CUR_TR
ii. IU_CANDIDACY.TRM_CDE to CANDIDATE.CUR_TRM
iii. IU_CANDIDACY.PROG_CDE to CANDIDATE.CUR_PROG
iv. IU_CANDIDACY.DIV_CDE to CANDIDATE.CUR.DIV
v. IU_CANDIDACY.LOCA_CDE to CANDIDATE.CUR_LOC
vi. IU_CANDIDACY.DEPT_CDE to CANDIDATE.CUR_DEPT
vii. IU_CANDIDACY.STAGE to CANDIDATE.CUR_STAGE
viii. STAGE_LVL from STAGE_CONFIG where STAGE = IU_CANDIDACY.STAGE to CANDIDATE.CUR_STAGE_LEVEL
b. The CANDIDACY.CUR_CANDIDACY is set to "Y" for the ID_NUM where the following is true:
i. CANDIDACY.YR_CDE = IU_CANDIDACY.TR_CDE
ii. CANDIDACY.TRM_CDE = IU_CANDIDACY.TRM_CDE
iii. CANDIDACY.PROG_CDE = IU_CANDIDACY.PROG_CDE
iv. CANDIDACY.DIV_CDE = IU_CANDIDACY.DIV_CDE
v. CANDIDACY.LOCA_CDE = IU_CANDIDACY.LOCA_CDE
c. If the IU_CANDIDACY.STAGE column is marked as USED and if it contains a value, then the following will occur:
i. A row is added to the STAGE_HISTORY_TRAN table to track the change in the stage.
ii. The STAGE_CONFIG.ACTION_LST_CDE column is checked for the specified stage. If the ACTION_LST_CDE column is non-null, the specified action list is attached to the candidate's Notepad.
iii. The STAGE_CONFIG.REQ_LST_CDE column is checked for the specified stage. If the REQ_LST_CDE column is non-null, the specified requirement list is attached to the candidate's imported candidacy.
iv. The STAGE_CONFIG.CREATE_JICS_ACCT column for each CANDIDACY.STAGE is checked to determine if any of the candidate's candidacies are in a JICS creation stage.
1) If Y, rows are inserted into the TW_WEB_SECURITY and the TW_GROUP_MEMBERSHIP tables so the API can pass information to JICS to create a JICS account. If the rows already exist in both tables, no rows are added.
2) If N, check to see if the ID Number has any other Candidacy rows where CREATE_JIC_SCCT = 'Y'. If not, then rows are deleted from the TW_GRP_MEMBERSHIP table so the API can pass information to JICS to delete the Candidate role.
3) If X, nothing is done for the Temp ID Number.
3. After all the data has been imported and if CANDIDATE and/or CANDIDACY rows were created during the import, counselor assignment is determined and the CANDIDATE.COUNSELOR_INITIALS for each imported ID Number is updated.
It is required that the columns in the table below be included for each set of data to be imported. If you forget one of these columns, the import will fail.
Table |
Column(s) |
NameMaster |
FIRST_NAME |
|
LAST_NAME |
AddressMaster |
ADDR_CDE |
CANDIDACY |
PROG_CDE |
|
YR_CDE |
|
TRM_CDE |
|
DIV_CDE |
|
LOCA_CDE |
TEST_SCORES |
TST_CDE |
|
TST_SEQ |
|
DTE_TAKEN |
TEST_SCORES_DETAIL |
TST_CDE |
|
TST_ELEM |
|
TST_SEQ |
|
TST_SCORE |
ETHNIC_REPORT_DTL |
ETHNIC_RPT_DEF_NUM |
RACE_REPORT_DTL |
RACE_RPT_DEF_NUM |
|
For the IU_CANDIDACY data, the import will work without the LOAD_P_F, CANDIDACY_TYPE, STAGE, and CUR_CANDIDACY columns defined as being USED or having a value, even though they are required on the Maintain Candidacy window. By default, the LOAD_P_F column will be given a value of 'F' (Full Time) and CUR_CANDIDACY will be set to 'Y' for any imported Candidacy row if values are not specified for these columns. However, no default will be defined for STAGE and CANDIDACY_TYPE. Therefore, if no data is inserted for these two columns for a new row in CANDIDACY, the data will be incomplete. Additionally, if the STAGE column does not have a value in the imported Candidacy data, none of the stage processing will occur for newly inserted Candidacy rows. |
Additionally, for the IU_ETHNIC_RACE_RPT data:
· The SEQ_NUM will default to 1.
· The IPEDS_REPORT_VALUE will default to 0.
· The REPORT_TYPE will default to 'S'.
· The REPORT_DATE will default to the current date and time if the columns are not defined as 'Used' or if the values for these columns are not explicitly defined prior to the import.
