Advantages of using VB.net and Access (backend)

[Louverril]

Can anyone give me the advantages and disadvantages of using vb.net front end
and an Access backend against an Access front end and Access backend.

The current totally Access 2007 application (split frontend/backend) has
about 17 tables, approx. 17 forms (inc. subforms), 37 queries, approx 64 VBA
subs/functions, 24 reports (inc. subreports). It needs “re-engineeringâ€.

Concurrent users unlikely to be more than two (2).

The only factor I’m sure of is that the VB.Net development will be more
costly however what about things like increase in support requirements??,
loss of default integration with MS Office programs??, limitations of
querying?? etc. with using .Net.

On the other hand would there be any advantages using .net – I can’t think
of any but I am not as familiar with it as some of my associates?

Thanks Lou

 

[Larry Linson]

If your users are going to be individual, accessing the application on their
own machine, or on a LAN, it would be sheer folly to "convert to .NET". I'm
not sure how you determined it "needs re-engineering", but, if so, and it is
local / LAN, you should re-engineer it in Access.

Typically, if you hire someone to convert the app to .NET, you are going to
incur expenses far beyond your expectations, and end up with an application
that is of no more (and perhaps less) utility to your business. You may also
incur the overhead of a .NET developer or few, with accompanying
infrastructure, a server database (e.g., MS SQL Server) and a DBA (all
server DBs need a certain amount of regular, routine TLC) because few
..NETters will be comfortable working with Jet or ACE databases, though you
might pay some performance penalties and use SharePoint as your datastore
(you can do that with Access, too, and SharePoint access has been improve in
Access 2007).

I would say that an application upgrade within Access ought to be perfectly
satisfactory (given the environment I described in the first paragraph), but
I'd fear that a .NET re-implementation might end up a failure, far
over-budget, and without benefits -- a potentially career-ending option.
Unless details not posted here reveal a compelling need, I'd forget the .NET
re-implementation idea.

Larry Linson
Microsoft Office Access MVP

 

[David W. Fenton]

Concurrent users unlikely to be more than two (2).

Going with anything but Access for this would be COMPLETELY INSANE.

 

[a a r o n _ k e m p f]

using VB.net with MS Access is just a joke-- if you know how to build
a front end-- using .NET- just use SQL Server

-Aaron

 

[Louverril]

Larry,

I tend to agree - that is my gut feeling - and basically I want to do it in
Access. But I am trying to get a list of clear watertight reasons why not to
do it in VB.

The software is as I describe and will need to be installed easily by a non
IT professional (via install package – which I have for Access).

I have the following reasons not to do it as VB front end and want to be
sure that I am correct:

• It will be more expensive
• It will require more IT support to install (as the various .Net elements
plus stuff like MS Data Access Components will need to be installed)
• It may require additional hardware as the system requirements for .NET are
higher than Access Runtime???
• More expensive to make simple changes.
• Loss of default links to other Office programs.
• If SQL were used instead of office loss of familiar querying options.
• If SQL Server (including Express) were used it couldn’t be installed via a
simple install package


I have had no feedback on the three forums I have added this query as to why
VB.net would be better - other than:
It is more robust – what’s not robust in Access up to at least 10 users (no
matter how badly it's written??) I have had no experience of problems with
Access – what am I missing?
You can do things you can't do in Access - like what? No one can actually
tell me.

If I do it in .NET I want a watertight technical and business reason – I
haven’t seen one yet.

Any comments on the above - are the points I have made correct?

Thanks

 

[Louverril]

David,

Please see my reply to Larry - do you have any comments to add.

Thanks

 

[Louverril]

Thanks Aaron,

There ar ereasons not to use SQL server - like the need tfor non IT person
to be able to install the system. Please see my reply to Larry - have you any
comments?

Thanks
Lou

 

[BruceM]

Aaron has one answer for everything, and at that provides little information
about how to implement his invariable, all-purpose "suggestion". Don't look
to him for useful comments.

 

[Louverril]

Thanks Bruce.

Aaron has one answer for everything, and at that provides little information
about how to implement his invariable, all-purpose "suggestion". Don't look
to him for useful comments.

 

[a a r o n _ k e m p f]

question your premises

a) is it _THAT_ hard to maintain SQL Server? it comes free, it's easy
to setup
b) SQL Server you don't need to even register a database to the server
now; it's called a 'user connection' right?
c) you can easily package SQL Server Express using the 'package and
deployment wizard' or whatever it's called
d) non-IT people are plenty capable of hitting yes, yes, next, yes.
e) it's all about future proofing. Jet is _NOT_ secure. if your db
has _ANYTHING_ to do with 'people or money' you should use SQL Server
just for security reasons.

 

