Question Access vs ASP.net

Landcruiser87

New member
Local time
Yesterday, 17:16
Joined
Oct 30, 2008
Messages
3
Greetings!

I've seen some earlier posts on this site about the difference between the two but am looking for an updated opinion. (the last reference was made in 2004 and i think both programs have evolved a TON since then) A little backstory, I've worked in a sports R&D laboratory for the past 6 years as a technician/vba programmer. As such, i took care of most of our data needs by using access. Its easily customized, fast and reliable. Recently, I switched companies (same job) and found myself in the middle of them deploying a new database (their old one was excel, barf) using Asp.net and an SQL Backend.

In terms of databasing standards, this seems normal, but i have no experience with asp.net and SQL. While i have no problem learning a new language, it seems the steps required to even utilize some of the most basic databasing functions are extensive. i.e. - it took the one guy who was designing it half an hour to add a column to a table. HALF AN HOUR. In access this takes you... roughly 30 seconds. (if you're checking field settings) so if it takes that long to wrangle a new column, whats it going to be like for any reporting functions. Or any, god forbid, graphing functions.

Another problem is that he inherited an old database from our parent company. They basically gave him the schema and said, Here. make it work. So after going through some of the structures i've found all sorts of bad databasing design. i.e. Abbreviated words for unique identifiers, repetition of data across multiple tables, etc. Its a mess! And granted, the guy developing it has done an amazing job cleaning it up to this point, his contract is almost up and he doesn't have the time to go through and change all these things, which means the ball is going to be left in my court to fix.

So i'm looking for some public opinion on development in the ASP.Net/SQL. If it is indeed the way to go, then I’ll shut my trap and slog through the learning curve. But my gut is telling me that so many of the functions that are going to take FOREVER to develop can be done in a fraction of the time with access. I'm basically looking for any ammunition i can take to my boss to support my gut feeling of switching, even though they've already dumped a considerable amount of money into this project. Also, i have the databasing structure for my last companies database that i designed, and could easily retrofit, implement, and deploy within a month. I feel I should also mention that this database isn't goign to be used by 10,000 people like SQL is designed for. Its going to be used by maybe 50. at the most.



Help!!!!!!!!
 
What are the requirements? How many simultaneous users? Located on the same network or not? Is remote access required? Is access for outside parties required? ASP.NET is for access using a webbrowser, from Intranet or perhaps Internet, and does not require any local installation.

The perceived technical ease/difficulty is a minute driver behind the choice. The requirements are the primary driver. Your post doesn't say much about those.
 
I'm like you Land cruiser I'm just so more productive in Access I really struggle to see the benefits of ASP.NET.

For us its only proving necessary for real outward facing stuff.
That's forms for customers / shopping requirements. Relativly low complexity high concurrency stuff.

High complexity internal systems I'd go with access everytime. For all intensive purposes Access / SQL Backend development of new systems is completely free for us and now we have terminal services we can get to desktop programs anywhere.

If you really want ASP.NET stuff with SQL backend probably a great idea to get some outside help in from experienced person to show you the ropes. This may prove expensive but will save you hours of pain and will at least give you road map.

If I were you for a 50 user system I'd definitely go the Access / SQL backend route. I have a habit of going ahead and doing things and then presenting them with finished system. Much harder for them to discount you then.:D
 
Last edited:
half an hour to add a table column? that's not a weakness of the database or ASP.net imo.

horses for courses in many respects. What do you need from your system? Access to a point can be quicker for a simple database because it provides a reasonable framework (VBA/forms/reports etc) to knock up quick and simple database applications but lacks many of the features and refinements that you'd expect from a full enterprise level Database product. Also on the downside it has terrible performance, severe limitations and not just allows but actively encourages terrible practices when it comes to both database and application design and implementation not to mention has a pretty limited ability to scale as requirements increase.

In some respects the case for using something like SQL Server and ASP is pretty clear cut so if you're scratching your chin and wondering if you should bother with the initial extra overhead to develop in that environment, especially if you're going to have to learn it from scratch, it's probably a self answering question. VBA is NOT .NET lite, it's just about VB6 lite and that's being kind to it.

I'm like you Land cruiser I'm just so more productive in Access I really struggle to see the benefits of ASP.NET.
I use VB/C# but I find the opposite to be true, I hate the limitations of Access and VBA. It is more forgiving for "dabblers" who've been lumbered with developing a database or for rapid development of quick, simple databases that don't have to do too much though, I will give it that.

For all intensive purposes
Sorry to be a grammar nazi but it's 'intents and purposes'. It drives me bonkers :D
 
I hate the limitations of Access and VBA. It is more forgiving for "dabblers" who've been lumbered with developing a database or for rapid development of quick, simple databases that don't have to do too much though, I will give it that.


Sorry to be a grammar nazi but it's 'intents and purposes'. It drives me bonkers :D

Thanks for the correction I'd never noted that before.

Can I ask why you're registered in an Access Forum if you find it limiting?
 
To try and answer you all,

@Spikepl

The requirements are ANY sort of structure at all. Currently they're all sharing excel worksheets which about made me puke when i found out. The ASP.net thats being developed is extremely basic with a single form that has tabs for different functionality within the lab. There will be a max of 50 people using it. Its on an internal network. There is no remote access needed. Most of the calculations take place within the excel sheets and need to be stored.

@ Lightwave,

I would have to agree with you on an Access/SQL being a far easier approach. I've already developed a full version of a database we would need at my previous job, which makes me think that i should just retrofit it to our needs, update it with the information and present as.... Oh look. Here you remember all those things that you've been waiting months for in asp.net? Its already done here. Business' want results, and if you give it to them upfront, they tend to be tempted to go that way.


@ TechNellie

I dont' see it as a weakness but as a developmental hurdle considering are two of us who are studying our asses off to try and get up to speed with this database. There is a single guy who's developing it and he's already using a schema that was handed down from our parent company and is fraught with bad database design. Also, he's basically just done the basic framework for it. There's very little functionality to it. (no reporting functions, no graphing, Hell it doesn't even have a way to filter tables) While access is the database for dummies version of enterprise level databasing. Our needs aren't enterprise level. We just need a way to quickly/simply present data to engineers. And this database thats already being developed is nowhere near where it needs to be.
 
