Christoffer Landtman wrote:
David Everly wrote:
Thank you for the reply.
I have more questions, which I'll place here, and then responses
to your questions will be inserted to the threads below.
1. We have immediate need to begin entering our data. What is the
risk of
using 1.2alpha? Will later releases provide an upgrade path from
1.2alpha?
Hello, and sorry for the delayed answer,
The beauty of Emilda is that Emilda itself does not "destroy" data, i.e.
the data is preserved exactly in the way that it is imported, excluding
the parts that You have manually edited. Thus, it is fairly safe to even
use alpha versions for importing of data. It however is not a very good
idea to use alpha versions in environments with other than testing
users, as the interface might still break in some cases in an alpha
release.
2. I'm interested in how to do subject (repeating 653a)
management/searching from 1.1.0 also. Is there a way?
Management of subjects in the way Emilda 1.2alpha does it is not
possible as this was a feature of Emilda 1.2. It however is possible to
manage subjects in 1.1.0 in the same way that one manages e.g. titles
and authors, i.e. _one_ field where one can add subjects e.g. either
comma or space separated.
Searching is possible in the same way as in 1.2, using the instructions
in http://www.emilda.org/archives/emilda/2004-June/000054.html The
search logics has however still be verified as it was noticed below.
If You need more advice on the steps how to get a new field into the
editables, please send me a note, and I'll try to advice the best I can.
3. Within 1.1.0, how does one specify the location / type of item /
call number?
I entirely forgot. Item Type and Call number have been introduced in 1.2
so the management tools are not present in Emilda 1.1.0. The call number
could be managed in the sam manner as titles and authors, but this would
not give You the same management and control possibilities. Item types
cannot be used in Emilda 1.1.0 without code patches.
Regards,
Managing the existing location that You belong to You need to be an
Administrator (ADMIN priv). Then You go to Management->Location (in 1.2
this is Management->Configuration->Location) In either 1.1.0 or 1.2 it
is not possible to from within Emilda add a new location. A standalone
tool for this is in planning stage, and should be shipped with 1.2
stable. For now You have to add new locations using a MySQL client. This
can be done using the following command:
INSERT INTO locations SET
location_name="<some name>",
location_postal_address="<some address>",
location_postal_code="<some code>",
location_town="<some town>",
location_phone="<some num>",
location_fax="<some num>",
location_notes="<some notes>",
location_added="2004-06-12";
Then regarding the subjects search problem and the loan history issue.
First now when You raised the issue I realized that there was something
wrong in the search logics concerning the searching of subjects. The
search query "Handbells and Piano" is the logically correct one, as You
maybe also realized, but with the current setup, Zebra does not do the
thing that we tell it to do. It searches for a subject field containing
both "Handbells" and "Piano" which does of course not exist, as all
subjects are added in separate fields. Thus I will take this issue up
with the Indexdata people and see what would be the correct solution,
and post the result here then on the list.
Regarding the history issue,
We are now battling wether to generate some centralized logging system
or use component-wize loggings, such as You suggested. The issue has not
yet been solved but will most certainly be tackled to some extent by the
stable release of 1.2. I hope that You can bear waiting until then, so
that we can try to decide on which solution is the best.
The two different locations where it is indicated that an item is
loaned, in the borrowed table and the books table is mainly for sanity
purposes and also to reduce search and indexing times. This will however
probably also be revised by the time we have figured out which logging
solution to use.
Best regards,
On Fri, Jul 09, 2004 at 01:17:34PM +0300, Christoffer Landtman wrote:
David Everly wrote:
I have set up Emilda 1.2alpha and have followed the instructions at:
http://www.emilda.org/archives/emilda/2004-June/000054.html
It seems to work a bit. However, lets say for example that I have the
following subjects:
Handbells
Piano
SATB
I then assign Handbells and Piano to one Title1 and assign SATB and
Piano to Title2.
Now I want to search for all titles for Handbells and Piano.
Unfortunately, I don't know how to do this. When I try Advanced Search
and enter "Handbells and Piano", nothing shows. If I use "Handbells or
Piano", the results include Title2, which I am not interested in.
Hello,
I'm not entirely sure if I have understood your question totally
correct. Thus I would like to clarify the question itself before
trying to solve it. Please correct me if I'm wrong.
So You have the above subjects and You assign "Handbells" and "Piano"
to one item (what You called Title1) and "SATB" and "Piano" to an
other item (what You called Title2). Now You would like to search for
all items that have either of the subjects "Handbells" or "Piano",
which should return both "Title1" and "Title2".
This is mostly correct, except I would restate the last sentence as
follows:
I would like to search all items that have both "Handbells" and "Piano"
subjects, which should return only "Title1" from my example.
Regarding Your second mail,
Using the above reasoning I'm not quite sure what type of a report
You would like to see. Could You please maybe be more specific, so we
could try to tackle the issue.
For a specified borrower, I would like to see their last year's
borrowing history, sorted by date of item return. As a normal borrower,
I should be able to view my own history, but not the history of someone
else. As an administrator, I should be able to see both my history
and the history of others.
I briefly looked at some of the php/sql, and it appears that the
following line in return.php deletes any history upon item return:
sql_query("DELETE FROM borrowed WHERE borrowed_book_id=".$id);
Perhaps an approach of having a NULL date field which is populated with
the return date by return.php instead of deleting the row would be one
possible change to allow future reporting.
By the way, it seems that there is also the following suggestion. I've
also noticed the following in return.php:
sql_query("UPDATE books SET book_borrowed=0 where book_id=".$id);
Perhaps this is not needed, instead setting the logic to notice a
corresponding row in the borrowed table. Just a thought.
Emilda 1.2alpha does not contain all the logging functions which will
be implemented in the final release of 1.2 so there is a risk that
this is not yet present.
Hoping for a reply so that we could tackle Your question.
Regards,
--
Christoffer Landtman
Oy Realnode Ab
Partner, Sales
+358 (0)41 510 1073
landtman@xxxxxxxxxxx
www.realnode.fi
_______________________________________________
Emilda mailing list
Emilda@xxxxxxxxxxxxxxxxxx
http://lists.realnode.com/mailman/listinfo/emilda
------------------------------------------------------------------------
_______________________________________________
Emilda mailing list
Emilda@xxxxxxxxxxxxxxxxxx
http://lists.realnode.com/mailman/listinfo/emilda
--
Christoffer Landtman
Oy Realnode Ab
Partner, Sales
+358 (0)41 510 1073
landtman@xxxxxxxxxxx
www.realnode.fi
|
