Skip to content

DC305 exports

A DC305 export is any file produced from DairyComp 305 for use outside it. There are three broad kinds:

  1. Item and event files. FILEOUT writes items for the selected animals to a CSV or TXT file, and EVENTS\F sends an event list to a file. Herds often save a set of export commands and run them on a schedule.
  2. Inventory reports: animal counts by class (lactating, dry, heifers by age band, bulls and steers), used for month-end counts, lender borrowing-base reports and herd projections. DC305 has built-in ones (ECON\I, ECON\ID, ECON\IHD); many herds also keep saved SUM or COUNT commands whose names vary by herd. See inventory reports.
  3. Backups: DC305’s own backup file of the whole herd database (animals, events, items, saved commands, code tables). Usually a ZIP of DC305’s proprietary data files, not CSV. It needs DC305 or a decoder to read.
Export Built from Typical columns
Animal list FILEOUT (or LIST) of items ID, BDAT, EID, breed, LACT, PEN, RC, FDAT, DDAT, DUE, sex, exit dates
Lactation list FILEOUT of items, cows ID, BDAT, LACT, FDAT, DDAT, lactation totals, DOPN
Event list EVENTS ID, BDAT, LACT, event name, DIM, event date, remark, plus result/technician/type for BRED
Breeding list EVENTS BRED ID, LACT, breeding date, sire, technician, breeding type, result code
Pregnancy-check list EVENTS PREG OPEN ID, LACT, check date, result, remark
Pen counts SUM … BY PEN pen, head count, averages
Inventory ECON\I, or SUM/COUNT by class class, head count

File names (EVENTS.CSV, BRED.CSV, and so on) are whatever the herd’s saved commands call them. Map them in the herd’s private dc305-vocab page.

Build the report as a command, check it on screen, then send it to a file:

LIST ID BDAT LACT PEN RC FDAT DDAT DUE FOR LACT>0 check on screen first
FILEOUT\CH ID BDAT LACT PEN RC FDAT DDAT DUE FOR LACT>0 current cows to a file
EVENTS\2B BRED ID BDAT LACT FOR EDAY>-180 breedings, last 180 days, incl. sold/died
ECON\I inventory by class
SUM BY PEN pen counts

Switch meanings that explain common saved export commands: on LIST and EVENTS, \B adds dead (sold or died) animals to the live ones, \D gives dead animals only, and EVENTS\2 is the list of cows and events (with \S for a date range and \I to pick events). EVENTS\F writes to a file.

Good practice for scheduled exports:

  • Use rolling date windows (EDAY>-180) wide enough to catch late-entered events and results that change after a pregnancy check.
  • Include ID and BDAT in every file so animals can be matched across files.
  • Include animals that have left the herd (\B) when counting past calvings, deaths or sales; LIST, SUM, COUNT and EVENTS are live-only by default.

Herd context: any DC305 herd; codes and items vary by herd setup.

  • An event export for a few thousand cows over 6–12 months is typically tens of thousands of rows.
  • Backups run nightly in most herds that sync with outside tools.
  • Inventory reports are usually pulled at month end.
  • Two-digit years. Dates usually print as MM/DD/YY. A birth date of 03/02/20 is 2020, but parsers can guess the century wrong for old animals.
  • Locale. A parser set to day-first dates reads 03/02/20 as 3 February. Fix the date format explicitly.
  • Padded fields. Values are often space-padded inside the commas ( 1507 ,03/02/20, 4 ,ABORT ,). Trim every field.
  • IDs are not unique over time. Barn numbers get reused. Key animals on ID plus BDAT, or EID / registration number.
  • Relative dates move. EDAY>-30 depends on the day the export ran; record the run date with the file.
  • 0 means unset. An empty numeric item exports as 0, not blank.
  • Item columns show current values. An event export’s PEN or RC column is today’s value, not the value on the event date.
  • Breeding rows change. A breeding’s result (and sometimes its label in the export) changes after a check, and the same breeding can appear more than once. De-duplicate and re-read the full window, don’t append.
  • Columns change. Editing a saved export command adds or drops columns. Read files by header, not by position.
  • Treating a backup as a CSV source. Backups are proprietary binary files.