Skip to main content

CALPADS error brief · IVR

IVR0034

Duplicate Record within File based on Operational Key
Severity Fatal
Error type Input Validation
Record type IVR

Official CALPADS rule

What CALPADS is rejecting

Two or more records exist with the same operational key fields

Focus fields

Fields validated

1.05 - School of Attendance 1.08 - SSID 1.22 - Enrollment Start Date

Recommended correction path

Suggested resolution

Read the complete validation

CALPADS rule: Two or more records exist with the same operational key fields.

Severity: Fatal   Type: Input Validation

Operational-key fields:

  • 1.05 School of Attendance
  • 1.08 SSID
  • 1.22 Enrollment Start Date

How two different-looking rows collide

School of Attendance1234567
SSID1234567890
Enrollment Start Date20260817
CALPADS resultOne operational key
Non-key differences do not prevent IVR0034
Submitted rowSame operational keyDifferent non-key payloadWhat CALPADS sees
Row 181234567 | 1234567890 | 20260817Status 10; Grade 09; no exitTwo versions of one key—not two separately identifiable enrollments.
Row 421234567 | 1234567890 | 20260817Status 10; Grade 10; exit populated

The numbers above are fictional and illustrate key behavior only.

“Delete one duplicate” is not yet a complete correction plan. First compare every field and identify which row—if either—accurately represents the documented enrollment. Arbitrary deletion can preserve the wrong grade, wrong status, stale open enrollment, incorrect exit, or wrong student.

Classify the collision before correcting it

Different collision types require different corrections
Collision typeHow to recognize itEvidence-based response
Exact duplicate rowsEvery submitted field, including transaction and payload, is identical.Retain one intended row, remove the redundant copy, and repair the query/export process that emitted it twice.
Same key, conflicting payloadThe three key fields match, but grade, status, exit, completion, transfer, or another field differs.Reconstruct the actual enrollment and build one correct complete transaction for that key.
Original plus revised versionA source query exported both an older snapshot and its corrected version.Identify the authoritative current record and modify the extract so only the intended transaction is emitted.
Two legitimate enrollments collapsedLocal evidence supports two enrollment episodes, but the submitted start dates or schools were made identical.Correct the inaccurate key field using actual attendance/enrollment evidence; never invent a date simply to make the rows unique.
Two students collapsed under one SSIDLocal IDs or names differ while the key uses the same SSID.Stop processing and reconcile student identity before changing enrollment history.
One enrollment duplicated by a joinThe same SIS enrollment appears once for each program, contact, schedule, school-year, or related-table row.Correct the query grain so one enrollment source record generates one SENR transaction.
Merged export batchesThe same student/key appears in two extracts concatenated into one upload file.Submit one controlled batch and repair file-assembly or scheduling logic.

Compare the complete rows—not only the key

A practical reconciliation worksheet
Field groupCompareQuestion to answerEvidence owner
Submission controlTransaction Type, Local Record ID, source row, batch, export timestamp.Did one source record generate both rows, or were separate versions combined?CALPADS coordinator and extract owner.
Operational keySchool of Attendance, SSID, Enrollment Start Date.Are all three values factually correct for the intended enrollment?Registrar/enrollment staff and authorized identity staff.
Enrollment meaningEnrollment Status, Grade Level, School Transfer, District of Geographic Residence.Which row describes how and where the student was actually enrolled?Registrar, site staff, and program owner.
Exit and outcomeExit Date, Exit Reason, Completion Status, expected receiver school.Is one row an outdated open record while the other contains the supported exit?Enrollment, counseling, completion, or cohort staff.
Student identitySSID, Local Student ID, legal-name and birth fields used for identification.Do both rows truly belong to the same person?Authorized student-records staff.
Source-system lineageSIS enrollment ID, import origin, update timestamp, query/join path.Which source record is authoritative, and why did the second row appear?SIS, integration, or vendor support.

What commonly creates the second row

