ASP - What's the point?

[yhgtbfk]

Yes, this is an ASP question, but it is also an access question.

I have finished a database, but it is more of an application. It is heavily reliant on visual basic and controls. I am happy with it,

The manager thinks it should be a web page (??)

I know ASP can interact with Access and be a front end, but Im struggling to find a point in using it.

So what Im after are reasons why NOT to use ASP. What are the limitations. I have read about people saying that access is the best front end for access, so please tell me why this is.

As a side note, and probably not relating to access, but no doubt something you may have encountered:-

What is the best way to do professional database applications?

Is it access?
Is it access with something else?
Is it something else?

Thank you

 

[Pace]

Hi,

This old argument again egh... well to start with in my opinion their is no best application, its horses for courses.

Access is the best fron end for Access... bescause its Access...

Now Access also makes a great fron end for SQL Server. But you could always have a web based UI.

ASP is great, much better than PHP but PHP is a lot easier to learn. Are you struggling because you just dont know it ? Why does he want it as a web page?

With regards to your question about the most professional way to do a database application again this vaires depending on your requirements of the app.

For example if you had a web only application than something like PHP & MySQL would be best.

If you had a application that is needed by say between 5 and 10 users then Access would be great. If you had 30+ users than you should consider something like SQL Server or Oracle (for me its SQL all the way )

hth

Pace

 

[Pat Hartman]

I am always leary of requests for technology for technology's sake. Unless you have to provide access to your application to users who cannot install Access and your application's .mdb, I simply wouldn't recommend it. IMHO, a web interface sucks compared to a rich client interface. You will loose subforms, reports, and various other things. Not to mention the fact that Access(or specifically Jet) is a FILE manager not a Database manager. Just because you can use Jet as a back end to a web page doesn't mean that you should. I would ONLY use Jet as the be to a web page if the primary application were an .mdb and one or two features needed to be exposed to the world at large. Then it makes sense to leave the main application as it is and just add a few web pages for viewing or remote data collection.

I know that many people here actually use Access as the be for their web pages but they do it because they need to reach users outside of their organizations.

 

[yhgtbfk]

ASP is great, much better than PHP but PHP is a lot easier to learn. Are you struggling because you just dont know it ?

Yes, it is a learning curve. Its like, OK, Ive created this database in access, now how to I make it work on the web.

Why does he want it as a web page?

Look and feel. I dont want to compromise all the things Pat mentioned above simply because of look and feel. Its kinda a buzz word. They throw around terms without understanding what it is. Yet they drive my work.

If you had 30+ users than you should consider something like SQL Server or Oracle (for me its SQL all the way )

I think I might learn this.

1/ Can it do everything access can in terms of structure, coding, forms, reports, queries, etc..?
2/ Where would be the first place on the net I will go to learn about it?

I am always leary of requests for technology for technology's sake.

I hear ya!

I simply wouldn't recommend it. IMHO, a web interface sucks compared to a rich client interface. You will loose subforms, reports, and various other things.

I know that many people here actually use Access as the be for their web pages but they do it because they need to reach users outside of their organizations.

Exactly. All good points. I think I might use them.



Has anybody else had similar experiences?

"Sorry sir, but it cant be a web page. Please dont fire me"

 

[wazz]

"Sorry sir, but it cant be a web page. Please dont fire me"

funny.

but, i guess it isn't, is it?

it looks like you've thought of this already, but, can i just say, if you are concerned about how the boss will react, get hard copies of these posts and as many (related) others as you can find and use them to help explain what's what. (there are many many posts here regarding upsizing, etc. use them to your advantage. maybe a raise should be in order if you save the company from wasting its time/money!)

 

[KenHigg]

IMHO - In order to divide and conquer the enemy, I would search out the strengths as well as the weaknesses. The weaknesses have be pretty well covered....

The main upside to ASP is deployment. Anyone with a browser can use it. They can hit live data. The app is loaded on the web sever and you're done. The front end is brought over into the web page every time the user requests it. (all of this of course is a bit qualified)

You do lose a lot of the robust features of having the FE on the local machine, but the trade-off can sometimes be worth it. For example, if all you need is a simple data entry form, asp is great - Much easier than trying do deploy a FE to hundreds of workstations....

In a nut shell, I suggest you put a rope around the BIG picture before you pro or con anything...

IMHO

 

[Crilen007]

I use PHP and MySQL for any web databases I have to create. They link to access pretty good. So I can have the entry online, and the reports on the program.

However... I am looking at putting a major database online (Has confidential information, but the locations that need to view it are like 8 hour drive + away)..

I was thinking of using VPN, with ACcess front end, and MySQL back end.

Does that sound right?

If I did it using PHP, I would have to have good user authentication.

My only question is, when using PHP, how do I create reports that fit haha.


Sorry if I jacked this post, but I figured my question was kind of similar. Perhaps it will help him too.

 

[KenHigg]

