A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

dotnet windows forms vs. Access



 
 
Thread Tools Display Modes
  #1  
Old June 3rd, 2007, 05:10 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

I just wonder if I am wasting my time learning VS 2005.

I've developed in Access for a long time, and seek out advanced work
which invariably requires complex unbound data entry forms connected
to a MS SQL back end.

Taking a hard look and experimenting with dotnet 2.0 and Visual Studio
2005 to see if dotnet Windows forms might be a good alternative for
these specific kinds of jobs, so far it doesn't seem so. My impression
thus far is it's great for quick and dirty jobs, but not complex ones.

What do you guys think? Better to stay with Access and SQL Server or
not?

Peter
  #2  
Old June 3rd, 2007, 07:40 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Baz
external usenet poster
 
Posts: 380
Default dotnet windows forms vs. Access

I assume you are talking about VB.Net and Windows forms. I'm not sure why
you think that it's only for quick and dirty jobs, it's pretty powerful,
although a pig to learn. My dislike for VB.Net (and Visual Studio) is such
that I have recently been experimenting with Delphi, although I haven't gone
far enough yet to be able to recommend it.

If you are mainly using unbound forms, forget about Access. Using Access to
build unbound forms is like taking a sledgehammer to crack a nut. However,
I am curious as to the circumstances in which you feel you need to go
unbound. It is rarely necessary in my experience.

"PMK" wrote in message
...
I just wonder if I am wasting my time learning VS 2005.

I've developed in Access for a long time, and seek out advanced work
which invariably requires complex unbound data entry forms connected
to a MS SQL back end.

Taking a hard look and experimenting with dotnet 2.0 and Visual Studio
2005 to see if dotnet Windows forms might be a good alternative for
these specific kinds of jobs, so far it doesn't seem so. My impression
thus far is it's great for quick and dirty jobs, but not complex ones.

What do you guys think? Better to stay with Access and SQL Server or
not?

Peter



  #3  
Old June 3rd, 2007, 08:18 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
wrote:

I assume you are talking about VB.Net and Windows forms.


Or C#.Net, etc., yes.

I'm not sure why
you think that it's only for quick and dirty jobs, it's pretty powerful


I didn't say only, and it's just a first impression - that is one of
the reasons I was asking for other opinions, but it is because you can
drag and drop so easily, including data connections - makes it easy to
knock off a simple application especially using datagrid type
controls, yet I am finding it unwieldy to deal with those very same
data controls - datasets, etc., manually.

although a pig to learn. My dislike for VB.Net (and Visual Studio) is such


What don't _you_ like about VB.net and VS?

that I have recently been experimenting with Delphi, although I haven't gone
far enough yet to be able to recommend it.

If you are mainly using unbound forms, forget about Access. Using Access to
build unbound forms is like taking a sledgehammer to crack a nut. However,
I am curious as to the circumstances in which you feel you need to go
unbound. It is rarely necessary in my experience.


I saw your comment about that elsewhere. I don't know why you feel
that bound forms is such a huge benefit of Access, but anyway, I use
unbound a lot primarily because I find it makes validation so much
easier and avoids the complexities of undoing an edit or reversing the
addition of a new record, particularly in a sub form.

"PMK" wrote in message
.. .
I just wonder if I am wasting my time learning VS 2005.

I've developed in Access for a long time, and seek out advanced work
which invariably requires complex unbound data entry forms connected
to a MS SQL back end.

Taking a hard look and experimenting with dotnet 2.0 and Visual Studio
2005 to see if dotnet Windows forms might be a good alternative for
these specific kinds of jobs, so far it doesn't seem so. My impression
thus far is it's great for quick and dirty jobs, but not complex ones.

What do you guys think? Better to stay with Access and SQL Server or
not?

Peter


  #4  
Old June 3rd, 2007, 09:42 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Baz
external usenet poster
 
Posts: 380
Default dotnet windows forms vs. Access


"PMK" wrote in message
...
On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
wrote:

I didn't say only, and it's just a first impression - that is one of
the reasons I was asking for other opinions, but it is because you can
drag and drop so easily, including data connections - makes it easy to
knock off a simple application especially using datagrid type
controls, yet I am finding it unwieldy to deal with those very same
data controls - datasets, etc., manually.


Hang on, you want to use unbound forms and yet you are trying to use
data-bound controls? Sounds like a contradiction to me. Data-bound
controls in Windows forms are indeed clumsy and cumbersome compared to
Access, and if that's what you want stick to Access. The datagrid is
absolutely hopeless when you compare it to what you can do in Access using
linked subforms and continuous forms.


