July 22, 2014 at 2:58 pm
If I want to hang a picture on the wall, I use a nail and a hammer. If I want to take photographs, I use a camera. Sure it is convenient that my phone can take a snapshot (and so can my laptop and my tablet and soon, my glasses) but that isn't the same as a professional quality photo which I am able to do with a camera. This trying to squish everything into one paradigm is insane. You end up with solutions that do everything but they do nothing well. Communication is the real issue. Applications need to be able to interact with each other in controlled ways. I want to be able to interact with other applications but it isn't necessary that one tool do everything. If I need to interact with strangers, my only option is a web page. If I'm working internally with a controlled group of known people, I have other options. Should we discard all cameras because phones can take crappy snapshots? Why should we discard client/server in favor of a less rich web tool that I now need to incur additional expense to host either internally or externally? Especially considering there is no value added. The web solution is inferior to the client/server solution. Who wants a touch screen on their desk to do data entry? Could you actually program that way? My arms are too short!!!! I have a big monitor so I could increase the print size and sit back and be comfortable. Now Windows 8.1 thinks EVERYTHING must be a touch screen. That is a case of hubris and being completely out of touch with your client base. Yes it's "cool" that I can stream video to my phone and hook up with my friends if they choose to show their GPS locations but those applications have nothing what so ever to do with the needs of a business unless you are paying your employees to listen to music and watch movies and chat with their friends.
July 22, 2014 at 3:45 pm
To Patricia Hartman - oi, where even to start?! Let's see:
Why should we discard client/server in favor of a less rich web tool that I now need to incur additional expense to host either internally or externally? Especially considering there is no value added. The web solution is inferior to the client/server solution. Who wants a touch screen on their desk to do data entry? Could you actually program that way? My arms are too short!!!!
1. No-one is suggesting you 'discard' client/server. I'm simply suggesting there may be web-based application development solutions which might also be worth considering.
2. At the same time, consider where the marketplace has gone over the last twenty years; it's generally moved from client/server to the web. Are we all suffering from some mass delusion, or might there be some perceived added value behind this change?
3. The web solution may or may not be inferior to the client/server solution - in each case, it really depends on the business and technical requirements.
4. Touch screens work great on smaller form factor/mobile devices. I have one product that's used by field workers whose primary tools are shovels and pick-axes. They don't do keyboarding very well.
5. I'm sorry your arms are too short for touch screens! I'm part orangutang myself, so no problems here. Seriously, though, no-one is suggesting programming using a touch screen - that's not the right tool for the job - but touch does work nicely in a wide number of web applications on a wide range of devices and form-factors.
Anyway, Patricia, I'm packing it in on this thread. I wish you well, and hope the next 20 years using Access are as fun and profitable for you as the last 20 have been.
July 22, 2014 at 4:43 pm
1) I'm not arguing that point. I've looked at some. The benefit of browser based solutions is their ease of distribution. If you can overcome the distribution issue (and it's not easy), client/server still provides a better user interface. If you have to interface with the public, you need a browser based solution. If your app is inward facing, you have options which no one seems to realize.
2) Are we all suffering from some mass delusion?
Yes. Every one likes the shiny new toy. I have never known a programmer to say - let me implement with tried and true methods that do the job at hand. They really don't care. All they want is to play with the new toys (I am just as guilty as the rest in this regard). It is the managers who need to get control of the children and guide them. They do after all work for the company and the company is in business to make a profit not to provide toys for the children. When a need arises for a new toy, then by all means, use it. But the inmates have confused a real need for the toy with the desire to pay with it and so attempt to use it for everything regardless of whether or not it makes sense.
5) My arms are not too short to use my phone, although my fingers seem to be too fat; it's my eyes that are the problem there. That point was a jab at MS for assuming that everyone who installed Win 8 would be using a touch screen and making it impossible to continue to do business the way desktop users have always done business. There is change that is productive and necessary and there is change for the sake of change and I wish they could sort out the difference. I have a hundred people complaining to me that they can't see the forms/reports anymore since we "upgraded" to O365. The metro look just doesn't cut it. I'm spending a huge amount of time changing all my standard themes to be non standard just so people can see things they had no trouble seeing when they were using A2010. And, I'm almost certainly going to have to change them again with the next release of Office. Or perhaps, I'll come in some Wednesday and find that patch Tuesday had made all my theme adjustments glow. That's the kind of change we can live without.
Thanks for participating. It was great to chat with you folks. I hope you've all learned a little about Access and its sidekicks Jet and ACE. I'll probably drop in with my SQL Server questions as they arise.
July 23, 2014 at 8:48 am
I have never known a programmer to say - let me implement with tried and true methods that do the job at hand.
You never talked with me when I was a programmer. I never went with "shiny new toys" for their own sake.
July 23, 2014 at 9:05 am
RonKyle (7/23/2014)
I have never known a programmer to say - let me implement with tried and true methods that do the job at hand.
You never talked with me when I was a programmer. I never went with "shiny new toys" for their own sake.
Don't blame them for the quality of developers that they have worked with. "shiny new toys" are sometimes worth using but only to solve or relieve an issue.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 23, 2014 at 2:25 pm
Was glad to see people admitting they use Access.
Since Access 97, my preference is to quickly prototype in MS Access.
Then take the model and convert it into SQL Server.
Since 1999, taking VB or Access front-end and distributing nationally with Citrix, keeping SQL Server for the back-end has proven profitable. Access when properly designed can support hundres of concurrent users securely.
Not every application needs to be Web-based available to millions of users.
There are many mid-size Divisions (30 to 500 users) where business decisions application using a rich front-end interface can be the right approach. In my case, the business rules for compliance, regulations, and data-trending seem to need a tool of this order. The SQL Server itself can concurrently be consumed for Web users in a larger audience.
It is a real shame that Microsoft has basically dropped Access as a valid development platform.
July 23, 2014 at 3:13 pm
I don't think the MS has ever understood what they had with Access. Bill Gates was a real champion in the earlier days but as he got further away from the details, no one else ever picked up the mantel. Even the Access development team thinks of the .mdb/.accdb as a document rather than as an application so there is little understanding or support for professionally created apps to facilitate distribution and source security. The SQL Server team, who controlled Jet (the Access team now controls ACE) spread rumors about the death of "Access" when what was really happening was Jet was being replaced with ACE and that scared a lot of customers a few years ago. And that brings us back to my major point; make sure you know which app you are dissing when you complain about inadequacies.
With the deprecating of Source Safe, it is almost impossible for a team to work on a single app. Even with Source Safe it was difficult. That seriously limits the scope of anything you can create since it is like serial monogamy. One developer at a time.
July 23, 2014 at 3:28 pm
Patricia Hartman wrote:
With the deprecating of Source Safe, it is almost impossible for a team to work on a single app. Even with Source Safe it was difficult. That seriously limits the scope of anything you can create since it is like serial monogamy.
Patricia, have you checked out Subversion[/url] and Tortoise SVN[/url]? You might be pleasantly surprised.
Serially and monogamously yours.
July 23, 2014 at 4:41 pm
I was just talking to a consultant I hired about this. Even with source management, it is virtually impossible to have two people working in the same database. At the moment, I've isolated enough of the framework so he can develop reports for me outside the main app and I integrate them as he finishes. The problem is the framework isn't quite complete so as we make changes to that, we are having trouble syncing the two .accdb's.
The problem with how Access integrated with Source Safe et. al. is that it was so incredibly slow that you couldn't check out all items when you opened the app. You had to check them out one at a time when you wanted to make a change. But, that is where the trouble came in. You could still change anything even if you hadn't checked it out and when you closed the database, you never knew you were now out of sync. The app we are trying to work on together now has 50 tables, most are linked but a couple are local to the FE because they control things like the menu and selection criteria options for the reports, 111 forms/subforms, 43 reports/subreports, 15 code modules (in addition to the class modules attached to each form/report) and almost 400 queries. It's a good sized Access app but not even close to the largest I've ever built. Given our timeframe, I need help which is why I brought in someone else but given the overhead of coordination, it is less productive than I had hoped. For those of you old enough to remember "The Mythical Man Month", it doesn't matter how hard they try, nine women simply cannot make a baby in one month:)
So, this is the true reason that Access apps tend to be on the smaller side. It doesn't have anything to do with the number of users or the size of the tables since both of those problems are easily solved by using a server based RDBMS instead of Jet/ACE, it has to do with the number of objects that need to be created and the timeframe for the project. There is just so much that one developer can do in a day and it is simply too hard to add additional developers productively.
July 24, 2014 at 10:44 am
Mile Higher Than Sea Level (7/23/2014)
It is a real shame that Microsoft has basically dropped Access as a valid development platform.
I really have to disagree with this. Access continues to be a very viable development platform. While its true that MS is looking to enable Access as a WEB development platform and that is there focus, nothing has been dropped that invalidates it as a development platform.
On the other hand, I do have to agree that it is not easy for a team to collaborate on developing in Access. its still possible, but various members of a team need to be assigned very specific tasks.
On the other hand, almost every Access app I've developed has been, in a certain light, a team product. I say that because, I constantly use functions, techniques and ideas I've picked up from the WEB and other colleagues. The amount of support for Access outside of Microsoft is amazing. Its also why Access MVPs are one of the largest MVP groups.
Scott<>
July 24, 2014 at 8:23 pm
Rumors of the demise of Mark "Access" Twain have been rampant since shortly after the release of Access 2.0 in 1994. Such rumors have never been more true than they are today. Nor has the ardent hope for their truth ever been greater.
July 24, 2014 at 9:26 pm
George Hepworth (7/24/2014)
Rumors of the demise of Mark "Access" Twain have been rampant since shortly after the release of Access 2.0 in 1994. Such rumors have never been more true than they are today. Nor has the ardent hope for their truth ever been greater.
The creation of Microsoft Office 365 seems to indicate they want to make Office a web app as opposed to having the availability of client server.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
July 25, 2014 at 6:01 am
Jim P. (7/24/2014)
The creation of Microsoft Office 365 seems to indicate they want to make Office a web app as opposed to having the availability of client server.
No it just means they want to compete with Google Docs and make Office more accessible in the Cloud. Doesn't mean they are doing away with the standard desktop. Why is it hard to understand that functionality can be added without taking away from previous functionality?
Scott<>
July 25, 2014 at 6:37 am
Dalkeith (7/18/2014)
I also believe it [Access] is an excellent tool for teaching database design principles and UI design principles.
patriciahartman (7/21/2014)
Also mentioned by several people is the use of "Access" as a database teaching tool. This is widely practiced by universities in the UK although it is much less popular in the US. Why make a beginner learn how to work with a command line interface or a complicated GUI when what you are trying to teach is the principles of normalization?
I think this is a mistake and, if true, it's probably to the detriment of some IT education in the UK. There are plenty of good reasons to use Access for application development. It's a great RAD tool for developers but it's not a healthy environment for students to learn about the principles of databases or database design or data management practice in general.
The Access UI obfuscates many of the things that students on database courses ought to be learning. For example the truly awful "diagram" view in the Access UI uses an inferior pictorial notation (don't ever call it an Entity Relationship Diagram please!) that is completely non aligned with any standards used in industry, academia, textbooks or indeed any other software product except Access itself. The concept of "relationships" is also unique to Access and hides and confuses important and distinct features of data management (i.e. referential integrity and the use of joins in queries). The SQL dialect used in Access is more limited and less standard than any other mainstream SQL product and simply lacks too many features to be a credible platform for learning proper SQL. The QBE has long standing bug-features that make it hard or impossible to write perfectly valid queries (even queries that are valid in Access's own dialect of SQL). The query designer features in general are a seriously frustrating obstacle to any student of SQL. Concepts and terminology used in Access or its documentation are also out of step with the rest of the data management industry.
The idea that Access could be useful for teaching "principles of normalization" is pretty strange. Alternate keys are hidden away behind several mouse-clicks and only shown as part of index definitions. Not only is that information rather cumbersomely presented in the UI, it can only be displayed for one table at a time. How are students supposed to concentrate on understanding normalization if they have to jump through so many hoops to view candidate keys?
I could go on and on but the Access forums have enough evidence of problems encountered by people trying to learn but coming up against these and similar frustrations or labouring under misunderstandings due to the inadequate way things are presented in Access.
I think students new to databases would be well advised to stay away from Access until they know what they are doing. It ought to be considered an advanced tool for developers and not any kind of platform for beginners to learn about databases.
July 25, 2014 at 6:48 am
For example the truly awful "diagram" view in the Access UI uses an inferior pictorial notation (don't ever call it an Entity Relationship Diagram please!) that is completely non aligned with any standards used in industry, academia, textbooks or indeed any other software product except Access itself. The concept of "relationships" is also unique to Access and hides and confuses important and distinct features of data management (i.e. referential integrity and the use of joins in queries).
I really do not understand how you can say this. It's possible to set relationships and have them show one to many, to enforce RI constraints, cascade updates and deletes. It's hardly far from any standards.
The SQL dialect used in Access is more limited and less standard than any other mainstream SQL product and simply lacks too many features to be a credible platform for learning proper SQL.
Completely agree here.
The idea that Access could be useful for teaching "principles of normalization" is pretty strange.
I successfully taught normalization using Access for years.
I could go on and on but the Access forums have enough evidence of problems encountered by people trying to learn but coming up against these and similar frustrations or labouring under misunderstandings due to the inadequate way things are presented in Access. I think students new to databases would be well advised to stay away from Access until they know what they are doing. It ought to be considered an advanced tool for developers and not any kind of platform for beginners to learn about databases.
There is something to be said for having a guide. While someone can learn Excel or PowerPoint largely on their own, my impression when I was an applications instructor was that most people needed someone to help. I was no different. But it wasn't any different than SQL Server. Learning the database aspects of Access gave me a grounding to move to SQL Server.
Viewing 15 posts - 91 through 105 (of 113 total)
You must be logged in to reply to this topic. Login to reply