Maximum PC

Okay, I first, I know close to nothing about macros, VB code, etc in MS Access. However, I want to create a database to manage a home library. I would like to have a search box that will search all the information (title, author, call number, etc.), and then return any records that have matching results. I am using Access 2010. My search box is currently called "txtSearch". I know it is possible, but I just do not know how. Can anybody help? THanks!

My answer depends on your answer to this simple question. Are you doing this as some kind of learning experience (ie you want to know how to design/implement a DB or something)?

If not, I would highly suggested using existing software, either commercial or open source. You might want to try freshmeat.net -- I usually have better look finding stuff there than anywhere else.

If so, I would like to add another node to the decision tree: Do you really need to use Access? Because I think that you're going to end up spending quite a bit of time only to realize that you can't do a whole lot with it.

Here are two things that you should do upfront:
1. Take a half hour to read about Prolog. I think that setting up your DB in Prolog will not only be easier, but actually provide you with a better overall system.

2. Make a requirements list. Imagine all the things you want the system to do... necessary, unnecessary, really nice features, etc. Then post the list here and someone will probably be able to help you out.

IMO. If all he wants is something to track his stuff at home. Access is probably the way to go. It is easy-ish to use unless you want to get stupid fancy (and for inventory, why bother getting fancy?).

Then again, this already exists and is probably cheaper both time wise and in money spent on books / learning.

http://quicken.intuit.com/personal-fina ... anager.jsp

It's not impossible but it is a little convoluted. VBA is a little, let's say, convoluted and kludgy. Your textbox has a .Text property you can access to find the keyword, if you have a button, then you'll need to attach a Click event to that button and run a query against a table (or tables, not sure what your schema looks like) then display the results.

Access isn't bad for small databases, especially ones for the home. However, as Crash said, ones you start using this in place of robust database systems...then you really should use a real system like Oracle or SQL Server.

One of the many things I hate about Access is how convoluted and kludgy VBA is.

IMO

Unless you are a real nerd, there is zero reason to be running Oracle or SQL ate home. SQL Express or SQL Lite maybe... SQL Compact is easier still, nothing to install.

The point is, that for managing your inventory Access is probably the right tool. I bet you could even download a DB that exists already. It is overkill to re-invent the wheel for something like this. Unless you intend to compete with software like in the example I posted above, and no single home user should be thinking about that.

Which I am. I use SQL Server at home. Not just SQL Server Express either, I'm talking full blow SQL Server Enterprise (thank you MSDN). It's more for training/practice, I try to keep a full blown environment for me to putz around with.



Yeah, that and for some stuff, a piece of paper does just fine.

Again, I think the choice depends mostly on whether this is a learning project for him, and what is really most important to him. If he actually want to learn how to create a schema, populate a database, write queries, etc., then an Access database may or may not be the best solution. The few times that I've had to work with Access, I found the whole process to be rather kludgey, limiting and backasswards... so let's find out what he wants to do, then go from there.

Personally, I might do a similar project for my library of books, and maybe, movies/videos in the future, but I'd be somewhat more inclined to create a knowledge base rather than a database.

Thanks for all the replies. I am not learning how to do it -- I want an actual database to manage my books. Obviously, there's no way I am going to be able to run some kind of database system at home. (I'm using a laptop.) I just don't have that much time.



What do you mean by knowledge base?

It looks like there are a couple of projects on freshmeat that do book management. You might also want to consider using a spreadsheet for the time being, or at least until you have a better idea of the features that you want implemented. Actually, we've sort of been using the term "database" loosely. It is common in industry to use the term "database" when you really mean "RDBMS", but anything that stores "structured data" is a database, so technically, a spreadsheet would be considered a database and is probably the easiest method for solving your problem.


A KB is one method for performing "knowledge representation"; You can find quite a bit of material on KBs in the AI literature. There's a Google Tech on Cyc which is probably the most important KB in existence. I found it to be interesting. Perhaps the most significant difference between a KB and DBMS is that a KB is generally based upon logic (propositional, 1st order, 2nd order, etc), whereas a RDBMS is based on relational algebra.

What does that mean in practice? A KB can perform logical deduction. If I've added rules to the database that mammals are a type of animal, dogs are a type of mammal, and "scruffy" is a dog, then the KB can infer that scruffy is both an animal and mammal w/o having to be explicitly be told about the relationship. With a DBMS, you'd have to create tables/columns, insert each of the relationships, then write an explicit query to accomplish the same task. I did a couple of projects with a KB at USC and was always amazed by how little work the KB required compared to a DB (and somewhat ironically, I was working for the "database group" at Boeing during this period of time). I hadn't really thought of it before now, but a KB is probably a good way to prototype a production database.

The other major difference is the language syntax. While SQL is dead simple for the most basic of queries, I constantly find myself googling "SQL incantations". This is probably just a personal taste issue, but I really haven't used another language which required me to spend as much time looking up syntax for such trivial things. A language like Prolog seems much more natural to me.