.net?

E

eddiec

hi everyone,

we have a sql server / access (adp) materials management system that works
fine. is there any reason in the world that we would want to move to .net
for developmnet of new modules?

any comments would be much appreciated

eddiec :)
 
D

Douglas J. Steele

As far as I know, if you decide to move to .Net, you'll have to rewrite all
of the existing application, as I don't think Access ADPs can communicate
with .Net components.
 
B

Brendan Reynolds

Access 2002 and 2003, with the help of the Office Web Services toolkit, can
call .NET web services. I've successfully used this to transfer data from a
remote database, via the Internet, into a local database. These are, of
course, very specific circumstances - I'm not suggesting this as a general
approach to Access development! :)

You can download the Office XP Web Services toolkit at ...
http://msdn.microsoft.com/library/d.../en-us/dnxpwst/html/odc_wstoolkitoverview.asp

.... or the Office 2003 Web Services toolkit at ...
http://www.microsoft.com/downloads/...8a-e1cf-48a3-9b35-169d819ecf18&DisplayLang=en
 
B

Brendan Reynolds

See Doug's post and my response. Depending on what you mean by 'modules' in
this context, it may not be possible to move new 'modules' to .NET without
moving the old ones as well.

More generally, whether you should move to .NET depends on what you hope to
gain from the move. Do you need to convert the app to a web app? Do you need
to separate the UI, business logic and data access into separate,
loosely-coupled components? Do you need to make your app accessible via
hand-held computers or mobile phones? Are your customers asking you to move
to .NET?

If you answered yes to any of the questions above, then a 'proof-of-concept'
project might be in order - pick a small sub-set of your application's
features, or even a single feature, and try to replicate that in .NET before
making any decisions about converting the complete application.
 
Top