What don't _you_ like about VB.net and VS?


It's a pig to learn. MS appears to have taken every concept in OO
programming known to mankind, and then some more that no-one had ever heard
of, and shoehorned them all into dotnet. It's an over-complex, overblown
smorgasbord of stuff that no-one needs. I hate the colossal dotnet
framework. And I hate the fact that MS killed off "classic" VB, the world's
most popular programming environment, in the face of fierce opposition from
hundreds of thousands of programmers.

I saw your comment about that elsewhere. I don't know why you feel
that bound forms is such a huge benefit of Access, but anyway, I use
unbound a lot primarily because I find it makes validation so much
easier and avoids the complexities of undoing an edit or reversing the
addition of a new record, particularly in a sub form.


Maybe you saw my comment about it elsewhere because you cross-posted!

Bound forms (and reports) are the ONLY benefit of Access. In particular,
Access' two most wonderful features are linked subforms and continuous
forms, both of which go out of the window when you use unbound forms. This
is NOT a criticism of Access, on the contrary, I would rarely use anything
but Access for database applications because nothing else even comes close
to it.

However, if I wanted to build something that consisted of all or mostly
unbound forms then I would even use VB.Net in preference to Access. In
order to achieve it's wonderful bound-forms capabilities Access comes with
all sorts of overheads, and if you don't want bound forms then you don't
need the overheads, as simple as that. If you want an analogy, building
lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you
prefer) and never taking it out of the city. It works, but at a cost which
you don't need to incur.

How do unbound forms make validation easier? In a bound form you just stick
all your validation in the form's BeforeUpdate event procedure and you're
done. Undoing an edit? Press the Esc key (or click Undo on the menu).
Reversing the addition of a new record? Delete it. How else would you do
it? If you add a record through a bound form or an unbound form you still
need to delete it if it's a mistake. With a bound form you can do these
things without having to write a line of code, with unbound forms you have
to program all of these functions. How is that easier?

You are using unbound subforms? How, exactly?


  #5  
Old June 3rd, 2007, 10:22 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Tore
external usenet poster
 
Posts: 2
Default dotnet windows forms vs. Access

I have done a lot of Access clients to SQL Server and find it very powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.

My experience is that Access takes a lot less programming effort (in
manhours) compared to vs.net to implement the same functionality. I find
this to be the big advantage of access. Some of the wizards in access are
quite powerful and will require a lot of manual coding in vs.net, especially
if you dont have a big library of vs. classes that you can reuse.

Access .adp client works fine when the client and the server are within the
same intranet. Vs.net provides the possibility to make powerful windows
clients communicating with sql server over the internet.

If you are familiar with access you can reuse a lot of your knowledge in
making access clients to sql server.

An access project (.adp file) is usually connected to the SQL Server at all
times while it is open. Each connection cause some load on the server. I
have never tried thousands of .adp clients connected to the same sql server,
but finally the load from idle connections could cause a problem.

Vs.net provides a wider set of mechanisms to tune the load on the server
(Disconnect when the connection is not needed) and provide better solutions
for large number of users.

Access usually requires the user to have an valid access user licence
(Office etc) and each client therefore has some cost. VS.net clients are
free once they are developed.

Unbound data entry forms is no problem with access. It requires some coding
in VBA, and it is not difficult to learn.

Regards

Tore





"PMK" wrote in message
...
I just wonder if I am wasting my time learning VS 2005.

I've developed in Access for a long time, and seek out advanced work
which invariably requires complex unbound data entry forms connected
to a MS SQL back end.

Taking a hard look and experimenting with dotnet 2.0 and Visual Studio
2005 to see if dotnet Windows forms might be a good alternative for
these specific kinds of jobs, so far it doesn't seem so. My impression
thus far is it's great for quick and dirty jobs, but not complex ones.

What do you guys think? Better to stay with Access and SQL Server or
not?

Peter



  #6  
Old June 3rd, 2007, 12:48 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
Maybe you saw my comment about it elsewhere because you cross-posted!


Comments on the topic at hand later, but I think in this case cross-
posting was warranted, as I wanted input from different groups of
users: Access and .net, most of whom probably don't read both groups.

Cross-posting, as opposed to multi-posting, is not inherently evil in
my book. However, I'm not going to drag this out - that's my only
comment I'm going to (cross)-post. ;-)

And the comment I saw about bound forms being a major advantage of
Access - I think it was yours - , was in a thread a few weeks ago but
I just came across.

Peter
  #7  
Old June 3rd, 2007, 02:13 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
wrote:

