By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,677 Members | 1,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,677 IT Pros & Developers. It's quick & easy.

Access vs Visual Studio dot.net

P: n/a
Hi everyone.
I am an Access developer having worked with Access-dev. projects for
many years on Sql server databases and Access.
For the internet I have been using traditional asp.
But now I have tried asp.net and this tool seemes great to me.

Haven't tried Vb for Visual Studio net, but hope to do that in the very
future.
Hope that this version of vb goes well together with asp.net although I
don't know how.

However I am therefore thinking about leaving Access for working with
Visual studio dot.net for new projects.

So folks: Do you think that I am doing the right thing moving to Visual
studio dot.net?

Nov 13 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On 3 Feb 2005 23:57:02 -0800, ol**@ylm.se wrote:
Hi everyone.
I am an Access developer having worked with Access-dev. projects for
many years on Sql server databases and Access.
For the internet I have been using traditional asp.
But now I have tried asp.net and this tool seemes great to me.

Haven't tried Vb for Visual Studio net, but hope to do that in the very
future.
Hope that this version of vb goes well together with asp.net although I
don't know how.

However I am therefore thinking about leaving Access for working with
Visual studio dot.net for new projects.

So folks: Do you think that I am doing the right thing moving to Visual
studio dot.net?


I wouldn't want to say if it was "right" or not. Access is still the best
tool for many jobs, but if those aren't the jobs you are doing, the .NET or
Java platforms provide better languages and development tools.
Nov 13 '05 #2

P: n/a
ol**@ylm.se wrote:
So folks: Do you think that I am doing the right thing moving to Visual
studio dot.net?


I think you have done the right thing moving away from Access.

There may not be so many great places to move.

In the long run it may not have been wonderful for the developer that MS
bought FoxPro, that CA bought Clipper. Who knows what marvels we might
have now had these products made the move to a GUI by themselves?

I may take a another look at FoxPro, 12 years after I abandoned it. I'm
looking at various "J" things.

I'm beginning to think that all the hoopla about client-server dbs like
MS-SQL may be just that, hoopla, and that for many developers the use of
file dbs, with home-grown security may be allow superior development.
The logic of combining data, indexes, procedures in the same file has
lost its validity with me. Why? Huh? To protect us from ourselves?

I am very disillusioned with MS.

--
--
Lyle
--
From ADO28.chm

Deprecated Components
Each of the following components is considered obsolete. While these
components are still supported in this release of the Microsoft® Data
Access Components (MDAC), they may be removed in the future. When
writing new applications, you should avoid using these deprecated
components. When modifying existing applications, you are strongly
encouraged to remove any dependency on these components.

ODBC Provider (MSDASQL)
You are strongly encouraged to use one of the native OLE DB Providers
instead of the Microsoft Open Database Connectivity (ODBC) Provider.
Native OLE DB Providers provide better application stability and
performance. Furthermore, native OLE DB Providers will be supported in
the future, whereas MSDASQL will not have any new features added to it,
will not be available on 64-bit, and will not be accessible from the OLE
DB NET Data Provider.

Remote Data Services (RDS)
Remote Data Services (RDS) is a proprietary Microsoft mechanism for
accessing remote data across the Internet or intranet. Microsoft is now
shipping the Microsoft Simple Object Access Protocol (SOAP) Toolkit 2.0
that enables you to access remote data using an open, XML-based
standard. Given the availability of the SOAP Toolkit 2.0, you should
migrate from RDS to SOAP. The SOAP 2.0 Toolkit 2.0 also includes sample
code for remotely accessing Microsoft ActiveX® Data Objects (ADO)
Recordsets.

Jet and Replication Objects (JRO)
The Microsoft Jet OLE DB Provider and other related components were
removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet
Engine, and plans no new releases or service packs for this component.
As a result, the Jet and Replication Objects (JRO) is being deprecated
in this release and will not be available in any future MDAC releases.

.....
Nov 13 '05 #3

P: n/a
I have been doing both MS Access and ASP.NET (using VB.NET) for the
past few years. I have not used the .NET platform to create a "Windows
forms" client/server application but I have looked at it. I would say
the following:

*Going from to VB to VB.NET will be no problem for you from a syntax
point of view. You will, however, need to learn the incredibly vast
object libraries (or "namespaces") in the .NET platform. To benefit
the most from the .NET platform, you may also want to brush up on some
of your object-oriented programming concepts. A good book will be
extremely valuable.

*If you develop a windows forms app for .NET, your client machines will
all need to have the .NET framework installed. This isn't a big deal
for a customer with all new equipment but it may be in many other
situations. Note that this isn't a problem for ASP.NET web apps where
only the server needs the .NET framework.

