Heh. If it were a smaller query, I might share it, but it's got lots of annoying decoding logic (MTWRFSU, time of day, name/facility lookups, etc.). In any case, I'm fairly confident that it's not making up class_mtg_pat rows that don't exist, as it's been running for a couple of years now, and this is the first time we've run across this particular glitch.
Basically, I'm creating a single row for each meeting pattern record, and labeling them "SED625_20_0980_2620_UMS05", "SED625_20_0980_2_2620_UMS05", "SED625_20_0980_3_2620_UMS05", etc. (I omit the _1 because most classes don't need to distinguish multiples) In this case, I had a student enrolled in two meeting patterns, but when they withdrew, the class only had one meeting pattern, so only the first record was marked as withdrawn, and the external system just carried the second record along from the original export. The SED class above properly withdrew all 9 rows, so I know it's not a general multi-row bug.
------------------------------
Garrett Fitzgerald
Senior Analyst Programmer I
University of Maine
------------------------------
Original Message:
Sent: 04-09-2026 01:14 PM
From: Scott Nishizaki
Subject: Disappearing meeting patterns
Hey Garrett,
I think we might need to see the SQL of your export.
I'm assuming there's not an issue with the actual student enrollment records just the way your export reports them? Class sections with multiple meeting patterns are for sure complex to query, especially if you're trying to aggregate and/or show distinct data (instructor, days of the week, times etc.).
------------------------------
Scott Nishizaki
Connected Campus Community of Practice
Developer/Analyst
Azusa Pacific University
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
------------------------------