Hang on, you want to use unbound forms and yet you are trying to use
data-bound controls? Sounds like a contradiction to me. Data-bound


I can see why. However, I was/am looking at alternatives to the way I
have been doing things.

controls in Windows forms are indeed clumsy and cumbersome compared to
Access, and if that's what you want stick to Access. The datagrid is
absolutely hopeless when you compare it to what you can do in Access using
linked subforms and continuous forms.


Bound forms (and reports) are the ONLY benefit of Access. In particular,
Access' two most wonderful features are linked subforms and continuous
forms, both of which go out of the window when you use unbound forms. This
is NOT a criticism of Access, on the contrary, I would rarely use anything
but Access for database applications because nothing else even comes close
to it.

However, if I wanted to build something that consisted of all or mostly
unbound forms then I would even use VB.Net in preference to Access. In
order to achieve it's wonderful bound-forms capabilities Access comes with
all sorts of overheads, and if you don't want bound forms then you don't
need the overheads, as simple as that. If you want an analogy, building
lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you
prefer) and never taking it out of the city. It works, but at a cost which
you don't need to incur.

How do unbound forms make validation easier? In a bound form you just stick
all your validation in the form's BeforeUpdate event procedure and you're
done. Undoing an edit? Press the Esc key (or click Undo on the menu).
Reversing the addition of a new record? Delete it. How else would you do


That won't work with subforms, and with multiple subforms the coding
to deal with all the various errors a user could make in any of
multiple fields which will cause the record to save is extremely
difficult, time consuming and gives a less satisfying result than
unbound forms. I do admit to a fondness for unbound forms in general,
as I have found it is easier to create idiot proof forms that way.

it? If you add a record through a bound form or an unbound form you still
need to delete it if it's a mistake. With a bound form you can do these
things without having to write a line of code, with unbound forms you have
to program all of these functions. How is that easier?
You are using unbound subforms? How, exactly?


In Access, local temporary tables. With ADP it can get tricky.
Sometimes SQL temp tables, sometimes permanent tables that simply hold
the subform info on a temporary basis until it gets saved, or a
combination of both.

I appreciate your other comments and thoughts.

Peter
  #8  
Old June 3rd, 2007, 02:21 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote:

I have done a lot of Access clients to SQL Server and find it very powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.


Tore,

Can you give me a few examples?

Peter
  #9  
Old June 3rd, 2007, 04:21 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Norman Yuan
external usenet poster
 
Posts: 105
Default dotnet windows forms vs. Access

If the topics/examples are limited in database applications, here mentions a
few in general:

- All sorts of web applications. MS Access app (*.mdb/*.accdb/*.adp) is
typical desktop client application. You cannot create web application with
it, either client side or server side. Do not mention Access DAP, it is
useless.

- Server/Client application(web app or win form app). .NET provide
complete set of infrastructure for server side development and client side
development (web client, win form, mobile device), which is used by VS
(VB.NET or C#), whilw Access is only client side desktop IDE/app.

- Even limited on Win form desktop app, with .NET you can easily develop
desktop app that uses all sorts of resources on the network (intranet and
the Internet) via Web Services/Remoting/WCF.

- Multiple tier enterprise system development...

As a development tool, VS is a lot richer that Access, as whole.
However, there is situation, your unique situation, where Access is the most
suitable tool to use. To make correct choice of development tool between VS
and Access, one need to know both Access and .NET (note, I say .NET, rather
than VS) well.


"PMK" wrote in message
news
On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote:

I have done a lot of Access clients to SQL Server and find it very
powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.


Tore,

Can you give me a few examples?

Peter



  #10  
Old June 3rd, 2007, 05:10 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Jim Rand
external usenet poster
 
Posts: 8
Default dotnet windows forms vs. Access

I've relied on Access supercharged with VB data marshalling since 1999.
Incredibly fast development, outstanding network performance (125 times
standard Access) coupled with 100% reliability.

Three years ago, I started transitioning to .NET. A lot of study and
experimentation has resulted in fast development, great performance and 100%
reliability. The end product looks better and is far more flexible. You can
do things in .NET that you can't do in MS Access using multi-threading.
Plus, with the extensive framework library, you have more to work with for
complex tasks.

There are some downsides. Plan on a long learning curve. VS 2005 is a real
performance pig (compared to VS 2003). Support from Microsoft is mediocre -
the little guys really try harder. All that aside, I'm happy with the
outcome and will not go back to Access.

An interesting comparison would be between .NET and Delphi 2007 for Win32.
I suspect the later might be a better choice.



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 04:44 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.