Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Access Productivity

Status
Not open for further replies.

VBADb

Programmer
Jul 30, 2004
11
US
Just looking for opinions...

I'm with a small company and have programmed in languages from Assembler to C++. We have an existing application in Access and for the last year I have been asked to develop certain projects using Access. The bottom line is for both myself and our office manager the development time is extremely slow. As one of my former co-workers would say - "you have to be smarter than the machine your working on" but I don't seem have the same problems with Excel/VBA. We just seem to always be "stuck in the mud" with Access. Is it like this with all DB development packages? Does anyone have experience with some other DB? I know this is an Access forum and my apologies if this question offends anyone. Just looking for a broader view.
 
Hi!

What size applications are talking about? and what do you and your office manager consider extremely slow?



Jeff Bridgham
Purdue University
Graduate School
Data Analyst
 
As a point-of-reference, I use Access extensively as a prototype tool--it's extremely fast as far as setting up a set of tables and forms for data entry to give managers an idea of what their 'real' app will do, then they give feedback on how the form should look, how the process should flow for the user, etc.

Then I put start the real development using VB/Oracle or VB/Sql-server. It takes much longer in VB, but much of the architecting of the tables and designing of the forms was done in Access, saving untold hours.

But the point is that Access is so fast for whipping up the data stores and UI objects. I know of nothing else that can do that.

With Excel, you're comparing Apples to Grapes, it's not a reasonable comarison unless the project is so non-data intensive that Excel will work for you, in which case Access maybe isn't the tool to use in the first place.
--Jim
 
Hi Jeff,
Mostly small to medium applications (if that adequately quantifies anything). Like I stated, we're a small company so we're doing HR apps for around 50 people, some small database apps for our customers doing product tracking which generate some Excel reports and some inventory database stuff. Extremely slow... that one is harder to quantify - we actually don't break out development hours. Seems I'm spending as much time in Tek Tips as doing Access development. Maybe have spent 60-70 hours on a simplistic inventory program and am still debugging the basics (received, processed, shipped) - problems with controls on forms, queries. Hope this helps some.
George
 
As with anything else, there is a learning curve. The more you use it, the faster it becomes to do the basics. However, you still end up spending the same amount of time building a project because you will continually find new things to do.
 
I somewhat agree w/ jsteph & KornGreek. Access is a pretty good development tool and perhaps the best RAD db device available. I have used Ms. A. for "enterprise" projects in two MAJOR copmpanies and am currently working on the largest Ms. A. db I've ever encountered.

In one of the large companies, Ms. A. supported 75 users with up to about 50 concurrent users. This process generated several thousand transctions per week and ran -essientially without error- for the last year I was at that company.

The current application is -for all pratical purposes- the entire operaqtion of the company. It is used for developing proposals to customers, ordering of equipment and material, entering time sheet information for ALL employees, generating billing / invoices , and many other smaller functions within the company. It also generates a large number of reports and supports numerous ad-hoc inquiries.

I must admit that in the several months I've been at this company, I have not yet tamed the beast. On the otherhand, I am reasonable confident that the issue is just one of size (and the attendant complexity), not one of wheather either the engine (Ms. A.) or the "engineer" (e.g. "Me") are inadequate to the task.

Relational database theory and implementation REQUIRE a more thorough understanding of (and care for) the principals and practices than spreadsheets and word processors. Then, the added complexity of Controls, Forms and Reports place an additional layer of detail over even that already new and mysterious beast (the relational database).

So, finally I meander to my 'answer'. Yse, it does take additional development time. A well done Ms. A. application takes even MORE additional development time. It MUST assure data integrity (not even a remote posability in Excel). It should provide the user with immediate access to all necessary and sufficient information to accomplish the designated tasks -without recourse to cobbling together disparate information sources- and assure that the data is of the correct type (and doesn't just 'look llike it'). There are many more 'requirements' to a well designed (and implemented) database application, but this snapshot should either cause you (and the errant manager) to say it just isn't worth it or to at least begin thinking about how the additional development effort is justified.




MichaelRed


 

Just wanted to say thanks to everyone who took time to respond. At least I have somewhat more of a prespective from the database community - an area that I'm new too. Thanks again to everyone.

George
 
Hi again!

Well it seems to me that the price you are paying time wise isn't bad for what you are doing, especially since you consider yourself to be new at it. Naturally, experience will make you quicker and, IMO, Access is worth the work. Access is an excellent product, not just for prototyping but also for production and archiving databases. Properly designed and Access db will do everything a small company could possibly want.

Again, IMO


Jeff Bridgham
Purdue University
Graduate School
Data Analyst
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top