[a a r o n _ k e m p f]

Bruce is a pansy that is stuck making $12/hour-- just because he
listens to the old dipshits around here
Access - as a database - is dead and it has been for a decade.

Just use SQL Server, it's the worlds most popular db.

 

[David W. Fenton]

But I am trying to get a list of clear watertight reasons why not
to do it in VB.

What's your list of POSITIVE reasons for using VB?

 

[Brendan Reynolds]

Larry,

I tend to agree - that is my gut feeling - and basically I want to do it
in
Access. But I am trying to get a list of clear watertight reasons why not
to
do it in VB.

The software is as I describe and will need to be installed easily by a
non
IT professional (via install package – which I have for Access).

I have the following reasons not to do it as VB front end and want to be
sure that I am correct:

• It will be more expensive

Yes, a lot more.

• It will require more IT support to install (as the various .Net elements
plus stuff like MS Data Access Components will need to be installed)

Well. Not so sure about this one. There might be some additional compoents
to install, depending on what is already installed, of course, but none of
it is really very complicated or onerous. I'd say it's a minor issue.

• It may require additional hardware as the system requirements for .NET
are
higher than Access Runtime???

Not convinced about this one. I think any PC capable of running the Access
2007 runtime would probably be capable of running a well designed .NET app.

• More expensive to make simple changes.
Absolutely.

• Loss of default links to other Office programs.
Yes.

• If SQL were used instead of office loss of familiar querying options.

Assuming this means SQL Server instead of JET, well, that's shifting the
goal posts significantly. The orignal question was about using VB.NET and an
Access (JET) database. If the data source becomes SQL Server, that's a whole
different discussion IMHO. On this specific point, though, well, a lot of
things that we're used to doing in queries in Access won't work anymore, but
on the upside we get access (no pun intended) to all the power of T-SQL.

• If SQL Server (including Express) were used it couldn’t be installed via
a
simple install package

SQL Server Express is not difficult to install.

I'll add to your list the loss of Access's excellent integrated report
designer and reporting engine. If you move to SQL Server you can use
Reporting Services, which works, but is complicated, and the designer is not
nearly as good as the Access report designer. Otherwise, you'll likely have
to resort to a third party reporting solution.

Bottom line, the main reasons not to do it in .NET are it will take longer
and cost more. Yes, there are things that you can do in .NET that you can't
do in Access, but that's not an argument in favour of using .NET unless you
actually have a need to do one or more of those things. If you don't have a
reason to do them, then the ability to do them if you did want to do them
isn't really a whole heck of a lot of use to you.

 

[So Sorry For Poor Aaron]

Its head is empty of all but its obsession with SQL Server. It lacks
real-world experience, it seems to think every user is an Admin, it thinks
all any user has to do is manage the database, not use it, it thinks ADP is a
real solution for everyday users not just for developer dorks, and if it
knows how easy it would be to use it, how come it doesn't even know what the
'package and deployment wizard or whatever it's called' is called. It
specializes in "answers" that don't give any specifics; doesn't help, just
purposely misleads. What is it?

It's not a bird, it's not a plane, it's not Superman. It's empty-headed
aaron with its dried-up pea brain rattling around inside its skull, making a
pest of itself again.

 

[So Sorry For Poor Aaron]

using VB.net with MS Access is just a joke

a vb.net app for this requirement is just a joke. aaron's a comedian, too.

if you know how to build a front end-- using .NET

you'd know it will be incredibly expensive, take a lot longer, and the OP's
company would have to hire a maintenance staff for it -- no, aaron sweetie,
they ain't gonna hire YOU!

just use SQL Server

aaron's a one-trick pony

 

[a a r o n _ k e m p f]

SQL Server doesn't need a DBA
not any more so than Access does.

Of course-- SQL Server is self-tuning, and it shrinks after itself.

and Access DOES NOT.

I don't need anyone to hire me, kid.. I got work coming out of my
ears.

-Aaron

 

[a a r o n _ k e m p f]

ADP is a great solution.

When a typical Access crybaby starts blaming thing on the network--
that's when you need to move to SQL Server

ADP works great over VPN, wireless, WAN and LAN.
Access is stuck in the 80s

 

[a a r o n _ k e m p f]

I'm not so sure that I agree-- Reporting Services designers-- any
version, including the Report Builder for christ sakes-- is 100 times
better than Access Reports.
Shit just works.

Bring in data from 3 different sources?

REPORTING SERVICES MAKES IT EASIER AND IT IS 100 TIME SUPERIOR TO
ACCESS