A segue from Cary's post.......as an Alma library, we have done quite a
bit of work with the REST patron/user API. It is pretty straight forward
and will allow you to grab everything you need to print out library
cards. Send me an email off-list and we can discuss.
Joseph M. Shubitowski
Head, Information Systems
Getty Research Institute
1200 Getty Center Drive, Suite 1100
Los Angeles CA 90049-1688
[log in to unmask]
>>> Cary Gordon <[log in to unmask]> 9/29/2014 3:24 PM >>>
Your best bet, IMHO, would be to write an app that pulls the info,
formats it and sends it to the printer. The Datacard software would not
likely be a good candidate for modification.
You might want to contact Datacard, but I don't think that you will get
very far. They make and sell printers. The software you have is a
sideline and not very well supported.
The other option would be to contact ExLibris and see what they can do
for you. Some of the other Alma libraries my have solved this.
Of course, if they haven't, and you create an open-source app to
connect printer and ILS, you will win the good karma award.
On Sep 29, 2014, at 12:58 PM, Fitchett, Deborah
<[log in to unmask]> wrote:
> Hi all,
> Apologies, have got distracted from mailing lists and missed these
replies last week...
> The existing app is called Datacard and I know very little about it -
installed before my time by another department, etc. But basically it
prints our library cards, so it needs the appropriate user data (name,
barcode, other ID details). Previously it pulled these from PeopleSoft
over ODBC, but with our migration things are different and decisions
were made so now for a class of users the data is only available in
> A nightly extract of data to a Koha (or other) install wouldn't work
because we're needing the data at the point of sign-up to the library so
the card can be printed.
> It sounds very much like it comes down to seeing if there's an
upgrade to Datacard we can write a business case for and in the meantime
continue to type or copy/paste the data by hand at point of need. Not
the ideal situation but at least it's a relatively small class of users
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf
Of Cary Gordon
> Sent: Wednesday, 24 September 2014 3:59 a.m.
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] REST vs ODBC
> Could you reveal anything about what the existing application (EA) is
and what it does?
> We don't know what the EA was connected to, so there can't know if
Koha would work as middleware. It might be simpler to write your own
middleware in Symfony (I have grown fond of Guzzle), or some other
framework and just pull the data into a database that has the same
structure as your old system.
> On Mon, Sep 22, 2014 at 3:01 PM, Fitchett, Deborah <
[log in to unmask]> wrote:
>> Morning, all,
>> We have a small dilemma:
>> 1. Our brand new Alma system provides access to a bunch of data
>> RESTful API. It’s on The Cloud so we’re not going to be getting
>> access to the database anytime soon.
>> 2. We have an existing application that would be more efficient
>> it could get that data, but which only uses ODBC. (I’m told other
>> available drivers are:
>> - Microsoft Jet 4.0 OLE
>> - Microsoft Office
>> - Microsoft OLE DB Provider
>> - Microsoft Datashape
>> - OLE DB Provider
>> - SQL Server Native Client 10.0)
>> Does anyone know if there’s any middleware out there that could make
>> these two things talk to each other, or do we give this up as a
>> have been nice, but <shrug>”?
>> Nāku noa, nā
>> Deborah Fitchett
>> Senior Advisor, Digital Access
>> Library, Teaching and Learning
>> p +64 3 423 0358
[log in to unmask]<mailto:[log in to unmask]>
>> | w library.lincoln.ac.nz<http://library.lincoln.ac.nz/>
>> Lincoln University, Te Whare Wānaka o Aoraki New Zealand's
>> land-based university
>> P Please consider the environment before you print this email.
>> "The contents of this e-mail (including any attachments) may be
>> confidential and/or subject to copyright. Any unauthorised use,
>> distribution, or copying of the contents is expressly prohibited. If
>> you have received this e-mail in error, please advise the sender by
>> return e-mail or telephone and then delete this e-mail together with
>> all attachments from your system."
> Cary Gordon
> The Cherry Hill Company