November 20, 2019 at 5:08 pm
roger.plowman wrote:... From a developer standpoint Access STOMPS Visual Studio...
I have a few issues with your post overall, which have been brought up by others, but I'm going to say that's a little ripe for me to leave standing uncommented. VS does a wee bit more than DB forms methinks.
Wasn't talking about forms alone. Forms, reports, database design, code. It's all in one place. It's interactive, you can change the code and not have to recompile to see the effect.
Don't get me wrong, I use VS every day. But for example the Access control model is simply better. For example, Access has an AfterUpdate event that fires once, when the focus is lost on a dirty control, whether the change occurred by mouse or by keystroke. .NET controls have the TextChanged event that fires every keystroke. And while that's nice for fine control it's pretty useless for validation when you need the finished product to validate. (And no, there are glitches with how LostFocus events work that make it less than an ideal replacement for AfterUpdate). Not to mention different controls treat things like LostFocus differently. Either it fires in a different sequence in the event chain or the control uses a different event name or something else equally inconsistent.
Access also integrates report design in a way that is nearly identical to form design. And is also interactive. The speed of development between Access and VS is stunning. If it weren't for the security and scaling issues I would have stayed with Access, benign neglect by MS be damned.
Remember, Access was designed to be easy. Easy to use, easy to code, easy to integrate all the required pieces. As an IDE Access is superior to VS, as VS is to vi. Making it easy for beginners (done correctly) makes it easy for developers too.
November 20, 2019 at 5:37 pm
Roger, the features you describe are not unique to Access, they are features of any Windows fat client. Users prefer fat client software because it is more user friendly. I certainly do. The problem with any fat client is distribution of the software. This issue alone is the main reason that the software development industry has returned to the data center. Advocate for Access all you wish, of course, but do not pretend that it does not have the distribution problem that any other fat clients does. Access is a one file solution, designed for a single user with a desktop. With care, an Access solution can scale to the workgroup. Beyond that, it can be a disaster. Anyone considering implementing an Access solution should be made aware of this.
November 20, 2019 at 6:26 pm
While I agree that Access has some connection limitations, I wouldn't by any means say that it's "a one file solution, designed for a single user with a desktop". I'm not involved in it but we do have a product built on Access shared by many concurrent users.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2019 at 6:30 pm
Hi Jeff, I don't like to dispute what you are saying. Microsoft Access is a module in the Office suite of products. Office is an individual productivity tool designed for a single user with a desktop. One of the great business features of Office is its interoperability with other business users. Nevertheless, it is a microcomputer tool designed to run on a single workstation. I'm sorry, but there is no getting around that.
An Access solution consists of a single file and has no supervisor layer. It is a single file solution.
November 21, 2019 at 1:10 am
Ah... now I see where you're coming from, George. In that vein, I have to agree.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2019 at 10:40 am
call.copse wrote:roger.plowman wrote:... From a developer standpoint Access STOMPS Visual Studio...
I have a few issues with your post overall, which have been brought up by others, but I'm going to say that's a little ripe for me to leave standing uncommented. VS does a wee bit more than DB forms methinks.
Wasn't talking about forms alone. Forms, reports, database design, code. It's all in one place. It's interactive, you can change the code and not have to recompile to see the effect.
Don't get me wrong, I use VS every day. But for example the Access control model is simply better. For example, Access has an AfterUpdate event that fires once, when the focus is lost on a dirty control, whether the change occurred by mouse or by keystroke. .NET controls have the TextChanged event that fires every keystroke. And while that's nice for fine control it's pretty useless for validation when you need the finished product to validate. (And no, there are glitches with how LostFocus events work that make it less than an ideal replacement for AfterUpdate). Not to mention different controls treat things like LostFocus differently. Either it fires in a different sequence in the event chain or the control uses a different event name or something else equally inconsistent.
Access also integrates report design in a way that is nearly identical to form design. And is also interactive. The speed of development between Access and VS is stunning. If it weren't for the security and scaling issues I would have stayed with Access, benign neglect by MS be damned.
Remember, Access was designed to be easy. Easy to use, easy to code, easy to integrate all the required pieces. As an IDE Access is superior to VS, as VS is to vi. Making it easy for beginners (done correctly) makes it easy for developers too.
Fair enough, these points I can accept. A good report designer needs to be bought for VS to make it usable for such purposes. Access doesn't do anything like close-to-the-machine code, or distributed (web based) solutions in any way though. It's good at what it does, it's just a very limited sub set of development tasks.
November 21, 2019 at 10:51 am
Fair enough, these points I can accept. A good report designer needs to be bought for VS to make it usable for such purposes. Access doesn't do anything like close-to-the-machine code, or distributed (web based) solutions in any way though. It's good at what it does, it's just a very limited sub set of development tasks.
I don't agree you have to buy one in. SSRS is pretty capable (but very slow) - but I do agree that when you start working with R and tableau things get much easier
MVDBA
November 21, 2019 at 1:58 pm
roger.plowman wrote:call.copse wrote:roger.plowman wrote:... From a developer standpoint Access STOMPS Visual Studio...
I have a few issues with your post overall, which have been brought up by others, but I'm going to say that's a little ripe for me to leave standing uncommented. VS does a wee bit more than DB forms methinks.
Wasn't talking about forms alone. Forms, reports, database design, code. It's all in one place. It's interactive, you can change the code and not have to recompile to see the effect.
Don't get me wrong, I use VS every day. But for example the Access control model is simply better. For example, Access has an AfterUpdate event that fires once, when the focus is lost on a dirty control, whether the change occurred by mouse or by keystroke. .NET controls have the TextChanged event that fires every keystroke. And while that's nice for fine control it's pretty useless for validation when you need the finished product to validate. (And no, there are glitches with how LostFocus events work that make it less than an ideal replacement for AfterUpdate). Not to mention different controls treat things like LostFocus differently. Either it fires in a different sequence in the event chain or the control uses a different event name or something else equally inconsistent.
Access also integrates report design in a way that is nearly identical to form design. And is also interactive. The speed of development between Access and VS is stunning. If it weren't for the security and scaling issues I would have stayed with Access, benign neglect by MS be damned.
Remember, Access was designed to be easy. Easy to use, easy to code, easy to integrate all the required pieces. As an IDE Access is superior to VS, as VS is to vi. Making it easy for beginners (done correctly) makes it easy for developers too.
Fair enough, these points I can accept. A good report designer needs to be bought for VS to make it usable for such purposes. Access doesn't do anything like close-to-the-machine code, or distributed (web based) solutions in any way though. It's good at what it does, it's just a very limited sub set of development tasks.
I can agree Access is useless for web, but close-to-the-machine...for what Access was intended for (database applications) I'm not sure it actually needs bare metal coding ability. As for lacking web, well, IMO that's a benefit, especially given its limited scalability.
Web applications are by their very nature almost impossible to secure--just look at the avalanche of data breeches from companies that should have the resources to build cyber fortresses and are laughably naked to attack. Even governments can't seem to lock away their secrets.
Personally, given the dire consequences to life and limb a data breech could expose our company employees to, I'm more than happy to stay the hell away from web apps.
Reducing the attack surface as much as possible, don't you know. 🙂
November 21, 2019 at 2:04 pm
call.copse wrote:roger.plowman wrote:call.copse wrote:roger.plowman wrote:... From a developer standpoint Access STOMPS Visual Studio...
I have a few issues with your post overall, which have been brought up by others, but I'm going to say that's a little ripe for me to leave standing uncommented. VS does a wee bit more than DB forms methinks.
Wasn't talking about forms alone. Forms, reports, database design, code. It's all in one place. It's interactive, you can change the code and not have to recompile to see the effect.
Don't get me wrong, I use VS every day. But for example the Access control model is simply better. For example, Access has an AfterUpdate event that fires once, when the focus is lost on a dirty control, whether the change occurred by mouse or by keystroke. .NET controls have the TextChanged event that fires every keystroke. And while that's nice for fine control it's pretty useless for validation when you need the finished product to validate. (And no, there are glitches with how LostFocus events work that make it less than an ideal replacement for AfterUpdate). Not to mention different controls treat things like LostFocus differently. Either it fires in a different sequence in the event chain or the control uses a different event name or something else equally inconsistent.
Access also integrates report design in a way that is nearly identical to form design. And is also interactive. The speed of development between Access and VS is stunning. If it weren't for the security and scaling issues I would have stayed with Access, benign neglect by MS be damned.
Remember, Access was designed to be easy. Easy to use, easy to code, easy to integrate all the required pieces. As an IDE Access is superior to VS, as VS is to vi. Making it easy for beginners (done correctly) makes it easy for developers too.
Fair enough, these points I can accept. A good report designer needs to be bought for VS to make it usable for such purposes. Access doesn't do anything like close-to-the-machine code, or distributed (web based) solutions in any way though. It's good at what it does, it's just a very limited sub set of development tasks.
I can agree Access is useless for web, but close-to-the-machine...for what Access was intended for (database applications) I'm not sure it actually needs bare metal coding ability. As for lacking web, well, IMO that's a benefit, especially given its limited scalability.
Web applications are by their very nature almost impossible to secure--just look at the avalanche of data breeches from companies that should have the resources to build cyber fortresses and are laughably naked to attack. Even governments can't seem to lock away their secrets.
Personally, given the dire consequences to life and limb a data breech could expose our company employees to, I'm more than happy to stay the hell away from web apps.
Reducing the attack surface as much as possible, don't you know. 🙂
I haven't heard of this problem! Can you post more about web apps getting compromised on an intranet?
edit: I would think if you had attackers get past the firewall and actually be able to make intranet web requests, you're already in pretty big trouble LOL
November 21, 2019 at 2:28 pm
I haven't heard of this problem! Can you post more about web apps getting compromised on an intranet?
edit: I would think if you had attackers get past the firewall and actually be able to make intranet web requests, you're already in pretty big trouble LOL
I'm going to regret posting this as I am in the pro camp for web.. but SQL or HTML injection attacks by disgruntled employees accounts for quite a few data breaches - they can then take them off site on USB... I've seen this on 2 sites where there were "whistle blowers"
MVDBA
November 21, 2019 at 2:52 pm
x wrote:I haven't heard of this problem! Can you post more about web apps getting compromised on an intranet?
edit: I would think if you had attackers get past the firewall and actually be able to make intranet web requests, you're already in pretty big trouble LOL
I'm going to regret posting this as I am in the pro camp for web.. but SQL or HTML injection attacks by disgruntled employees accounts for quite a few data breaches - they can then take them off site on USB... I've seen this on 2 sites where there were "whistle blowers"
I'm not saying to make your app allow code injection and additionally, SQL injection if allowed affects any app that will let you enter arbitrary SQL into a text box and execute it. Heck I found one just by reviewing a dot net app, the developer most likely knew better but was just thinking this can't happen in a dot net app, but I was able to send arbitrary commands to the database server through the text box by the usual injection thing. So I recommend folks not let their guard down just because its not a web app.
You can incorrectly code anything and I get it, many programmers are relatively uneducated, and security practices in general seem to be pretty awful. But if your database is secure enough to allow MSAccess operations, you're probably going to be pretty secure with a web app especially if data is properly escaped before use or presentation.
Theres always going to be exploitable bugs and additionally I'm going to wager that many insider breaches come from a lack of security efforts by the internal IT department, probably many more than any injection of an intranet web app.
Also, whistleblowers should be protected not denigrated.
November 21, 2019 at 3:00 pm
Also, whistleblowers should be protected not denigrated.
I've been one twice - once for a major rail disaster caused by a failing in the design of track inspection software (by another company) and once for a data leak, trust me you don't get protected
MVDBA
November 21, 2019 at 3:07 pm
x wrote:Also, whistleblowers should be protected not denigrated.
I've been one twice - once for a major rail disaster caused by a failing in the design of track inspection software (by another company) and once for a data leak, trust me you don't get protected
You should have been protected, and it sucks that you weren't.
November 21, 2019 at 10:20 pm
Don't forget to compact and repair! 😉
Okay, joking aside, I got my start in FoxPro as a couple of others have mentioned back in the mid 90's. It too had an all in one simple to use IDE that you could build a whole application in. I sometimes wish that it had won out over Access.
Anyway, I have forklifted a number of Access applications to use an Oracle or SQL Server back end. It can work well for small groups, as long as it's using pass through queries. Otherwise it tends to work at the table level which causes some of the blocking that others have mentioned.
Viewing 15 posts - 46 through 60 (of 70 total)
You must be logged in to reply to this topic. Login to reply