Library Circulation

[northstar1128]

Hi,

I am a very new FM user who's been elected to create a library circulation program to be used yesterday. Patience is not of virtue at the moment.

I have the general layout using some of the asset management from the FM webpage templates.

I am learning how to use with scripts/portals/containers. If anyone is able to help me it would be so appreciated. This is what I have going so far. And if it would be of help to send you what I have I can do that too. I'm computer literate, just not programming literate.

I have a check out check in page that I put in the Book number in, description, person's name ect. I have a calculation for 15 days check out and then in the Overdue field it say yes for overdue. One of the bigger problems is when I check it in it creates it as another record. If I have 6 books checked out, and I check one in, I want it to say 5 for the number of records. I would like it to archive the check out data. Whenever I check in a book I want it to go to that archive. That is just one of my many questions, but that is the major one at the moment. I am trying to get the check in check out, and overdue taken care of before I move on to the other things.

Sorry for the long explanation.

Hoping for help.

Thanks

Janet [color:"blue"]

[Fitch]

Seems to me that you should have Books in one file, and Circulation (or whatever you want to call it) in another. Each book should have a unique ID that is use to relate the files. Whenever a book goes in or out, you can set its status in the Books file, but also create a record in the Circ. file so you'll have the complete history there (e.g. date out, date due, date in, user id). Oh yeah, you should have a people file too!

[stardust]

This sounds like quite a project. I don't think you're going to find a quickie solution for the task at hand. It may be prudent to sit down and chart out all of the things you would like to accomplish for your solution.

I think you'll find that you will at least need the following databases:

-- book info (title, author, book id, description, in/out status, etc.)

-- patron info (name, id, etc.)

-- tracking (this will be your main interface)

A new record will be created every time someone check's out a book. When that book is checked back in, it will only update the original record (not delete it). I suggest using a radio button to toggle between a books in/out status.

So don't get hung up on the number of records you see. Generate reports to find out how many books are checked in/out at any given time, or books that are overdue -- whatever meets your needs.

Good luck!

[Jim McKee]

Janet ...

I like the tagline in stardust's (Maria's) signature: "What kind of a mess have I gotten myself into?"

You probably haven't gotten yourself into a mess yet, but you will definitely find yourself in a big one if you don't take Maria's advice to first carefully consider all of the functions you want the system to perform. Then begin to design (using the analog method of pencil and paper) how the various features will interact with one another, and what will be needed (files, fields, calculations, relationships, layouts, scripts) to implement the functionality you're aiming for. If you don't do this up-front, you could well find yourself having to tear apart whatever you build to fix the problems created by a not so well thought out design.

The file structure that stardust laid-out in her reply (Patrons, Books and Tracking) will get you started.

The "Patrons" file will contain Name, Address, Phone, etc. of the patron, and most-importantly, a unique code (best automatically assigned when the patron record is created) to identify them throughout the rest of the system. The coding algorithm you use should be based at a minimum on the criteria you can read about here (see the post by Live Oak).

The "Books" file would contain the Title, Author, ISBN number, etc. and also you need a way of designating multiple copies of the same title, so, your coding system would have to uniquely identify each book (not each "title"). There would also be a "Status" field to desginate the book as "In" or "Out", and maybe an extension of this field to include: "Lost", "Destroyed", "Out of circulation", etc.

The "Tracking" file, as Maria said, would have a new record created each time a book is checked out. That record will contain its own unique code (think of it as a "transaction" code), the Patron code, the Book code, the checkout date, the due date (Checkout date + 15 days), and a "Date Returned" field, which can serve double-duty as a way of calculating those dreaded overdue fines, but also a way of marking the book as "returned." From the "Tracking" file, you could easily set up some simple scripts so that when the book is checked out, the "Status" field in the Book's record gets set to "Out". When the book is returned, the "Status" field gets set to "In".

The solution you are trying to develop will require some basic relationships and scripting (but definitely not expert-level stuff), and this will be a great opportunity for you to begin to dig into Filemaker's features and to learn. But know that what you are trying to develop is NOT something that can be done "yesterday", especially if it's going to be done well. And, you can tell whoever is pressuring you to get this done "yesterday" that the experts on the Forum strongly advised against simply slapping together something that marginally works, but which will require more time and effort and aggravation in retro-fitting than if it had been done well at the start.

If you have more questions, ask away! That's why we're here.

[stanley]

Janet:

Jim's absolutely right about the structure and functionality of your library checkout system, but the most important point he makes is in his penultimate paragraph: this will take time to do correctly.

I was wondering if you (or rather, the people at the check out and return desks) will be typing all this data in when books are checked out/in, or if you will be using any kind of barcode or magnetic stripe system to automate most of the work, which is what you see in most libraries these days. Something to keep in mind, if the manual (typing) approach is to be used, is that FileMaker can deal with barcoding and mag stripes very easily, and if that migration ever needs to be taken, it mostly just comes down to rescripting the already in-place system.

Other than that, Jim has given you a pretty decent outline of what lies before you.

Good luck

-Stanley