If I'm not mistaken, VPN does a local cert type deal. Where you download and register a local security certificate. I may be wrong on this but seems thats how I got access to get behing my co's firewall from my home pc. So while it should be secure, seem it would be a challenge to admin. if your users/locations change a lot...

As far as using access as a fe via long distance, I would say it sounds fine as long as you do a the processing on the be / sever side, jet doesn't do a very good job on slow to meduim speed internet...

 

[Crilen007]

Hence the MySQL BE.

 

[Kodo]

I've built quite a few ASP FE/Access BE applications before and there are lots of pro's to it as well. With the use of some client-side scripting, you can maintain features such as masks etc.

I used it to avoid pushing out a FE/BE scenario, to control security OUTSIDE of access' horrible excuse for what it calls security and to make things easier to maintain all-around. Now, ASP.NET would be an even better solution as it more closely ties in Desktop type usability with the web environment.

I've also done combinations of using the MSDE or SQL 2000 and an ADP in conjunction with an ASP FE for those who would VPN or otherwise have access outside of the facility and could only get to the secured site.

DO use the JET driver when using ASP.

You will loose subforms, reports, and various other things

no, no and maybe. Yes, you will have to put a little extra work into it but with CSS, you can build a report that ROCKS compared to access. You could build a template report format that is used when building the report upon request. Iframes are a good substitute for subforms. The other various things I would have to answer separately. Obviously there are limitations but the first two you stated, I have to disagree with.

[edit]
On a sidenote, for those who are not aware, MS has a report service for sql server now.

 

[KenHigg]

If I was a company owner, I would approach these types of decisions from a very high level and let the business model dictate what technology to use. i.e If long term plans were to drive more sale personel into the fld, I'd do web based stuff for their needs,or if a segment of my workforce required consolidation where tighter platform control was avail and bandwidth was not a problem, I might do custom FE/BE stuff. Then once all this is defined, do the back office stuff to support it...

Much too complex to decide based on forum chit chat, but a great place to get ideas...

IMHO

 

[Pat Hartman]

I'm going to jump back in here with a few questions.
1. If the manager thought the application should use a web front end rather than Access forms, why didn't he mention that in the beginning?
2. Does the manager understand the difference between interface and data. If he's an Excel user, this may be confused in his mind.
3. Does the manager know the difference between Access (the rapid application development environment) and Jet the database engine? Did he tell you to build an Access application and he was thinking Jet and you were thinking GUI? I blame this on Microsoft for not creating more of a separation in people's minds. Access is two applications and most people simply do not understand the distinction.

What is the best way to do professional database applications?

Is it access?
Is it access with something else?
Is it something else?

There are many tools with which to create professional client/server database applications and Access is just one of them. However, there isn't a better RAD tool on the market. The Visual Studio product is getting better but it's not there yet. You can build the same application in VB, C++, and Access and chances are very good that the Access application will be the shortest development time.

I happen to really like the combination of an Access front-end to an ODBC back-end. Here I think you get the best of both worlds. You get an easy to use development environment and a robust database manager that can support huge numbers of users and large volumes of data thereby removing all the limitations that people ascribe to Access which are in fact, limitations of Jet.

 

[yhgtbfk]

I'm going to jump back in here with a few questions.
1. If the manager thought the application should use a web front end rather than Access forms, why didn't he mention that in the beginning?
2. Does the manager understand the difference between interface and data. If he's an Excel user, this may be confused in his mind.
3. Does the manager know the difference between Access (the rapid application development environment) and Jet the database engine? Did he tell you to build an Access application and he was thinking Jet and you were thinking GUI? I blame this on Microsoft for not creating more of a separation in people's minds. Access is two applications and most people simply do not understand the distinction.

1/ The manager doesnt understand front end back end. He also sees terms like a 'web page' as a buzz word. You know the feeling you get when you have your very own web page and you say to everybody 'Hey guys, I have a web page!'. Its that kind of mentality.

For reasons far too difficult for me to explain, the database overlaps our internal web page. So rather then compromising the internal web page, he would rather my application become web based. Again, dont try to udnerstand it cos I really cant go into it.

But it is a dynamic business solution heavily reliant on MS access features. And while ASP can read and write data in a simple interface, this is extremely complicated.

Alot of it might come down to inexperience, but there are 20,000 lines of code and about 40 forms. And alot of the forms are constantly reaching data from tables and running code everytime the user clicks a button or uses a drop down list. The amount of resends to the server will be painful.

2/ No, he doesnt understand the difference between interface and data. And he is also the type to specify which program it must be in when giving a proposal

3/ No. Imagine a manger hires somebody to write a program for him. He is not going to understand it, just see the end result and say 'Yay' or 'Nay'. But my manager is caught up in all these buzz words like 'web page' and 'database' etc... without even knowing what they mean.

 

[Pat Hartman]

Sad but this is where job security comes in. If he's willing to get you a little training or let you stumble through it yourself, build a web front-end. Perhaps after he sees a cost estimate and a comparison of functionality he will reconsider.