Result pages: 1
09:58 | dbwells | We're still on 9.1.14, so that might be a factor in why the code I posted has always worked for me. |
10:00 | Newziky joined #evergreen | |
10:00 | gmcharlt | dbwells: indeed |
10:00 | dbwells | I've also had luck with something like the following (where the "namespace" argument structure can actually be any namespace you want): |
10:00 | dbwells | SELECT xpath('/marc:record/marc:datafield[@tag="245"]/marc:subfield[@code="a"]', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]) from biblio.record_entry where id = 12345; |
10:00 | gmcharlt | dbwells: likewise |
10:08 | Dyrcona | Yeah. I just gave up and used mrfr. I don't want to spend all morning on it. |
10:19 | Dyrcona | On my opensrf.settings issue: I have almost ruled out the hold targeter and a/t runner, but not exactly. |
16:15 | * Dyrcona | would love to email EBSCO and say, you're counting the record length incorrectly, but I doubt that they would listen. |
16:20 | pastebot | "Dyrcona" at 64.57.241.14 pasted "MARCXML for EBSCO" (199 lines) at http://paste.evergreen-ils.org/11 |
16:21 | Dyrcona | gmcharlt: That is not straight out of our database because I am also exporting item info in 852 tags. |
16:29 | dbwells | Dyrcona: probably just a past problem, but your example record has an extra </datafield> after the 852 |
16:29 | dbwells | s/past/paste/ |
16:29 | * Dyrcona | doesn't care enough to bother with that. |
16:29 | Dyrcona | Straight out of the MARC documentation: Computer-generated, five-character number equal to the length of the entire record, including itself and the record terminator. The number is right justified and unused positions contain zeros. |
16:30 | Dyrcona | So, MARC doesn't say it it is octets or characters. |
Result pages: 1