Welcome to the fraternity. Having worked for non-profits, I can sympathize with the restraints you're facing.
Most of the RDMS software programs that have been around for a while are good solid development platforms.
Choose something that will let you start small and upsize to Oracle or SQL at a later time. The bean-counters won't let you spend big bucks for anything until you can demonstrate something that shows some promise of working.
Another thing to consider is the long-term viability of the solution you choose. Non-profits work on an entirely different time frame than other businesses. IT resources get stretched way beyond their normal life in non-profits. Pick something common enough that three or four generations of Windows workstations will be able to operate your solution and something that you or your replacement will recognize it in five or six years.
Will the support resources be there for you or your replacement in three years? How about five or even ten years? Are there ODBC or other connection options that will still be available at that time? Will the company be gobbled up by a competitor and the software left to wither and die? Does it use a common or proprietary file structure? Let history be your guide. If the company has been around for a long time, odds are they will be around longer than someone who started making RDMS software last month.
We each have our favorite development platform, but the database concepts are the same no matter which program you use to build and deploy your solution.
If possible, download a trial version of each of the possible candidates - Access, Alpha5, FilePro, Foxpro and any of the open source apps that may look promising. Repeat your classroom work in each of the candidates. That will give you a feel for how they differ. Some are geared to the hard-core code warrior. Others are more intuitive and give you lots of prepackaged widgets that you assemble into a wokable solution.
Since you're just getting started, it's tempting to jump in and start building something right away, but you'll find the more time you spend on design, the less time you'll spend reworking because of poor initial planning. If you've done the right prep work, the actual programming is easy - no matter what application you're working with.
In your case, I think Access has a lot of advantages:
1. It's ubiquitous. It's included on almost every workstation that has MSOffice. If your workstations have it now, they'll have it in five, seven or ten years in some version. If they don't have it, non-profits can get it at a discount ( check out
http://www.techsoup.org ).
2. Support. There a hundreds of books, classes, websites like this and the behemoth in Redmond, WA to help you work through anything that can (and will) go wrong in Access. See point #1.
3. Access will let you "upsize" to SQL when your database is ready for deployment across the enterprise. There are lots of intermediate steps you can use before you're at that stage. There's the single monolithic file stage that lets you develop the business rules and the look and feel of the database. If your comfortable with macros, you can stick with them. When you're ready to work with code, Visual Basic for Applications will get you started. After that, you can separate it into a Front End / Back End solution that will give you a feel for networked applications without commiting to an expensive database solution. If your network continues using Microsoft Small Business Server as its main platform, the e-mail and SQL database options are included in some versions.
4. Familiarity. Despite the feature bloat that Microsoft is known for, if you were to pick up the manual for any older version of Access, you could use it to work in the latest version. Tables, Queries, Forms, Macros and Modules - Access has worked like that since I was in school ( I won't actually say how long ago that was ). It's the Relation Database that everyone under 35 learned on. Microsoft didn't make billions by accident, they know how to develop and maintain a customer base.
5. Transferability. When you finally get that big promotion, or sell out and move into that corporate office downtown, the programmer who replaces you will be able to figure out what you built and how it does what it does. Of course, you'll provide all the necessary documentation, because you kept all your prep work and sprinkled remarks throughout your code explaining the processes.
I'm sure everyone else will jump in to tout their favorites. I've worked with a lot of the older programs and they're all good platforms. I can't speak for the newer ones and I'm still wary of open source software - I don't like being anyone's guinea pig, but that's just me.
Sorry to be so long-winded - four years of business school can leak out of my brain at any time when I'm not looking.