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.
Original Message:
Sent: 04-08-2026 06:06 PM
From: Garrett Fitzgerald
Subject: Disappearing meeting patterns
I have an export for student schedules. I just ran into a case where it seems that a class had two meeting patterns when it was created, but only one when people dropped it - which left the second row still enrolled. Has anyone run into this? Is there some way of tracking deleted meeting patterns short of setting up auditing, which I had to do for classes dropped before the LST_DROP_DT_DEL date? (Which isn't the way I'd like to handle it, because it's not actually dropping a class, just removing a row for a meeting pattern)
Thanks for any thoughts you have.
------------------------------
Garrett Fitzgerald
Senior Analyst Programmer I
University of Maine
------------------------------