Die Access, Die
-
Jim brings up a good point, but the problem with Access is it makes it too easy for the secretary or very unknowledgable person to build something they can use 80% of the time and deal with the quirks. Once they give it to others, we start to have issues.
Access could make some sense as a front end, but then why not build it out as a "front end tool" and put some limits on the trouble people can get in to with small applications.
Most development environments are fairly intolerant of mistakes. VB developers caused a lot of problems early on and I'd have argued that VB shouldn't have been released until it was OO capable. That alone limits the number of people causing problems.
-
In for penny...
Your VB comment is telling because it assumes that complexity is restriction enough i.e. if it's too complex to understand then no-one who isn't competent can use it. All that means is the slightly more competent -or someone with a half decent book - can make a hash of it instead. Again I go back to the point no matter what platform you use if the developer is incompetent then you will get a mess and i would argue the more complex the environment the more of a mess you'll get.
On the OO VB statement. If you believe OO is restrictive because of it's complexity then what does that say about it. What is the point of a paradigm that can only be understood and implemented successfully by a select few, great if you’re a programmer, crap if you’re a business that wants to get things done. This is precisely why Access and procedural languages are still used. In the real world getting things done is more important than standing on some imaginary moral high ground surrounded by the UML labour of thousands congratulating ourselves on the vast expense we have incurred to develop something a VB6 programmer managed to accomplish successfully on their own 6 month earlier. Guess which side of the fence i sit on
At the end of the day I might of agreed with you if it wasn't for the fact i've seen garbage created in all sorts of languages and databases, complexity is no barrier to earnest stupidity.
K.
-
I know a lot of people with "micro" businesses (1 to 5 employees, typically family) that use Access exclusively. They don't need anything more and it's a complete environment. My wife and I use it do her "shoe box" accounting for her business .
To paraphrase a well know saying here in the USA, Access doesn't kill. It's the people who use it that do. Like anything else, used properly, it is a good tool.
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
-
I've used Access successfully since 2.0 and there are limitations (size issues, web usage) and annoyances (proprietary date and variable structure). But there are some wonderful benefits also. Being able to link both SQL Server, Oracle and dbf tables in one platform and produce forms and reports almost as fast as you can conceive of them is a big plus. Creating forms to interact with SQL importing/exporting and backups is another. Version upgrades are as manageable as any other product. Easier in some respects.
Access will most likely have its teeth pulled from it, but since Microsoft uses it extensively under the covers, it won't entirely disappear. I've noticed many software vendors install a mdb file with their product. Have you noticed that each version of the Sybase born MS SQL Server behaves more like Access with each revision? The Access table gui is being used as table gui in SQL Server 2005. Query analyzer 2005 has an update of the Access query gui. And Microsoft has created an entire system (BI) to perfom the same Access reporting functionality.
Access has been bashed by any programmer who writes in a real language and this won't change. For that matter, TSQL programmers don't get the same respect as VB programmers, who get shunned by C, C+, C# programmers. But my job isn't to write in Access/vba. My job is to produce the desired results in a timely fashion and I use whatever tool is best suited. I refuse to not use Access because it is looked down upon. The last Access database I created used SQL server 2000 as a back end with an Access adp front end. This has worked flawlessly. I get the power and security of SQL Server for 75-100 users and the flexibility of being able to quickly create over 150 forms and 200 reports, offering any variable I have for my users who want to filter both forms and reports.
Access is a tool like any other program and as such is not structured for every job, but then what is? If you work with SQL Server 2005, for instance, you have to use TSQL, SSIS, BI and .net tools to produce a complete product. All of these are good, but sometimes you don't need a sledgehammer, just a rubber mallet to bang something out.
-
In this forum and in the cited article, there seems to be pretty universal agreement that Jet as a data store (it's not *Access* that is being used as a database, it's *Jet*) is a bad idea.
I wholeheartedly dissent.
I have been developing professionally in Access since 1996, and the vast majority of my clients are small businesses or workgroups with 1-25 users. For the low end of that, there is no server machine to run a db server on, and there's absolutely no justification for them using a server in 99% of those cases.
Just as with *any* database, you have to design an application to be efficient in retrieving and updating data. Using Jet does not change that.
The vulnerability of Jet is that it is a shared file and that creates locking issues when multiple users open it. But if you don't share your front end, this is a minimal problem (it should go without saying that any competently-implemented Access application will have a front end MDB with forms/reports/queries/code and a back end data MDB with nothing but tables). In the 11 years I've been doing this, I've had clients lose data only one time, and that was because they were backing up the wrong MDB (the front end instead of the back end -- lesson learned: set up their backup routines for them) and were never compacting/repairing their data file (despite my instructions to them to do so). In retrospect, having recovered a data file that was 3 months old, I found that the back end had been carrying corruption for a very long time, long before I was brought in to fix their problems (which were badly exacerbated by using a workstation as a file server, and the workstation was running the buggiest version of WordPerfect that ever existed, 6.0, and it was crashing the whole machine several times a day; this was in Win3.x days). Again, I learned a lesson: when brought in to fix a problematic Access app, rebuild all files from scratch.
But I digrss.
It is true that very occasionally, my clients' Jet MDB data files corrupt. Actually, what most often happens is that the files are somehow closed in a dirty fashion and they are flagged as "suspect," so that the next time they are opened, they need to be compacted/repaired. 99.99% of the time these "corruptions" are not corruptions at all, and no data is ever lost. The easiest way ot minimize this problem is to have a backup and compact routine run overnight on the file server so that the MDB is always in a pristine state in the morning.
There are other vulnerabilities, such as corrupted memo field pointers. This can be minimized by using unbound controls to edit memo fields.
In short, *properly administered* Jet data files are very safe.
Now, that said, of course, if you need 24/7 uptime and can't afford even the possibility of 1 record being lost and need unbreakable security, then a Jet data store is not a good idea.
But most small business applications don't need any of those things.
The people who can't keep Jet data files running smoothly simply are not competent. Those who are incompetent definitely should not use Jet as a data store.
But for the rest of us who know what the hell we are doing, it works quite well and provides real value and capability for small businesses who otherwise would not be able to afford their db applications.
-
Lots of good comments and I agree with most of them - on both sides. If you want to have some fun, spec a simple form based app that will have text boxes, checkboxes, and a couple data driven lookups, then have a VB developer race the Access developer. Access developer will be done and looking for work long before the VB'er. Access just makes it simple to do the kind of data access that most of us need.
PC's overtook the mainframe in large part because users could do 'bad' things very quickly and deliver value. More and more in corporate IT we seem to be taking the attitude that if IT doesnt build it that users can't have it. Sharepoint I think is a good example of the business seeing a way to be empowered again to an extent to distribute information. It's obviously not as simple as saying do whatever you want, but killing Access/Excel/etc won't solve the problem either.
-
MS did, and does, provide, in Access, a way to have a full and tight integration with SQL Server, which enables you to use the user friendly, GUI Access as a front end to the robustness of SQL server. It is called Access Data Project and it maintains its own connection to the SQL server. All the tables, views, and queries are on the SQL server. Only the presentation layer objects are in Access.
When you pair this with stored procedures, you have the best of both worlds! The data access and processing is done in the back end where it should be done, and the presentation is done in the front end where there are user friendly tools to produce forms and reports.
That is not to say that Crystal Reports could not be used to produce the same reports, or Reporting Services, or Visual Studio. Using stored procedures to provide the data access allows the freedom to present the data in multiple platforms, one of which could be Access.
-
RANT ALERT...... RANT ALERT..... RANT ALERT....
<rant>
It's funny to me to see how little respect Application developers seem to get from the data community. Let's face it - it's a self fulfilling prophecy. Let's review the process:
- think and verbalize that any monkey with a text editor can whip up fully functional apps. Tell your Boss and HR that
- Boss and HR go out and hire said monkey, paying him two peanuts and a banana.
- Monkey builds app on test server and demos it to Boss, who approves it to be published
- Monkey-written application wreck DB server access, dumping record after record of crappy data into the DB.
- DBA spends oodles of time finding and fixing issues caused by said application, muttering lovely things like "what - did a monkey write this?"
- ...
Sure - I can find someone I can pay 12$/hr. to write my applications, or "whip up a web app", but that doesn't mean it's going to be any good. Good apps are built when and only when the data and the presentation/UI level are both well represented by competent, technically savvy, and "other-side" aware technicians. Actually - as another thread was trying to impress - if a DBA is empowered to try and be the Guardian of all good data, and preserve data integrity and reliability, then very likely their first responsibility would be to ensure that they are surrounded by *competent* and highly technical app programmers.
That being said - expecting your user community to just sit around and wait for IT to "whip up a web app" for them just isn't realistic either. Will their applications be less than optimal? Sure. Might they make the server a little cranky? possibly. Could I have done a better job? I'd like to hope so, but I have to get through these other 32 things which will take me 42 months to complete.
Apps (the real ones) are neither easy nor quick to build, but until we can all convince the various senior leaderships in our various organizations to fully fund appropriate development shops that can keep up with the needs of our end-user community, trying to take away the end-user tools is, well - Criminal.
</rant>
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
Should we say that Yukon does the same to SQL Server?
It makes it too easy for the Java/VB/... developers or other very acknowledgeable persons to build something they can use 80% of the time and deal with the quirks. Once they give it to others, we start to have issues.
Actually, Steve has a good point.
With introduction of 2005 and 2008 versions SQL Server degrades to Access level. So, there is no point to support same level applications.
_____________
Code for TallyGenerator -
Hate to beat a dead horse, or maybe I just need to get in the last word… Today I had to listen to yet another anti-Access rant based on hearsay and "conventional wisdom" which encouraged me to suggest this entrance exam for further participation in the debate that suggests Access applications are ugly, amateurish and inefficient:
Q1. How many serious applications have you developed using Access?
A1. 0 -- You are not qualified to comment.
A2: >0 -- continue to Q2.
Q2. Of the serious Access applications you have developed, how many were ugly, amateurish, and inefficient?
A1. 0 You have proved the point that quality serious application development can be done professionally in Access.
A2. >0 You have proved that bad applications can be developed in Access, and you are one of those bad developers.
-
Nice reply, Jim. (Not to take away from your last word)
-
Thank you Steve. (Got it back!)
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply