I'm in the process of converting our library from DBText to koha 3.00 RC1 and have a couple of questions about the fields in the patron record. I see address, city and zipcode for the addresses, but no state or country fields. Being in south Florida, we do get a number of Canadians. I'm also curious about why street number and street type are separate fields. We also have a number of flags like 'mailing list' (which indicates whether or not the patron wants to get general mailings) which don't map to anything in the patron record. What format should the dates have? I don't have a sex or date-of-birth field (I'll probably use 1/1/1969 for date of birth which will make everyone 39 years old. They're all adults.) I see that the branch and category codes must be valid for importing patrons. Are there any other fields that are required or checked. I guess that cardnumber, zipcode and surname are required. Thanks for any suggestions. -- Bob
I want to point you to the working manual: http://sites.google.com/a/liblime.com/koha-manual/ I don't know how to answer all of your questions, but as for the street type - this is because there is an authorized value you can assign to that to make it easier for people to add patrons. As for missing fields, you can set up your own custom fields by going to the patron attribute types: http://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/adm... --- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ On Tue, Jul 22, 2008 at 11:29 AM, Bob Ewart <bob-ewart@earthlink.net> wrote:
I'm in the process of converting our library from DBText to koha 3.00 RC1 and have a couple of questions about the fields in the patron record.
I see address, city and zipcode for the addresses, but no state or country fields. Being in south Florida, we do get a number of Canadians.
I'm also curious about why street number and street type are separate fields.
We also have a number of flags like 'mailing list' (which indicates whether or not the patron wants to get general mailings) which don't map to anything in the patron record.
What format should the dates have? I don't have a sex or date-of-birth field (I'll probably use 1/1/1969 for date of birth which will make everyone 39 years old. They're all adults.)
I see that the branch and category codes must be valid for importing patrons. Are there any other fields that are required or checked. I guess that cardnumber, zipcode and surname are required.
Thanks for any suggestions.
-- Bob
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Bob - The borrowers table contains all the fields you're looking for, I think, with perhaps the exception of country. That shouldn't be a major limitation, if you record the Canadian's state as something recognizeable like "Ontario". Here are the table fields. mysql> describe borrowers; +---------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+--------------+------+-----+---------+----------------+ | borrowernumber | int(11) | NO | PRI | NULL | auto_increment | | cardnumber | varchar(16) | YES | UNI | NULL | | | surname | mediumtext | NO | | | | | firstname | text | YES | | NULL | | | title | mediumtext | YES | | NULL | | | othernames | mediumtext | YES | | NULL | | | initials | text | YES | | NULL | | | streetnumber | varchar(10) | YES | | NULL | | | streettype | varchar(50) | YES | | NULL | | | address | mediumtext | NO | | | | | address2 | text | YES | | NULL | | | city | mediumtext | NO | | | | | zipcode | varchar(25) | YES | | NULL | | | email | mediumtext | YES | | NULL | | | phone | text | YES | | NULL | | | mobile | varchar(50) | YES | | NULL | | | fax | mediumtext | YES | | NULL | | | emailpro | text | YES | | NULL | | | phonepro | text | YES | | NULL | | | B_streetnumber | varchar(10) | YES | | NULL | | | B_streettype | varchar(50) | YES | | NULL | | | B_address | varchar(100) | YES | | NULL | | | B_city | mediumtext | YES | | NULL | | | B_zipcode | varchar(25) | YES | | NULL | | | B_email | text | YES | | NULL | | | B_phone | mediumtext | YES | | NULL | | | dateofbirth | date | YES | | NULL | | | branchcode | varchar(10) | NO | MUL | | | | categorycode | varchar(10) | NO | MUL | | | | dateenrolled | date | YES | | NULL | | | dateexpiry | date | YES | | NULL | | | gonenoaddress | tinyint(1) | YES | | NULL | | | lost | tinyint(1) | YES | | NULL | | | debarred | tinyint(1) | YES | | NULL | | | contactname | mediumtext | YES | | NULL | | | contactfirstname | text | YES | | NULL | | | contacttitle | text | YES | | NULL | | | guarantorid | int(11) | YES | | NULL | | | borrowernotes | mediumtext | YES | | NULL | | | relationship | varchar(100) | YES | | NULL | | | ethnicity | varchar(50) | YES | | NULL | | | ethnotes | varchar(255) | YES | | NULL | | | sex | varchar(1) | YES | | NULL | | | password | varchar(30) | YES | | NULL | | | flags | int(11) | YES | | NULL | | | userid | varchar(30) | YES | MUL | NULL | | | opacnote | mediumtext | YES | | NULL | | | contactnote | varchar(255) | YES | | NULL | | | sort1 | varchar(80) | YES | | NULL | | | sort2 | varchar(80) | YES | | NULL | | | altcontactfirstname | varchar(255) | YES | | NULL | | | altcontactsurname | varchar(255) | YES | | NULL | | | altcontactaddress1 | varchar(255) | YES | | NULL | | | altcontactaddress2 | varchar(255) | YES | | NULL | | | altcontactaddress3 | varchar(255) | YES | | NULL | | | altcontactzipcode | varchar(50) | YES | | NULL | | | altcontactphone | varchar(50) | YES | | NULL | | | smsalertnumber | varchar(50) | YES | | NULL | | +---------------------+--------------+------+-----+---------+----------------+ 58 rows in set (0.00 sec) The fields with NULL=NO are requried. Any additional fields that you cannot easily map yet, I suggest you incorporate into the "contactnote" or "opacnote" fields, using some consistent mechanical format (e.g., "message_flag=y, other_flag=3"). Then later you can still extract that info for use in an extended attribute, custom report, etc. All Koha's date fields are represented internally as ISO format dates (YYYY-MM-DD). --Joe Atzberger Systems Administrator, LibLime On Tue, Jul 22, 2008 at 11:34 AM, Nicole Engard <nicole.engard@liblime.com>wrote:
I want to point you to the working manual: http://sites.google.com/a/liblime.com/koha-manual/
I don't know how to answer all of your questions, but as for the street type - this is because there is an authorized value you can assign to that to make it easier for people to add patrons.
As for missing fields, you can set up your own custom fields by going to the patron attribute types: http://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/adm...
---
Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard
http://liblime.com http://blogs.liblime.com/open-sesame/
On Tue, Jul 22, 2008 at 11:29 AM, Bob Ewart <bob-ewart@earthlink.net> wrote:
I'm in the process of converting our library from DBText to koha 3.00 RC1 and have a couple of questions about the fields in the patron record.
I see address, city and zipcode for the addresses, but no state or country fields. Being in south Florida, we do get a number of Canadians.
I'm also curious about why street number and street type are separate fields.
We also have a number of flags like 'mailing list' (which indicates whether or not the patron wants to get general mailings) which don't map to anything in the patron record.
What format should the dates have? I don't have a sex or date-of-birth field (I'll probably use 1/1/1969 for date of birth which will make everyone 39 years old. They're all adults.)
I see that the branch and category codes must be valid for importing patrons. Are there any other fields that are required or checked. I guess that cardnumber, zipcode and surname are required.
Thanks for any suggestions. -- Bob
Hi Joe and Nicole, Thanks for your quick responses. They will make this part of the conversion easy. Joe, where do you record the state? The fun part of the conversion is going to be the catalog. Joe Atzberger wrote:
Bob -
The borrowers table contains all the fields you're looking for, I think, with perhaps the exception of country. That shouldn't be a major limitation, if you record the Canadian's state as something recognizeable like "Ontario".
Here are the table fields.
mysql> describe borrowers; +---------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+--------------+------+-----+---------+----------------+ | borrowernumber | int(11) | NO | PRI | NULL | auto_increment | | cardnumber | varchar(16) | YES | UNI | NULL | | | surname | mediumtext | NO | | | | | firstname | text | YES | | NULL | | | title | mediumtext | YES | | NULL | | | othernames | mediumtext | YES | | NULL | | | initials | text | YES | | NULL | | | streetnumber | varchar(10) | YES | | NULL | | | streettype | varchar(50) | YES | | NULL | | | address | mediumtext | NO | | | | | address2 | text | YES | | NULL | | | city | mediumtext | NO | | | | | zipcode | varchar(25) | YES | | NULL | | | email | mediumtext | YES | | NULL | | | phone | text | YES | | NULL | | | mobile | varchar(50) | YES | | NULL | | | fax | mediumtext | YES | | NULL | | | emailpro | text | YES | | NULL | | | phonepro | text | YES | | NULL | | | B_streetnumber | varchar(10) | YES | | NULL | | | B_streettype | varchar(50) | YES | | NULL | | | B_address | varchar(100) | YES | | NULL | | | B_city | mediumtext | YES | | NULL | | | B_zipcode | varchar(25) | YES | | NULL | | | B_email | text | YES | | NULL | | | B_phone | mediumtext | YES | | NULL | | | dateofbirth | date | YES | | NULL | | | branchcode | varchar(10) | NO | MUL | | | | categorycode | varchar(10) | NO | MUL | | | | dateenrolled | date | YES | | NULL | | | dateexpiry | date | YES | | NULL | | | gonenoaddress | tinyint(1) | YES | | NULL | | | lost | tinyint(1) | YES | | NULL | | | debarred | tinyint(1) | YES | | NULL | | | contactname | mediumtext | YES | | NULL | | | contactfirstname | text | YES | | NULL | | | contacttitle | text | YES | | NULL | | | guarantorid | int(11) | YES | | NULL | | | borrowernotes | mediumtext | YES | | NULL | | | relationship | varchar(100) | YES | | NULL | | | ethnicity | varchar(50) | YES | | NULL | | | ethnotes | varchar(255) | YES | | NULL | | | sex | varchar(1) | YES | | NULL | | | password | varchar(30) | YES | | NULL | | | flags | int(11) | YES | | NULL | | | userid | varchar(30) | YES | MUL | NULL | | | opacnote | mediumtext | YES | | NULL | | | contactnote | varchar(255) | YES | | NULL | | | sort1 | varchar(80) | YES | | NULL | | | sort2 | varchar(80) | YES | | NULL | | | altcontactfirstname | varchar(255) | YES | | NULL | | | altcontactsurname | varchar(255) | YES | | NULL | | | altcontactaddress1 | varchar(255) | YES | | NULL | | | altcontactaddress2 | varchar(255) | YES | | NULL | | | altcontactaddress3 | varchar(255) | YES | | NULL | | | altcontactzipcode | varchar(50) | YES | | NULL | | | altcontactphone | varchar(50) | YES | | NULL | | | smsalertnumber | varchar(50) | YES | | NULL | | +---------------------+--------------+------+-----+---------+----------------+ 58 rows in set (0.00 sec)
The fields with NULL=NO are requried. Any additional fields that you cannot easily map yet, I suggest you incorporate into the "contactnote" or "opacnote" fields, using some consistent mechanical format (e.g., "message_flag=y, other_flag=3"). Then later you can still extract that info for use in an extended attribute, custom report, etc.
All Koha's date fields are represented internally as ISO format dates (YYYY-MM-DD).
--Joe Atzberger Systems Administrator, LibLime
On Tue, Jul 22, 2008 at 11:34 AM, Nicole Engard <nicole.engard@liblime.com <mailto:nicole.engard@liblime.com>> wrote:
I want to point you to the working manual: http://sites.google.com/a/liblime.com/koha-manual/
I don't know how to answer all of your questions, but as for the street type - this is because there is an authorized value you can assign to that to make it easier for people to add patrons.
As for missing fields, you can set up your own custom fields by going to the patron attribute types: http://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/adm...
---
Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com <mailto:nce@liblime.com> AIM/Y!/Skype: nengard
http://liblime.com http://blogs.liblime.com/open-sesame/
On Tue, Jul 22, 2008 at 11:29 AM, Bob Ewart <bob-ewart@earthlink.net <mailto:bob-ewart@earthlink.net>> wrote:
I'm in the process of converting our library from DBText to koha 3.00 RC1 and have a couple of questions about the fields in the patron record.
I see address, city and zipcode for the addresses, but no state or country fields. Being in south Florida, we do get a number of Canadians.
I'm also curious about why street number and street type are separate fields.
We also have a number of flags like 'mailing list' (which indicates whether or not the patron wants to get general mailings) which don't map to anything in the patron record.
What format should the dates have? I don't have a sex or date-of-birth field (I'll probably use 1/1/1969 for date of birth which will make everyone 39 years old. They're all adults.)
I see that the branch and category codes must be valid for importing patrons. Are there any other fields that are required or checked. I guess that cardnumber, zipcode and surname are required.
Thanks for any suggestions. -- Bob
-- Bob
Bob -- It looks like state doesn't get a separate field, it is just a part of city. So, in my test database, for example: mysql> select DISTINCT city from borrowers WHERE city IS NOT NULL LIMIT 3,5; +----------------------+ | city | +----------------------+ | Portland, OR | | Santa Cruz, CA | | Mayfield Heights, OH | | Athens, OH | | Atwater, OH | +----------------------+ 5 rows in set (0.01 sec) Other more reliable sorting and batching can still be achieved with zip codes, if you wanted to do something like targeted mailing. --joe On Tue, Jul 22, 2008 at 1:02 PM, Bob Ewart <bob-ewart@earthlink.net> wrote:
Hi Joe and Nicole,
Thanks for your quick responses.
They will make this part of the conversion easy.
Joe, where do you record the state?
The fun part of the conversion is going to be the catalog.
Joe Atzberger wrote:
Bob -
The borrowers table contains all the fields you're looking for, I think, with perhaps the exception of country. That shouldn't be a major limitation, if you record the Canadian's state as something recognizeable like "Ontario".
Here are the table fields.
mysql> describe borrowers;
+---------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------+--------------+------+-----+---------+----------------+
| borrowernumber | int(11) | NO | PRI | NULL | auto_increment | | cardnumber | varchar(16) | YES | UNI | NULL | | | surname | mediumtext | NO | | | | | firstname | text | YES | | NULL | | | title | mediumtext | YES | | NULL | | | othernames | mediumtext | YES | | NULL | | | initials | text | YES | | NULL | | | streetnumber | varchar(10) | YES | | NULL | | | streettype | varchar(50) | YES | | NULL | | | address | mediumtext | NO | | | | | address2 | text | YES | | NULL | | | city | mediumtext | NO | | | | | zipcode | varchar(25) | YES | | NULL | | | email | mediumtext | YES | | NULL | | | phone | text | YES | | NULL | | | mobile | varchar(50) | YES | | NULL | | | fax | mediumtext | YES | | NULL | | | emailpro | text | YES | | NULL | | | phonepro | text | YES | | NULL | | | B_streetnumber | varchar(10) | YES | | NULL | | | B_streettype | varchar(50) | YES | | NULL | | | B_address | varchar(100) | YES | | NULL | | | B_city | mediumtext | YES | | NULL | | | B_zipcode | varchar(25) | YES | | NULL | | | B_email | text | YES | | NULL | | | B_phone | mediumtext | YES | | NULL | | | dateofbirth | date | YES | | NULL | | | branchcode | varchar(10) | NO | MUL | | | | categorycode | varchar(10) | NO | MUL | | | | dateenrolled | date | YES | | NULL | | | dateexpiry | date | YES | | NULL | | | gonenoaddress | tinyint(1) | YES | | NULL | | | lost | tinyint(1) | YES | | NULL | | | debarred | tinyint(1) | YES | | NULL | | | contactname | mediumtext | YES | | NULL | | | contactfirstname | text | YES | | NULL | | | contacttitle | text | YES | | NULL | | | guarantorid | int(11) | YES | | NULL | | | borrowernotes | mediumtext | YES | | NULL | | | relationship | varchar(100) | YES | | NULL | | | ethnicity | varchar(50) | YES | | NULL | | | ethnotes | varchar(255) | YES | | NULL | | | sex | varchar(1) | YES | | NULL | | | password | varchar(30) | YES | | NULL | | | flags | int(11) | YES | | NULL | | | userid | varchar(30) | YES | MUL | NULL | | | opacnote | mediumtext | YES | | NULL | | | contactnote | varchar(255) | YES | | NULL | | | sort1 | varchar(80) | YES | | NULL | | | sort2 | varchar(80) | YES | | NULL | | | altcontactfirstname | varchar(255) | YES | | NULL | | | altcontactsurname | varchar(255) | YES | | NULL | | | altcontactaddress1 | varchar(255) | YES | | NULL | | | altcontactaddress2 | varchar(255) | YES | | NULL | | | altcontactaddress3 | varchar(255) | YES | | NULL | | | altcontactzipcode | varchar(50) | YES | | NULL | | | altcontactphone | varchar(50) | YES | | NULL | | | smsalertnumber | varchar(50) | YES | | NULL | |
+---------------------+--------------+------+-----+---------+----------------+
58 rows in set (0.00 sec)
The fields with NULL=NO are requried. Any additional fields that you cannot easily map yet, I suggest you incorporate into the "contactnote" or "opacnote" fields, using some consistent mechanical format (e.g., "message_flag=y, other_flag=3"). Then later you can still extract that info for use in an extended attribute, custom report, etc.
All Koha's date fields are represented internally as ISO format dates (YYYY-MM-DD).
--Joe Atzberger Systems Administrator, LibLime
On Tue, Jul 22, 2008 at 11:34 AM, Nicole Engard <nicole.engard@liblime.com <mailto:nicole.engard@liblime.com>> wrote:
I want to point you to the working manual: http://sites.google.com/a/liblime.com/koha-manual/
I don't know how to answer all of your questions, but as for the street type - this is because there is an authorized value you can assign to that to make it easier for people to add patrons.
As for missing fields, you can set up your own custom fields by going to the patron attribute types:
http://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/adm...
---
Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com <mailto:nce@liblime.com> AIM/Y!/Skype: nengard
http://liblime.com http://blogs.liblime.com/open-sesame/
On Tue, Jul 22, 2008 at 11:29 AM, Bob Ewart <bob-ewart@earthlink.net <mailto:bob-ewart@earthlink.net>> wrote:
I'm in the process of converting our library from DBText to koha 3.00 RC1 and have a couple of questions about the fields in the patron record.
I see address, city and zipcode for the addresses, but no state
or
country fields. Being in south Florida, we do get a number of Canadians.
I'm also curious about why street number and street type are separate fields.
We also have a number of flags like 'mailing list' (which
indicates
whether or not the patron wants to get general mailings) which don't map to anything in the patron record.
What format should the dates have? I don't have a sex or date-of-birth field (I'll probably use 1/1/1969 for date of birth which will
make
everyone 39 years old. They're all adults.)
I see that the branch and category codes must be valid for
importing
patrons. Are there any other fields that are required or checked. I guess that cardnumber, zipcode and surname are required.
Thanks for any suggestions. -- Bob
-- Bob
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (3)
-
Bob Ewart -
Joe Atzberger -
Nicole Engard