Because I work with Access and VBA (more than I'd like), as well as other platforms. I also have customers who I deliberately gave an Access Database backend to because it was the best fit for what they needed.

Access is limited, so is VBA, but they're great low price, simplified offerings that let people get decent Database solutions up and running without having to spend thousands of pounds on developers, support staff, hardware or software infrastructure. You don't even need Access on the client PC to be able to run an Access Database application as long as its running Windows 2000 or later. That's about as low maintenance as you can get and I won't fault it for that.

I stand by the statement that it encourages terrible practices, but the flip side of that is that it has a fairly shallow learning curve as a result.
 
#6

OK, so we are at ground 0. I would have to agree with Lightwave that ASP.NET is a too complex a solution to get something simple running ASAP, and it throws away all the the reporting/ex-/importing etc capabilities of Access. What were the reasons for starting up in ASP.NET? Perhaps because that was the only thing the programmer knew?

Your ammo:


  • Simple import/export from/to Access - no uploads/downloads, no need to run a web server
  • Built-in graphing capability, or easily done after export to Excel
  • Extensive reporting capabilities (that can also be made in ASP.NET, at a bit more effort than in Access)
  • Your familiarity with Access and unfamiliarity with ASP.NET/SQL server (ie lower cost than the rather steep learning curve for ASP.NET, quick turnaround for changes/extensions, easy integration with Outlook, for sending reminders, collecting data etc)
  • If capacity insufficient, can be migrated to SQL server later
  • If external access required later - can be established using terminal server (hardware or software), or using gotoAssist, TeamViewer, some flavour of VNC, or LogMeIn.
  • If they claim that Access is too expensive, because each work station would need it, that is not true. A free runtime version can be installed.
 
Last edited:
I agree,

They're definitely at ground zero which is making me truly deliberate what we should do here. Their reason for using ASP.NET was that the parent company on the east coast had developed a similar platform and when a need arose for our department on the west coast, they simply said, "Well just take the platform we already have and retrofit it to your needs." Without any support development wise. They simply hired an external guy to come in, take a look at our data, and then go from there.

Thanks for your ammo Spikepl. Much appreciated and will definitely be useful in my approach moving forward. I have a feeling that it will probably be beneficial to continue learning ASP.NET and SQL, but for the short term building an Access database for them with an SQL backend.

Which won't take me long to do.
 
Lancruiser, I agree with Spike and yourself based on what you're saying that Access is probably not a bad starting point if not a perfectly acceptable solution. Especially if you've got a pre-built front end application that would save you re-inventing the wheel in preference to delivering a few tweaks in certain areas.

I think seeing Access recommended as the preferred solution for a complex implementation in preference just made my brain leak out of my ears a bit :).

Learning [ASP].NET when you've got the time to do it is one thing, trying to learn it to implement a live solution that people are going to rely on in a short timescale with limited support and crap specs coming from up on high probably isn't a recipe with a happy outcome.

Done right Access is a perfectly fine front end to a.n.other database platform in any case, yes it's limited, but the inbuilt reports and if you squint hard enough the form builder does allow some fairly decent stuff to be built.
 
Firstly, Access does not need to be slow particularly if you use persistency.

Web performance using whatever technology depends on the concentration of web sites each web server and the amount of traffic on that server.

I have seen 10,000,000 hits with 3,000,000 pages read on a web site with a Jet database at the back-end. The performance of the site was fast because it was on serious, expensive hosting company that provided 1Mbit bursts.

Correct if I'm wrong - many deployments of web based application validation requires the page to be posted and not on each input field. ASP.net needs readers and adapters which seem rather perscriptive and rigid. The web site was just the public face of the organisation.

There is a steep learning curve to understand ASP and whilst the web site project was highly successful, its rakings performed well within the Search Engines but it was a task and a half to get it to work.

My personal preference is to use a Terminal Server mainly because you can provide a business-wide global solution that embraces not only a database solution, you can yield corporate emails, documents, spreadsheets, images and any other information. Any doubts about Access corruption over a WAN can mitigated by Session Timeouts. Using remote desktop you can even start a session on one PC and resume it on another.

With a Terminal Server the data requests are all local to the file server so there is no performance degradation. All that is transmitted across the WAN are the screen dumps. Local printers can be used and printing can be performed to remote printers, slower that local printing.

A web deployment of just the database is really just transferring one piece of the jigsaw to another platform. There needs to be investment in a Terminal Server but with 50 users it is worth investigating but it does mean that an organisation has to make a committment to the project.

I have developed in Access, ASP classic and ASP.net and I would still opt for a Terminal Server because it provides a comprehensive solution.

Simon
 

Users who are viewing this thread

Back
Top Bottom