Greetings, I was looking to sign off bug 18111, which looks good by the way, and then I noticed that ods and xml exports were floody. So, I was pondering how to fix them, because the code is reminiscent of MARC indicators and not authorised_value or framework code. So, I put in a condition to catch things and make it not floody, but then my exports were strange. Some had ‘#’ and some had ‘’ in the authorised_values. This, of course, didn’t match the CSV patch in bug 17389. And regardless of format, I would expect the same values in the columns. So I thought, “Why are some #’s and some blank?” Turns out marc_tag_structure has both NULL and empty strings in the authorised_value field. I thought to myself, “Where did this get set?” I had recently dropped and recreated my database, so it had to be an installer file. Well, it turns out that installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql has some NULL and some empty strings. So, first question: is that right? So, then I thought, “Okay, so where is this # being processed?” I found it around line 1128 in C4/ImportExportFramework.pm which reads: $data = '' if ($data eq '#'); So, second question: shouldn’t an empty string have been put out in the first place? To which I thought, “Bah! It works. It’s ugly and gross and should be refactored somehow, but I don’t know which way, so I’ll just leave it.” So, last question: if you were going to refactor, what would your plan of attack be? This includes choosing not to refactor as an option. GPML, Mark Tompsett