using access for the back end

[unluckyuser]

I've got several Excel programs that are forms based, no data stored in them. The application is for a patient unit, where I have maybe 100 people. I need to be able to connect to it and quickly get data fields to the spreadsheet, maybe change a field or two and send that back to the database. I need to be able to move, add and delete within the database. This needs to happen quickly with multiple users. Will this be practical with Excel for the front end?

 

[Micron]

I would say no. Excel data is 'wide' (arranged in rows over columns). Access data should be 'tall' (arranged in rows). Related data is kept in additional tables, not columns (in Access those are called fields).

I need to be able to move, add and delete within the database.

If by database you mean Access, then the smart thing to do would be to do all your data editing in Access. It makes no sense to me to be moving data around to do anything to it. Likely Access can do whatever it is you need it to do (except IMO Access charts are sorely lacking in features). Besides, Excel doesn't play well with multiple concurrent user scenarios, and on a scale of 1 to 10, it's security is pretty much zero, not one. Not the app I'd use for private medical information. Access security can be made to be about 7 or 8 on that scale but it takes a bit of work. I'm talking about very smart hackers, not your casual user. Then there's the fact that if done properly, Access does well in a multi user environment and has a fairly robust reporting capability. The downside is that Access has a steep learning curve if you're going to do a good job with any project. What is of utmost importance is to understand normalization before getting down to designing a first gen database.

 

[CPGDeveloper]

I agree with Micron -- Excel is a terrible tool for actually storing data. Access is your best bet here I would think.