MS Access database - Is this possible?
Discussion
At the moment we have a requirement for a call handling system for one off small volume telesales projects, as a result it has to be cheap and easily modified to be practical.
Its been suggested that we could do it within access, however with no access experience it means grabbing an "access for idiots" book and putting in some serious playing.
Anyone out there with plenty of access experience willing to have a quick look through the spec and let me know whether this is practical to do myself or whether we will have to fork out for someone to do it for us?
Its been suggested that we could do it within access, however with no access experience it means grabbing an "access for idiots" book and putting in some serious playing.
Anyone out there with plenty of access experience willing to have a quick look through the spec and let me know whether this is practical to do myself or whether we will have to fork out for someone to do it for us?
TheLemming said:
For it to be worthwhile I would need to capture call outcomes, generate a seperate database item for each call result capturing the notes entered at the time.
Then show a listing of available calls for the agent to make the next outbound call.
This sounds like the system that we use at work here (which I created). The main screen stores company/organisation information at the top half, with the bottom half storing "Encounters". Each company can have as many of these as you like. Details of what happened are stored along with what should be done next. The "next action" field then generates a diary which we use for our full time telesales staff to keep em pro-active with ye customers and potentials.
It started out in Access 2.0 what must be 8 years ago, then 97 and now XP with SQL back end.
I agree - definitely possible in Access. We have several incident/contact logging systems that use Access.
What we've found is that these tend to grow from simple systems with a handful of users to multi-user "business critical" systems that you can't do without (at which point I normally have to fix them!)
What we've found is that these tend to grow from simple systems with a handful of users to multi-user "business critical" systems that you can't do without (at which point I normally have to fix them!)
One further comment on Access - to use a car analogy, building an app using Access is like building a kit car. It is possible to create something that looks horrible and is unreliable, but it is also possible to do something good, perfectly reliable using less effort than other methods.
One bad thing about Access in the past is that even the run time "version" loads up the large access .exe, but with the speed and memory of modern PC's it isn't really relavent any more..
One bad thing about Access in the past is that even the run time "version" loads up the large access .exe, but with the speed and memory of modern PC's it isn't really relavent any more..
Thanks for the response everyone.
Now we know its possible, is it a good idea to use something like access for this or is there a better solution out there?
The last thing I want to do is take a substantial amount of time learning to do it, then doing it, then realise it should have been done in another medium...
Now we know its possible, is it a good idea to use something like access for this or is there a better solution out there?
The last thing I want to do is take a substantial amount of time learning to do it, then doing it, then realise it should have been done in another medium...
Access is a doddle as long as you know SQL and simple relational database theory.
An advantage with access is that you can slap a front end on it using ASP or VB or C# or just about any language which can use ODBC.
I believe that is also possble to use the access front end to talk with another datasource. So you could build your app in Access then migrate database to SQL Server (due to the simplicity of the migration path) or your interface to a web front end with out losing data or user experience
An advantage with access is that you can slap a front end on it using ASP or VB or C# or just about any language which can use ODBC.
I believe that is also possble to use the access front end to talk with another datasource. So you could build your app in Access then migrate database to SQL Server (due to the simplicity of the migration path) or your interface to a web front end with out losing data or user experience
The bad bit about an Access database (independant to the front end being VB, C or Access etc) is that it exposes data over a network for multi user systems.
Unreliable networks or users who don't use applications properly can cause data corruption since it is basically a file sharing system.
To take an access front end/back end (the actual data) to SQL back end is very easy. You can tell the management that it will take a week, do it in a few hours and spend the rest of the time on PH.....
Bosses here would probably allow the system I did to be sold externally and customised.
Err, apologies - I'm getting dreaming of ways to fill the "TVR" labelled piggy bank quicker....
Unreliable networks or users who don't use applications properly can cause data corruption since it is basically a file sharing system.
To take an access front end/back end (the actual data) to SQL back end is very easy. You can tell the management that it will take a week, do it in a few hours and spend the rest of the time on PH.....
Bosses here would probably allow the system I did to be sold externally and customised.
Err, apologies - I'm getting dreaming of ways to fill the "TVR" labelled piggy bank quicker....
Access is fine for a lot of small scale things, but if you're planning on a DB getting bigger than about 1Gb you'd be better at looking elsewhere (MSDE or SQL Server probably - maybe with access front end). Access 2K will go up as far as 2Gb I believe (possibly even 4), but it get's difficult to manage.
The other thing to consider is concurrent users. From memory, Access creaks and groans over 2 or 3 concurrent users.
The other thing to consider is concurrent users. From memory, Access creaks and groans over 2 or 3 concurrent users.
PetrolTed said:
In my experience it will cope with 100+ concurrent users without any problems.
But is that concurrent website users, or is it 100+ queries being run on the same DB at exactly the same time?
I used to build telecoms billing packages in VB talking to Access and with more than single figure call centre people using the font end Access was in trouble. These users have a lower "think time" between database access than web users.
All IMHE of course.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff