Access Front End vs VB.Net front end

[ions]

Dear Access Expert,

My client has asked my why I am endorsing Access as the Front End for his application. He thinks that VB.Net is better.

I have never programmed in VB.Net and I know Access is considered a RAD tool. From this forumn I have read that it can cut development $ and time by up to 66%.

Also from this forumn I have learned that Access Front end has some limitations when it comes to the look of the GUI. Basically we are limitted to the controls shipped with access or from third party dealers. Access cannot be web based.

I have also learned that VB.Net is more secure than the Access Front End which I do not fully understand.

I am confident that MS Access is the right solution for this client as the application is for a small business (6 concurrent users), it doesn't need to be web-based, will use LogmeIn for remote access and has to be under $10K.


Please note that I don't want to discuss the backend (Jet vs SQL Server) just the front end (Access vs VB.Net.) in this thread.

How do I convince the client that MS Access is the right platform despite all the media and hype for VB.net?

Thank you for your feedback.

Peter.

 

[Banana]

Here's a selling point.

You can in fact use .NET with Access so if he really want some .NET toy, well, he can have it on top of Access as .NET can interoperate with COM objects of which Access is capable of interacting with.

The point here is that it's much more likely that you/he will end up not needing .NET at all as Access will do what he usually needs and for less time & money. But the option is there should we actually need it.

I have a simple demo over there showing how to use .NET components. This works with a .NET library but there should be no reason why a .NET form can't be called via Access and used for data entry should Access's forms be insufficient for his needs. Just to be clear, though, you can't expect to drop a .NET control into Access form; that requires ActiveX, which builds on top of COM but with additional specifications and I would venture to say they're not worth the extra hassle. (BTW, I understand there's also a book discussing about using .NET in Access... I think that was Access 2007 Inside Out but I need to double check that)

Second point: You can tell him it's useful for prototyping and thus save on the design cost when it comes to migrate to .NET. This is in fact how many Access applications start out: As a prototype that would be eventually superseded by the newest & latest technology... except they never actually get around to do doing it because it cost too much money.

As for security, I think we need to discuss two things which are quite distinct. First, if it's the code and the IP that he's concerned, I would point out that it's actually harder to decompile MDE than it is to decompile an EXE so code in MDE is actually more secure from invasion than code in MDE. If this doesn't reassure him, you can go to everythingaccess.com and purchase MDE Code Protector for extra protection. Now, for data security, this actually depends on what we're using for back-end, rather than the front-end*. So using Jet backend will be problematic in securing data properly but with any other ODBC-compliant RDBMS, data is just as secure as it would be in any other programs. Finally, it must not be forgotten that the only users would be his employees, not random hackers. This is the network security's job and if the random hacker gets in, all bets are off, Access, .NET, whatever. Furthermore, it's not always a technology problem and thus has a technology solution. It may be in fact a human resource problem, for example and that can't be easily solved by a technological solution if he can't trust his own employees for example.

* I should clarify though, that there are caveats when developing front-end, regardless of whether we're using Access, .NET, web forms, whatever, we must ensure we do not save passwords plaintext when creating connections to the backend table among other similar measures. Basically, the security of front-end is dependent on the developer, not on the technology.

I hope this helps somehow.

 

[ions]

Thanks Banana