*Remember that "Access" is both a database (Jet) and a tool for
creating a user interface all wrapped up in one. You will still need a
database when developing in .NET just as you did when using VB6. MS
Access (Jet) could be the database that you use in certain situations
so don't abandon MS Access.

*With Visual Studio.NET 2002/3 you had to recompile your project every
time you made a change to your code. This makes debugging a lot slower
than it would be in MS-Access where you can actually change the code
while you're stepping through it. I believe that you will be able to
do this with the new VS 2005 (Whidbey) for windows forms apps.
Unfortunately, we ASP.NET developers will still need to recompile (or
at least wait for the automatic compilation) as far as I know.

*You will love the tools for working with SQL Server contained in
Visual studio.NET. You can even step through and debug your stored
procedures and user-defined functions. I use VS.NET almost exclusively
to do database design and I'll bet that you will too after trying it.

*For simple applications, using .NET will be overkill. In MS Access,
you have a few simple controls that you can customize as needed--few
choices and no confusion about what to use. In VB6, you have libraries
of controls from which to choose and weave into an application. You
can also use third party controls. From what I see from .NET windows
apps, the choices are even larger (and better). Your development time
will increase without a doubt.

Therefore, I would say that you should absolutely without question
learn the .NET platform and learn to create applications in .NET.
However, don't abandon MS Access. Keep both tools in your toolbelt and
use each of them appropriately.

Bill E.
Hollywood, FL
ol**@ylm.se wrote:
Hi everyone.
I am an Access developer having worked with Access-dev. projects for
many years on Sql server databases and Access.
For the internet I have been using traditional asp.
But now I have tried asp.net and this tool seemes great to me.

Haven't tried Vb for Visual Studio net, but hope to do that in the very future.
Hope that this version of vb goes well together with asp.net although I don't know how.

However I am therefore thinking about leaving Access for working with Visual studio dot.net for new projects.

So folks: Do you think that I am doing the right thing moving to Visual studio dot.net?


Nov 13 '05 #4

P: n/a
Thanks for all the good advice.
They are very valuable for me.
/Regards BigOlle

Nov 13 '05 #5

P: n/a
bi********@netscape.net wrote:
I have been doing both MS Access and ASP.NET (using VB.NET) for the
past few years. I have not used the .NET platform to create a "Windows
forms" client/server application but I have looked at it. I would say
the following:

*Going from to VB to VB.NET will be no problem for you from a syntax
point of view. You will, however, need to learn the incredibly vast
object libraries (or "namespaces") in the .NET platform. To benefit
the most from the .NET platform, you may also want to brush up on some
of your object-oriented programming concepts. A good book will be
extremely valuable.

*If you develop a windows forms app for .NET, your client machines will
all need to have the .NET framework installed. This isn't a big deal
for a customer with all new equipment but it may be in many other
situations. Note that this isn't a problem for ASP.NET web apps where
only the server needs the .NET framework.

*Remember that "Access" is both a database (Jet) and a tool for
creating a user interface all wrapped up in one. You will still need a
database when developing in .NET just as you did when using VB6. MS
Access (Jet) could be the database that you use in certain situations
so don't abandon MS Access.

*With Visual Studio.NET 2002/3 you had to recompile your project every
time you made a change to your code. This makes debugging a lot slower
than it would be in MS-Access where you can actually change the code
while you're stepping through it. I believe that you will be able to
do this with the new VS 2005 (Whidbey) for windows forms apps.
Unfortunately, we ASP.NET developers will still need to recompile (or
at least wait for the automatic compilation) as far as I know.

*You will love the tools for working with SQL Server contained in
Visual studio.NET. You can even step through and debug your stored
procedures and user-defined functions. I use VS.NET almost exclusively
to do database design and I'll bet that you will too after trying it.

*For simple applications, using .NET will be overkill. In MS Access,
you have a few simple controls that you can customize as needed--few
choices and no confusion about what to use. In VB6, you have libraries
of controls from which to choose and weave into an application. You
can also use third party controls. From what I see from .NET windows
apps, the choices are even larger (and better). Your development time
will increase without a doubt.

Therefore, I would say that you should absolutely without question
learn the .NET platform and learn to create applications in .NET.
However, don't abandon MS Access. Keep both tools in your toolbelt and
use each of them appropriately.

Bill E.
Hollywood, FL
ol**@ylm.se wrote:
Hi everyone.
I am an Access developer having worked with Access-dev. projects for
many years on Sql server databases and Access.
For the internet I have been using traditional asp.
But now I have tried asp.net and this tool seemes great to me.

