well not Excel clearly , especially as this is a database forum, not a spreadsheet fourm
depends on your experience, your budget your aspirations
login system, yeah can do that or can use the windows networking logon
multiple queries, add delete data (so called CRUD), yeah can do that
on the face of it quite a trivial application, especially if there are around 2,000 rows
the tricky part is what is the right way of doing this.
if your users already have access to Access that would be a contender in my books
Access has a database built in but can also talk to virtually any other data storage mechanism out there. if your users dont' have Access then I doubt its worth spending the cash to install Access, nor do I think from what you are saying you have the expertese to deploy an Access application using the freely available runtime (alothough you may)
There's various types of data storage you can use (eg Apple's vile Filemaker a competitor to Access, there's Open Office's database product which will probably do the job). those all come with a front end (the user interface) and a data storage mechanism. like SQLite these are file sharing systems which are fine for small applications (say upto 15..30 users) using their native datastorage mechanism.
You can use other storage mechanisms such as Client Server databases such as SQL server, MySQL, Psotgres, DB2 and so on which can get very expensive, and for what you are trying to do will almost certainly be overkill.
the problem is the user interface (ie how you shield the user from the details of the database but at the same time allow the user to do what you want when they want.
If you are constrained by budget then a web scripting system could be a good approach, using soemthing like PHP, Ruby, Ruby on Rails Python or whatever. the security implications of web servers shoudl be less if the systrem is deployed only to known users on a local intranet. however such scripting langauges are not great at generating reports, great for screens, not so great for paper
the main problems are going to be
1) getting your data model sorted out, if the datamodel is right then usually accessign the data is straightforward, get it wrong and its a right PITA
2) creating the user interface. Access is striaghtforward to create forms & reports (especially reports) but its all to easy to create soemthign in Access whihc is a PITA to maintain over time
if it were me I'd use Access, to keep costs down I'd have one copy of Access and use the runtime to deploy the finished app. but whether thats right for you I dunno as it depends on your skills, knowledge and enthusiasm to learn. irrespective of waht you do choose you need to get to grips with physical design (that mean table / column design). look up normalisation
Fundamentals of Relational Database Design -- r937.com
or The Relational Data Model, Normalisation and effective Database Design are good starting points
then you need to egt to grips with your chosen front end interface
I'd rather be riding on the Tiger 800 or the Norton