Database Tables

ACCOUNT_P_AND_L_SPREADSHEET_ML

Table used in Solutions AccountMapper program to fill the data in bottom search box. Downloaded from a Rutgers source (ask Cornelia Kinsella for source)

cfdata_10

Table to hold inbound Special Permission Honors Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_SPHonorsRequests tables

cfdata_111

Table to hold inbound Honors Candidate RSVP Data from getforms2.py before processed by Solutions Control Center and used to update the tbl1_honors_candidates table

cfdata_11

Table to hold inbound Transfer Credit Preapproval Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_TransferRequests tables

cfdata_121

Table to hold inbound Special Permission for Non-Matriculating Student Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_SPNMRequests tables

cfdata_123

Table to hold inbound Special Permission for Multiple-Fails Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_SPMFRequests tables

cfdata_12

Table to hold inbound Transfer Credit Postapproval Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_TransferRequests tables

cfdata_74

Table to hold inbound Prerequisite Override Request Data from getforms2.py before processed by Solutions Control Center and moved to tbl1_Requests and tbl1_PrereqRequests tables

css_courses

Obsolete? This was used before we switched to using css_sections

css_sections2

This table is used in conjunction with the getcss and putcss python programs and the css_upload table. The process works as follows: (i) Data from getcss.py fills this table. (ii) Solutions Synchronize process copies this data into css_upload table and makes edits reflecting any changes that have happened in Solutions, most commonly instructor assignments (iii) the putcss.py program uses css_upload to post changes to CSS (course scheduling system) web data

css_sections

This table is used in conjunction with the getcss and putcss python programs and the css_upload table. The process works as follows: (i) Data from getcss.py fills this table. (ii) Solutions Synchronize process copies this data into css_upload table and makes edits reflecting any changes that have happened in Solutions, most commonly instructor assignments (iii) the putcss.py program uses css_upload to post changes to CSS (course scheduling system) web data

css_sync_options

This table is used to tell Solutions how instructor to/from Solutions and CSS should be handled based on the course unit and subject

css_upload

This table is used in conjunction with the getcss and putcss python programs and the css_sections table. The process works as follows: (i) data from getcss.py fills the css_sections table (ii) Solutions Synchronize process copies data from css_sections into css_upload table and makes edits reflecting any changes that have happened in Solutions, most commonly instructor assignments (iii) the putcss.py program uses css_upload to post changes to CSS (course scheduling system) web data

Email_Default_Wording_gd

In grant deadlines program (GrantDeadlinesDashboard.accdb) this table contains the default wording of the email that will come up when the “compose email to selected PIs” function is used. It can also be edited via the programs interface. Future Recommendation: Obsolete this table and merge content into a single email_templates table

Email_Default_Wording_hc

In honors candidates program (HonorsCandidatesDashboard.accdb) this table contains the default wording of the email that will come up when student invitation emails care composed. Future Recommendation: Obsolete this table and merge content into a single email_templates table

exam_schedule

This table holds the final exam schedules as pulled from the SAS final exam schedule website, https://finalexams.rutgers.edu/ It is populated at regular intervals when the python getfinals.py program is run. This program takes data from the Rutgers SAS final exam schedule website and fills this table with exam dates for upcoming semester as they are posted. Solutions Control Center will then periodically check for new schedules and when found incorporate the dates into the semester schedules in the tbl1_Schedule_Data and tbl1_FinalExamDates tables

Grant_Deadline_Data_Template

Obsolete. Can drop from MySQL once we are on Solutions frozen version #2 or higher

Grant_Deadlines

This table holds the grant deadline data used in the GrandDeadlinesDashboard.accdb program. The program imports data from cornerstone report output, and reformatts for staff use of this utility. See MATHDATASolutions_Sample_Import_Formats for specification of import data

Honors_Candidates_Data_Template

Obsolete. Can drop from MySQL once we are on Solutions frozen version #2 or higher

logfiles_reformatted

reformatted version of data in logfiles table to enable nice display in control center dashboard

logfiles

table that contains the recent log messages that were accumulated through crontab running of python programs. Solutions Control center queries this table and saves in nicer format in logfiles_reformatted table, which is used to display the log messages in the different tabs of its dashboard.

request_importer_kill_requests

We might want to obsolete this. Usage here was to solve problem of a user leaving control center running on their computer, and then the computer logging out and other users not able to kill the program. This table enabled a user from another computer to enter a user name (the “Kill Auto-Scan for user name” field on control center dashboard main window) in order to send a message to kill process running to other computer. To my knowledge we have never really needed to use this, and with current technique of always leaving control center running on same computer, this might be able to go away.

RIAS_FULLMAPPING_PROJECTSFLAG