Haven't tried Vb for Visual Studio net, but hope to do that in the


very
future.
Hope that this version of vb goes well together with asp.net although


I
don't know how.

However I am therefore thinking about leaving Access for working


with
Visual studio dot.net for new projects.

So folks: Do you think that I am doing the right thing moving to


Visual
studio dot.net?


I am also trying to learn visual studio.net and asp.net. I have done a
lot of development in Access and am very comfortable with it and its
events, vba and modules.

Any suggestions for good books or online tutorials for an access retred
like me?

I have also been investigating conversion software to convert Access
databases and forms to dot net. Have you had any experience with any of
these?

Bob alston
Nov 13 '05 #6

P: n/a
Bob,

Given that Visual Studio 2005 and .NET framework 2.0 are sheduled for
release (not Beta) this summer, I'm not entirely sure where to tell you
to start. Would it be better to start with the 1.1 framework and
VS2003 or jump straight into the VS2005 beta? Perhaps you should start
with the former to give you a good background.

There are so many books out there. Perhaps you should post a question
in the ASP.NET groups to get some guidance. Try

microsoft.public.dotnet.framework.aspnet for web applications (ASP.NET)
and
microsoft.public.dotnet.framework.aspnet (windows forms)

By the way, I think that you will need to make a decision as to whether
you want to learn to make windows forms apps or web apps. If you have
no experience making web applications, you will have some additional
learning to do simply because web apps are designed differently,
whether you use .NET or not. Also, the portions of the .NET framework
you will learn will be different for each, although there will be a lot
of overlap.

I've never used any conversion software for Access to .NET. I'm
guessing this would be MS Access converted to a Windows Forms app in
..NET I'm not sure that I would recommend using it. Even if it works,
it couldn't possibly be optimized. What would be the value of doing
that? Instead, I would recommend converting a MS Access app yourself
by hand as part of your learning process. I did that for my first
ASP.NET app--I took an application I had written in ASP and rewrote it
in ASP.NET. I then gave the .NET app to the client for free. They're
still using it today. I learned a lot doing that and so will you.

I hope this answers your questions.

Bill

I am also trying to learn visual studio.net and asp.net. I have done a lot of development in Access and am very comfortable with it and its
events, vba and modules.

Any suggestions for good books or online tutorials for an access retred like me?

I have also been investigating conversion software to convert Access
databases and forms to dot net. Have you had any experience with any of these?

Bob alston


Nov 13 '05 #7

P: n/a
<ol**@ylm.se> wrote
But now I have tried asp.net and
this tool seemes great to me.

Haven't tried Vb for Visual Studio net,
but hope to do that in the very
future. Hope that this version of vb
goes well together with asp.net
although I don't know how.


Just as a matter of interest -- what language have you been using to program
ASP.NET? The only languages widely used for that purpose are VB.NET and C#.
And, I'd think if you use either one, you'd have at least learned that they
aren't all that much different, anymore. ActiveX Server Pages, classic or
..NET, is an approach to creating interactive web pages, but is not itself a
programming language.

A very knowledgeable and respected (classic) VB MVP recently said about
..NET: "Three releases and it is still only useful for Web applications." If
enterprise web apps are your target market, then you need to choose between
..NET in all its glory or J2EE in all its glory. If relatively modest
individual, multiuser, or client-server apps are your target market, Access
(or Access in combination with an ODBC-compliant server database) is likely
a good choice. If you are interested in web apps something less than
"enterprise level", there are too many choices to list here.

Larry
Nov 13 '05 #8

P: n/a

"Lyle Fairfield" <ly******@yahoo.ca> wrote in message
news:s7*******************@read2.cgocable.net...
I am very disillusioned with MS.

Hey, Microsoft put you into business, so why can't they put you out of
business?
Nov 13 '05 #9

P: n/a
thanks to you all for all the clever thoughts on this subject.

I have one more question:
Is it possible to write a Windows Vs studio dot.net app. for Access or
Ms Sqlserver in a way that when you want to give users possibilities to
work on the database from the internet,
then I can with few changes move my applikation to my asp.net -
webserver?

Nov 13 '05 #10

P: n/a
Not that I know of. You would still need to create a web interface. A
windows forms interface does not just naturally translate to a web
interface. However, you could (and should) design your windows forms
app such that all business logic, data access and other functionality
are separated from the UI elements (i.e., contained in separate
classes). If you do that, you can reuse all of this in your web
application--you'll only need to replace the windows forms with web
forms.

Bill E.

Nov 13 '05 #11

P: n/a
thanks Bill.
Look forward to try developing in this way.

Nov 13 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.