Is Access2000 suitable for this?
Hi, just want to get some opinions and ideas for a project I will be starting.
The system is for a multiuser environment (max 5 persons) and it is a simple invoicing and reporting system.
I will be using VB6 for the front end so that is no problem. But for the backend I am thinking of using Access2000 (Okay, thats the only db I have experienced in besides Ms SQL7 which I have messed around a bit). But my client can't afford MS SQL due to budget constraints.
Just wondering, what are the pros and cons if I use Access from your own experience for a system like this?
suhu
Thursday, April 8, 2004
Sorry hit the Submit button too soon. I know some of you might recommend MSDE but I don't have any experience with it at all.
And I am not sure I will have the time to learn it before starting on the project. So unless Access2000 is really not suitable for the above system, I will have no choice but to look for alternative databases.
Thanks in advance.
suhu
Thursday, April 8, 2004
We use access97 in the same sort of situation. We have a 25user environment, the program is used to keep track of client 'work in progress'.
It works quite fine. (although this really consitutes a limited opinion)
Aussie Chick
Thursday, April 8, 2004
It'll be fine, assuming your volumes are reasonably low. How many invoices/month do they print? (Most businesses tend to do these all at once).
If the tool is fit for purpose (which it is, in my opinion, given the limited details), I would be inclined towards using it over another, superior tool that you have no experience with - otherwise, this is a major project risk.
Oh and make sure you *really* understand their invoicing process and what they expect from the system.
Justin
Thursday, April 8, 2004
Thanks for the feedback so far.
Regarding the number of invoices, it is around 30 perday.
Will the db be able to handle around 5 users at once? I have heard that access can get corrupted and stuff.
suhu
Thursday, April 8, 2004
Access/Jet db's can get corrupted, but if it's going to happen in your intended 5-user setup it would probably be because a client computer crashed or was turned off by the user without shutting down, not some unpredictable error. Jet/Access clients are usually designed to each keep the db file open, which causes problems when one of the clients crashes.
Regarding an invoicing app, you might want to consider making some changes to the Access sample Northwinds application. I've seen small businesses use slightly modified versions with good success.
Herbert Sitz
Thursday, April 8, 2004
What I can't udnerstand is this statement...
---"I will be using VB6 for the front end"----
Coding the front end in Access is two or three times quicker than doing it in VB. Why take the weakest point of Access (the .mdb back end) and not use the strongest (the IDE).?
I'd consider writing it as an Access project using MSDE. This will make it easier to upgrade at a later date. If you are really pushed for time you could do an .mdb now, and change it to an MSDE later -- there is a button for doing this automatically but we all know what happens when you go around pressing strange buttons :)
Stephen Jones
Thursday, April 8, 2004
Excellent point, Stephen.
Unless the app is intended for shrinkwrap delivery, Access offers a significantly faster dev environment -- not having to deal with DB connections, better data-integrated controls, and so on. If it's a departmental or internal app, Access will let you spend more time working on actual features and less time on the mechanics.
By the way, I've had good luck using Kixtart to ensure that users always have the latest version of the front end copied down to their machines. Email me for a sample script I put together recently.
Also, I wouldn't recommend MSDE for anything but an internal application -- I had enough installation support requests when I tried making an Access app publicly available without the configuration issues of having to have one computer always on. If you can physically manage the MSDE workstation (esp. working out a backup scheme), it's a good way to go, but don't try doing it over the phone; you'll lose all the time you saved by doing your front end in Access, and then some. ;>
Sam Livingston-Gray
Thursday, April 8, 2004
I just ported an internal Access application to web-based php/mysql because, among other things, the Access app had major record-locking and corruption problems. It was a basic customer contact tracking system with about 15 users, 7 tables, 60,000+ contact records, and about 150 new contacts per day. it just couldn't handle the "load", although I think a lot of that was due to the design my boss created. she's an idiot.
bob
Thursday, April 8, 2004
Look, if you know SQL Server then you know MSDE. It's exactly SQL Server.
Five users and you may be fine with MS Access depending on the usage. I'd spend a couple of hours with MSDE and see if you can figure it out.
pdq
Thursday, April 8, 2004
And of course, if you only sort-of know SQL Server, then...
Go with Access, since you know it, and look at porting it to MSDE later. This could be good practice in seeing whether your data access strategy allows you to port easily.
Kyralessa
Thursday, April 8, 2004
Thanks for all the feedbacks. I will look at MSDE like some of you suggested. And depending on time constraints I will try to make the application db independent ( no Access specific SQLs etc) at the beginning and see how it goes.
But I will definately start looking at other databases after this project for future systems especially in a multiuser environment.
suhu
Thursday, April 8, 2004
Recent Topics
Fog Creek Home
|