The Emilda FAQ contains frequently asked questions about Emilda, the installation and related issues.
To ensure the base for understanding the importing and thus handling of MARC records within Emilda, some basic concepts have to be clarified.
1. MARC information resides within the Zebra server in Emilda. This directly implies that no bibliographic data exists in MySQL.
2. For administrative purposes, administrative data of items is stored in MySQL. Such administrative data is e.g. the Item Type of this particular item, the Control Number that links the item to the MARC record in Zebra etc.
Importing data, i.e. not using the Z39.50 searching or manual adding within Emilda, can be split up into subsections as follows.
1. What MARC fields are required for Emilda to be able to import records?
The only compulsory field that Emilda requires is the field 001 - Control field, (see q2). It is of course rather useless to add Items that do not contain any data, as they are virtually imposible to access.
Just as in importing records from an Z39.50-server, You can supply "any" information within the MARC record to Emilda, and it will use the information that it has been configured to do (the MARC configuration section). So if You only have field 100 configured within Emilda, You might only supply that field in the generated Titles, but if You maybe later would like to change the setup of fields, it is a good idea so add all information present into the records so that when needed the information can be accessed.
2. Are there any MARC fields or field values (for instance, "001") that I should avoid converting so that there will not be any conflicts with existing Emilda records?
Emilda uses an incrementing number as the control number - 001 to link the "Items" in the MySQL database together with the MARC records. There is no direct need to give the imported fields a control number according to the Emilda-type of control numbers, but it would be safer in case the Records at a later stage will be edited within Emilda.
In the table "control" within the Emilda MySQL database, there is a row called, "last_control_number" which represents the last added control number. This You can use when generating the records to get the last record. The control number is of the type 0000000001, where the total length is "CONTROL_NUMBER_LENGTH" (from the control panel), and the "1" is a actual id, and the zeros are just padded to achieve the length. The zeros are compulsory for indexing purposes.
3. How must I put these Titles into the Zebra records directory? Should they be one file per title? All 400 titles in one file? What should I name the file(s) so that there is no conflict with the existing Emilda Zebra records?
The file naming has to be done according to the control number. What this implies that each record has to be a single file, with the file name identical to the control number of that record. When You list the files in the Zebra records folder, You will see files named of the type 0000000001. When creating these records, remember to give the correct file permissions to avoid errors, i.e. the apache user has to have write access to these files.
4. How must I set up the corresponding data in MySQL?
Each Record has at least one Item attached to it, for the system to be sane. This means that You can have "Records" in Zebra, but without a linkage to this record in the MySQL database the records is worthless. The table structure of the books table is as follows:
+---------------------+----------------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+----------------------+------+-----+------------+----------------+ | book_id | int(10) unsigned | | PRI | NULL | auto_increment | | book_control_number | varchar(255) | | MUL | | | | book_date_added | date | | | 0000-00-00 | | | book_date_deleted | date | | | 0000-00-00 | | | book_borrowed | tinyint(1) | | MUL | 0 | | | book_reserved | tinyint(1) | | | 0 | | | book_deleted | tinyint(1) | | MUL | 0 | | | book_borrow_count | smallint(5) unsigned | | | 0 | | | book_location | tinyint(3) unsigned | | | 0 | | | book_item_type | varchar(255) | | | | | +---------------------+----------------------+------+-----+------------+----------------+
where the important fields are:
book_control_number: The control number of the record that this particular item is linked to
book_location: the location of the item, i.e. in which library instance it exists
book_item_type: the type of item it is. (check item_types table for reference)
This set of information should be enough to get any system up and running.
We have noticed that compiling Zebra so that the Perl libraries get compiled correctly is quite tricky business. However, David experimented on this and found an order in which things should be done to achieve a sane system. Below is the findings of this mail. In case You are experiencing problems compiling Zebra correctly, it is adviseable to follow these steps.
First, I needed these package on my Debian system before it would build properly: automake1.4, tcl8.3-dev, libncurses5-dev, libexpat1-dev, libyaz-dev (>= 2.0.2), libssl-dev, libbz2-dev, autoconf2.13, libperl-dev Also, I found it is very important to do things in order: 1. ./configure
2. make
3. cd perl
4. perl Makefile.PL
5. make
6. cd ..
7. make install
8. cd perl
9. make install
The login (index) page for Emilda 1.2 looks for a file called .setup in the Emilda directory. If that file is not writeable by the web server user (usually apache or www-data) Emilda setup cannot update it, therefore prompting to run setup everytime the login page is loaded. To fix this run the following commands in the Emilda directory:
touch .setup chmod 666 .setup
The next time you enter setup, the file should be updated correctly.