Table used in Solutions AccountMapper program to fill the data in top search box. Downloaded from a Rutgers source (ask Cornelia Kinsella for source)

sol_columns

sol_tables

summer_section_dates_inbound

This table holds the summer section dates as published on Rutgers summer session website. It is populated at regular intervals when the python get_summer_dates.py program is run. Solutions Control Center will then periodically check for new schedules and when found incorporate the dates into the semester schedules in the tbl1_SummerSectionDates` table

summer_sections_IS

I am pretty sure this table is obsolete and okay to drop

survey_alternate_field_names

This table is a collection of field names and associations to bridge the gap between the field names on Qualtrics surveys and the corresponding table field names within the Solutions tbl1_survey_responses table. The reason we needed this table was because in the beginning semesters of designing our Qualtrics survey we did not always adhere to the conventions in place now, and we need a way to translate what old field names used to be with the our new conventions. If this program is ever re-designed it would be nice to do it in a way that we don’t need to use this table anymore.

tbl1_about_300

This is the Solutions “About” table for the 300_checker application. Solutions will compare version numbers in this table with version numbers in the tbl1_about_300_local table in 300_checker.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_about_account_mapper

This is the Solutions “About” table for the account_mapper application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_account_mapper_local table in AccountMapperDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_about_control_center

This is the Solutions “About” table for the Control Center application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_control_center_local table in ControlCenterDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_about_ff

This is the Solutions “About” table for the Form Fit application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_ff_local table in FormFitDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_gd

This is the Solutions “About” table for the Grant Deadlines utility application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_gd_local table in GrantDeadlinesDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_hc

This is the Solutions “About” table for the Honors Candidates Utility application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_hc_local table in HonorsCandidatesDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_IS

This is the Solutions “About” table for the Instructor Survey application. Solutions will compare version numbers in this table with version numbers in the local tbl1_About_is_local table in InstructorSurveyDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_request_importer

This table became obsolete when we merged request importer into control center application

tbl1_About_room_finder

This is the Solutions “About” table for the Room Finder application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_room_finder_local table in RoomFinder.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_rp

This is the Solutions “About” table for the Request Portal application. Solutions will compare version numbers in this table with version numbers in the local tbl1_about_rp_local table in RequestPortalDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_sd

This is the Solutions “About” table for the Solutions Database application. Solutions will compare version numbers in this table with version numbers in the local tbl1_About_sd_local table in SolutionsDashboard.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_About_SV

This is the Solutions “About” table for the Summer Validator application. Solutions will compare version numbers in this table with version numbers in the local tbl1_About_SV_local table in SummerValidator.accdb If version numbers do not match, the program will not be allowed to start up. Future Direction: It would be nice to have a single solutions “About” table with a field for the version number of each application, instead of all of these separate tables.

tbl1_Advising_Office_Contacts

This table holds the contact information for the advising office that should be contacted with student request decisions as needed. There is one contact listed per student’s school (within Rutgers, for example SAS). List can be maintained via the ‘Advising Office Conatacts’ button on the Request Portal’s transfer credit window. It is used when evaluator clicks the “Email Student’s School Advising Office” button, or the “Email Other Advising Office” button

tbl1_AppointmentHistory

This table relates to the tbl1_Appointments table where one appointment in tbl1_Appointments can have many related records in tbl1_AppointmentHistory. This tables contains a record for each person who has held a particular appointment during a particular timeframe.

tbl1_Appointments

This table holds a list of the department’s appointments. These are the jobs where a person is assigned to the job for a particular amount of time.

tbl1_Buildings — Rutgers Building Codes

This table translates Rutgers building codes and numbers to building names.

tbl1_Campuses

Rutgers campuses and campuse codes

tbl1_Categories

This table contains a list of the categories of people in the department and their associated abbreviations. These categories drive many things within Solutions since different categories of people are handled differently

tbl1_course_docs

This table gives names of documents associated with courses. It is assumed that the documents are saved in a “docs” subfolder under the share path

tbl1_CourseFormats

This table describes the ways a course format can be categorized based on how it is presented For example “Lecture and Recitation” which typically has 2 lectures and one recitation per week

tbl1_CourseModes

These are the different types of meetings within a course, for example “L” for lecture and “R” for recitation.

tbl1_CoursePageTemplates

This table was to be used to display HTML template for course page HTML. This is not used at this time, and was intended to eventually be used in the procedure of automatically generating HTML in a standardized format for course pages on our website, while plugging in data from the solutions tbl1_Courses table. If we decide definitively not to use this feature, then this table can be obsoleted.

tbl1_Courses_DateTracker

This table keeps track of when each semester was last synchronized and when projected enrollments were last refreshed.

tbl1_Courses

Table containing all the courses the math department cares about

tbl1_DepartmentContactInfo

Possibly obsolete. Used by Request Portal. Some request types have a button “Math Department Contact” that takes data from this table.

tbl1_EmailTemplates_rp

This table contains the email templates used in the Request Portal application

tbl1_EmailTemplates

This table holds the text for various email templates Each template supports a series of bookmarks using the convention <bookmark_name> which will be replaced with the relevant content when composing emails. List of bookmarks available for each template type are in the template_bookmarks table

Tbl1_EnrollmentHistory

This table contains a snapshot of the total enrollment per course offering for a semester and a date. Every time the Solutions synchronize procedure is run, this table is filled in with a snapshot of current enrollments. Department Chairs and Advisors can use this information to track enrollment trends over time

tbl1_Evaluators

List of Request Evaluators used by Request Portal program

tbl1_exam_dates_EventLog

This table holds the log messages when exam dates are pulled from https://finalexams.rutgers.edu/ with the getfinals.py Python program. The log data is viewable in Solutions Control Center in the Exam Schedule tab

tbl1_FinalExamDates

This table holds the final exam schedule per semester per exam group.

tbl1_FinalExamRooms

This table holds the rooms that can be used for final exams. Solutions’ “Find Exam Rooms” function from the course scheduling screen will use the information in this table to assing exam rooms to sections.

tbl1_GraderPayRates

This table is used to specify grader pay rates. Graders are paid hourly based on the course number.

Tbl1_GradLines

This table is one of the tables available from Solutions main window’s Table Maintenance area.

tbl1_honors_candidates

This table is used by the Solutions Honors Candidates utility program to keep track of students who are candidates for math department honors courses.

tbl1_honors_response_log

This is a logfile of students who submit responses to honors course invites via the RSVP chronoform. Data is pulled when the getforms2.py program is run. This log data is viewable via the Honors Responses tab in the Solutions Control Center. Honors invites are sent via the Solutions Honors Candidates Utility program

tbl1_ImportedData_ff

temp table to hold data imported for use in the Solutions Form Fit program

tbl1_ImportedData_gd

temp table to hold data imported for use in the Solutions Grant Deadline Utility program

tbl1_ImportedData_hc

Temporary table to hold data imported for use in the Solutions Honors Candidates program.

tbl1_ImportedData_IS

tbl1_ImportedDataReformatted_ff

temp table used by used by form fit program for reformatted data in the summer salary function

tbl1_ImportedDataReformatted_PU_ff

temp table used by used by form fit program for reformatted data in the payment upload function

tbl1_Instructors_ClassesTaught

This table holds the saved schedule data for semesters. It is used to generate course schedule HTML that appears on math department website’s Teaching Schedule page and drives many Solutions processes and reports.

tbl1_LastGenerated_rf

This table keeps track of the last time results were generated by the room finder program and what the parameters used to generate the results were

tbl1_LastImportDates_IS

This table keeps track of the last time survey results were imported into the tbl1_survey_responses table for the indicated semester

tbl1_Offices

This table lists offices used by people in tbl1_People table

tbl1_options_ff

Options used in the Form Fit program

tbl1_People_AlternateSpellings

obsolete? see footnote

tbl1_People_docs

This table keeps track of documents associated with people.

tbl1_People_Events

Possible employment events for a person used in the tbl1_Person_History table

tbl1_People

This table is one of the centerpieces of Solutions and has many related tables. It holds all of the data for people associated with the department.

tbl1_periods_and_rooms

This is an administrative table used by the room finder program. Each time the room finder program is run, the “Available_Room_List” column of this table will be cleared and re-derived based on current search results.

tbl1_period_timeslots

This is an administrative table used by the room finder program. It is used to tell the program what timeslots need to be checked for availability depending on the campus and period being searched. This table was added to facilitate scanning rooms since (i) different campuses have different period schedules, and (ii) the IMS program only displays availabilities per every 30-minute block of time.

tbl1_Person_History

List of employment events for a person

tbl1_PrereqRequests

Student Prerquisite Override requests

tbl1_PTLPayRates

This table keeps track of the current PTL pay rates for a semester

tbl1_Registrar_Contacts

This table keeps track of the email addresses the request portal program should use to email decisions to the registrar’s office based on semester

tbl1_request_importer_EventLog

Log of student requests imported into tbl1_Requests table, viewable in control center

tbl1_request_importer_last_scans

keeps track of last time each particular request type was scanned

tbl1_RequestsBeingEdited

This is a little table that is used in Request Portal to disallow other users from editing requests that are being viewed by other evaluators

tbl1_Requests

high-level table to hold student requests

tbl1_results_rf

Table used by Room Finder program to collect the results

tbl1_Roles

List of roles a person can play when associated with a course and section

tbl1_Rooms

This tables lists classrooms for use in room assignments etc

Tbl1_Schedule_Data_Unformatted

This table is used to hold data as it is imported from CSS. Obsolete?

tbl1_Schedule_Data

This table holds all of the schedule data used in Solutions.

tbl1_schedule_inbound_from_css

This table is used for the Control Center Sync procedure. Most fields in this table parallel the fields in tbl1_Schedule_Data so please look at that table for more specifcs. Also refer to footnote for more info.

tbl1_Semester_Statuses_Payroll

Works similar to tbl1_Semester_Statuses but for use with the Solutions payroll functions

tbl1_Semester_Statuses

This table lists all of the semesters known to Solutions so far, and corresponding statuses.

Tbl1_SIRS_data

This table imports and saves a summarized version of Instructor Rating values from SIRS surveys that are sent to us from CTAAR office. This data is importable and viewable from the Solutions Database SIRS Summary report category.

tbl1_SPHonorsRequests

Student Special Permission Honors Requests

tbl1_SPMFRequests

Student Requests for Permission to take a course after failing multiple times

tbl1_SPNMRequests

Student Special Permission for Non-Matriculated Student Requests

tbl1_SPNumbers

Special Permission Numbers

tbl1_Statuses

Statuses that can be given to a person

tbl1_Student_CourseHistory

Obsolete?

tbl1_StudentEmailDisclaimer

This table holds some disclaimer text that can be used as a bookmark in email templates when composing email to students about request portal transfer request decisions.

tbl1_Student_Proficiencies

Obsolete?

tbl1_Students

Students who have made requests through our web forms and request portal

tbl1_summer_schedule_EventLog

Logfile for when summer session dates are grabbed from summer session website

tbl1_SummerSectionDates

List of summer section dates based on year and section letter code

tbl1_survey_field_usage

This is an internal table used by the Instructor Survey program. In the process of importing survey results, Solutions looks at the inbound fields, and creates an entry in this table to list the fields that were used in the particular survey, and which instructor types were presented with the question. This will later be used for other functions in the instructor survey program.

tbl1_survey_responses

Data table containing all survey responses from Teaching Availability and Preferences survey and each instructors’ response answers

tbl1_sync_log

This table has a log of when the Solutions sync with CSS was performed. It is viewable in the Solutions Control Center “css sync” log tab

tbl1_sync_messages

Messages generated from Solutions sync with CSS for discrepancies found

tbl1_SystemOptions

System Options for Solutions Applications. Most of the fields here that are configurable are accessibly via the Solutions Database’s System Options window, accessible via the little button with a globe picture on the Solutions Database’s main window.

tbl1_teaching_load_reduction_types

This table quantifies the types of teaching load reductions an instructor might have, for example a service reduction or a research reduction.

tbl1_teaching_loads

Tbl1_TimeConflictChart

Used by summer validator to indicate whether a pair of times indicate a conflict

tbl1_Titles

This table contains the possible job titles that department staff and faculty might have

tbl1_TransferRequests

Student Requests for Transfer Credit Preapprovals or Postapprovals

tbl_survey_field_usage

I think this is obsolete and was mistakenly added to db when the actual table is tbl1_survey_field_usage

Tblx_DataToSynchronize2

obsolete, as far as I can tell.

Tblx_DataToSynchronize

This is a temp table used in the reformatting of data pulled in from CSS export/import. The fields in this table parallel the fields that come out of CSS in it’s data export. It is somewhat obsolete (see footnote)

tblx_Graders_Data

This table is used to hold the grader data for the grader payroll function.

tblx_incoming_requests_prereq

obsolete

tblx_incoming_requests_sp_honors

obsolete

tblx_incoming_requests_spmf

obsolete

tblx_incoming_requests_spnm

obsolete

tblx_incoming_requests_xfer_post

obsolete

tblx_incoming_requests_xfer_pre

obsolete

tblx_PTLs_Data

This table is used to hold the PTL data for the PTL payroll function.

Teaching_Availability_and_Preferences_Data_Template

obsolete?

template_bookmarks

This table was created to consolidate the list of bookmarks available throughout email templates throught all of the Solutions applications. It was built so that we can get rid of hard-coded bookmarks within the applications and make this table-driven instead. It is internal within Solutions, and not editable by users.

template_tags

This looks like more bookmarks used for email templates in Solutoins Database; however, this might be obsolete, need to look closer

tmp_honors_rsvps

This is a temp placeholder table used to import student responses to invitation to honors course invites from the exported Chronoform csv file. This is mostly obsolete since we are now using the getforms2.py python program to pull in these RSVPs. However, since the ‘import student responses’ button still exists in the Honors Candidates program, we should keep this just in case.