Recurring technical causes and durable repairs
Technical patternWhy it duplicates the keyWhat to inspect
One-to-many database joinOne enrollment joins to multiple contacts, programs, schedules, services, or audit rows.Query grain, join predicates, effective dates, and pre-aggregation.
Union or append without deduplicationCurrent and historical extracts contribute the same enrollment.Batch boundaries, union branches, date filters, and job schedules.
Update emitted beside originalBoth before-change and after-change versions remain in the staging set.Change-data logic, effective record selection, and latest-row rules.
Manual file concatenationThe same school/student batch is pasted or appended twice.File names, row ranges, upload assembly, and staff procedure.
E150 or grade-change workflowA midyear update is generated without a genuinely distinct supported enrollment start date.Local E150 configuration, continuation record, start/exit chronology, and current CALPADS rules.
Stale record not retired locallyAn inactive local enrollment continues to qualify for the extract beside its replacement.Active flags, enrollment status, effective dates, and suppression criteria.

Choose the diagnostic pathway

  • Confirm the duplicate set
    • Which row numbers share the same school, SSID, and start date?
    • Are there two rows or a larger duplicate group?
    • Are the rows byte-for-byte identical?
    • Do Local Record IDs or source enrollment IDs identify their origin?
    • Does the same key appear in another batch or file?
  • Reconcile student identity
    • Do both rows belong to the same SSID and person?
    • Do Local Student IDs and identifying fields agree?
    • Could two students have been assigned the same SSID locally?
    • Is the SSID active and correct after any MID resolution?
    • Should submission stop for identity review?
  • Reconstruct enrollment chronology
    • Was there one enrollment episode or two?
    • What was the first date the student was expected to attend each school?
    • Are school, status, grade, start, and exit values supported?
    • Did an E150 or other midyear update create a new enrollment?
    • Which complete row tells the documented story?
  • Compare transaction intent
    • What Transaction Type appears on each row?
    • Is one row an older version and the other a correction?
    • Was an Add, Delete, or Replace transaction generated as intended?
    • Does the current CALPADS ODS already contain the key?
    • What single transaction should this file communicate?
  • Trace the extract defect
    • Which SIS record produced each submitted row?
    • Did a one-to-many join multiply the enrollment?
    • Were historical and current snapshots combined?
    • Did manual file assembly duplicate a row range?
    • Will the next scheduled export reproduce the collision?

Resolve the record before repairing the generator

  1. GroupFind matching keys.
  2. CompareDiff complete rows.
  3. ProveReconstruct enrollment.
  4. RepairFix source and extract.
  5. VerifyConfirm one correct key.

Primary participants

  • CALPADS coordinator
  • Registrar or enrollment staff
  • Authorized student-identity staff when SSIDs differ from local evidence
  • SIS system owner
  • Extract, integration, or vendor support

Assign ownership by cause

  • True redundant copy: extract/file-assembly owner.
  • Conflicting enrollment facts: registrar and SIS owner.
  • Wrong SSID: authorized identity reconciliation.
  • Wrong school/start date: enrollment evidence review.

Recommended correction path

  1. Preserve the submitted evidence

    Save the untouched file, submission details, rejected row numbers, Local Record IDs, and exact duplicate-key values.

  2. Group every matching operational key

    Find all rows sharing School of Attendance, SSID, and Enrollment Start Date; do not stop after locating the first pair.

  3. Compare every field

    Determine whether the rows are exact copies or disagree on transaction, identity, grade, status, exit, completion, or transfer information.

  4. Reconstruct the authoritative enrollment

    Use SIS history, attendance, registration, transfer, withdrawal, and completion evidence to establish what actually occurred.

  5. Choose the correct disposition

    Remove a true redundant copy, build one corrected version of a conflicting record, or repair inaccurate key fields for genuinely distinct enrollments.

  6. Correct the source and generator

    Repair the SIS record, query grain, joins, filters, staging logic, scheduling, or manual assembly process that created the collision.

  7. Regenerate a clean file

    Verify each operational key occurs once and that the surviving complete row contains the intended transaction and payload.

  8. Resubmit and inspect CALPADS

    Confirm IVR0034 clears, then verify the student’s complete enrollment history rather than relying only on submission acceptance.

  9. Search for systemic duplicates

    Check other students, schools, dates, files, and scheduled exports affected by the same generation logic.

Before closing the issue

  • Confirm each School + SSID + Start Date key occurs only once in the regenerated file.
  • Verify the surviving row contains the correct complete transaction—not merely the first occurrence.
  • Confirm the SSID belongs to the intended student.
  • Verify school, start date, status, grade, and exit information against enrollment evidence.
  • Inspect the accepted CALPADS enrollment history.
  • Document the source-system or extract defect and test other affected records.

Official SENR IVR0034 troubleshooting page  |  SENR guidance  |  Current CALPADS system documents