mot (symmys) wrote,
mot
symmys

Rage against the filemaker system...

I've blogged the crap that is our assessment system before and I'll do my best to refrain this year. This year I actually made head-way in learning how to use the import/export feature built-into our filemaker system to get the data out as a CSV file (and, more importantly, to get it back in as a CSV file). This substantially sped up data entry and I marked it as a great victory in the epic tale of me-vs.-the-piece-of-crap. Most importantly, with my new know-how I can show the powers-that-be how to import things like attendance data from their excel spreadsheets, which will save untold teacher-hours of data-entry (and keep untold numbers of teacher-created errors from going home in the progress reports).

Also, I had new evidence that the system was in fact designed by a nimwit -- I got to see the underlying data structure and, friends, it is scary. (details in lj-cut below)

So, until moments ago, I was thinking that this year marked a net victory in the battle of me against insanity.

But then, just a moment ago, the filemaker-program-from-hell decided to segfault on me, which led to me discovering a new WTF: this fine little application, which uses a file-based DB, apparently only commits changes to the database (i.e. to the file) when you quit. Meaning that all the work I'd done today was erased when the application segfaulted (well -- that was my experience; it would be more accurate to say none of the work I had done today was ever saved -- nor could I have saved it, as there is no "save" button since I'm supposed to be imagining I'm interacting with a database rather than writing-to-a-file anyway).

Of course, you can't blame them, can you? I mean, every programmer knows that if you write your program well enough, it can't possibly segfault (bugs? what's a bug? power failures? we can't be blamed for power failures...), so it's perfectly safe to count on saving all your data when the user quits at the end of a session.

So I'll be typing the rest of my comments into another program and then copying them into filemaker, now that I've learned my lesson.

Notes:
1. Here's an example of the ingenius data-base design:
We have slots to write in four different assessments in Spanish -- for each slot we can record the assessment title, skills addressed, and how the student did on the assessment.

Now, I understand from the user interface that the typically "sane" way to design this is out of the question. In a sane system, there would be an assessments-description table in which I could create as many assessments as I wanted, and then a separate assessments table in which I store an assessment-ID, a student-ID and an assessment. Of course, this adds complexity to the programming and the interface, so I understand we won't do that -- we have one very large flat database table and we had to predetermine the number of assessments that could possibly show up on a single progress report (in this case, 4).

So I'd assume from the UI that there would be, you know, 12 columns in the table to deal with this particular chunk of info (3 fields per assessment * 4 assessments), with names like assessment-description-1, assessment-description-2, and so on.

But no -- this is precious -- there is instead one column for each chunk of text (description, skills, assessment). But, you ask, how could their be a mere one column if there are 4 different assessments? Why, that's easy: we use newlines to store the different fields. Yes, friends, newlines.

So, the database actually looks like this:
Assessment NameSkills AddressedAssessment
Listening to a Dialog^KReading a newspaper^KSpeaking with the TeacherListening^KReading^KSpeakingA/M^KM^KA


Now that's beauty.
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

  • 0 comments