ADP or MDB - which is a better front end for SQL Server?

  • Thread starter Thread starter Paul Ponzelli
  • Start date Start date
For MDB, they will be kept around a little more longer but only for
supporting these innumerable kitchen recipes' databases that already
Click to expand...
exists.

I wonder what they intend to do with all those recipe databases out there
then?
Even though MS may be trying to introduce new technology the need for small
databases and apps that are easy to develop won't dissappear.
I don't know much about .net but a quite a bit about Access and it serves a
huge need with it's easy development and deployment. If it disappear's it
seems to me there'll be something missing in the bottom segment of database
technology.
It'll be interesting to see what happens.

Jesper Fjølner, Denmark
 
You should be doing your recipes in XML, access if far to heavy weight, no
really access is still has the largest user base out of all the smaller
relational databases, MS cannot get rid of it for a while yet, but I have
the feeling that it is going to end up managed (.net) but who knows.
 
As you said, the real question here is the possible (future) integration of
the CLR into the JET/MDB couple. Obviously, MS won't call you at home to
remove your MDB files on your home computer but if the JET/MDB remains
inchanged, I don't see what future it could have when the next version of
Windows, Longhorn, will came out on the market.

Sometime - even when you don't want it or like it - you need to have your
program communicates with the exterior and this is especially true for
enterprise application, even when you don't need to interface with
SQL-Server. For example, when I've integrated the payment by credit card on
the Renaud-Bray web site, I didn't have any choice on the tools for doing
it. Now that VB6 is gone; the only thing that remains for making COM/COM+
components if VC++. It would be a very strange situation indeed to see MS
promoting the use of the MDB format on Longhorn without giving these
applications an easy access of communicating with the local operating system
environment. For those who are already the happy owners of a current
version of Windows, either Win95, 98, 2000 or XP; the MDB format will be
kept running for a long time (well, until the hard drive on these machines
crash). But when Longhorn will be released to the market next year; the
only logical choice that I see MS could take would be simply to drop the MDB
format without any further question in any new version of Access/Office.

But I may be wrong and it is well possible that we will see in the futur a
full integration of the CLR and of the .NET Framework - including the
ADO.NET objects - into JET and MDB.
 
Many thanks to the various contributors for your thoughtful and enlightening
comments.

This is very helpful.

Paul
 
I've just see this answer from Mary Chipman [MSFT] from m.p.dotnet.faqs
(answer on 5/9/2005, first post on 5/8/2005), that I'm quoting here:

« No, Access is not being phased out as a development platform, just the
opposite. The Access team is hard at work on the next version of Access even
as we speak. However, Access is not envisioned as a development tool for
..NET applications, if that is what you mean by the question. The Jet engine
can be used as a data store for a .NET application as long as it's small and
local in scope -- it is not suitable for a public web site or
enterprise-level applications that need to scale up or out. So the bottom
line is, if you want to continue to use Access/VBA, you're not going to be
building applications in the .NET space. If you want to use the Jet engine
as a data store for a .NET application, you can safely do so as long as you
don't attempt to exceed its somewhat limited capabilities. » -- Mary Chipman

So, it looks like that MS is playing the Push-Pull game: they have stopped
the development of COM/COM+/DCOM, they don't offer free support for VB6
anymore; ASP and VBScript are phased out on IIS in favor of ASP.NET; the
next version of SQL-Server, including SQL-Server Express, is tightly coupled
to the .NET; the version of DTS running with VBScript is dropped in favor of
the version running with .NET; all support and development for web services
are now strictly .NET related (what was the last time that we heard from MS
about the SOAP and the XML development toolkits for VStudio?) and they
intend to introduce the equivalent of Applets from .NET with the ClickOnce
technology but at the same time, they tell us that the couple Access/VBA is
well alive and will be even better in the next version of Access.

Where someone like you and I - searching for a good development platform for
creating front ends to SQL-Server - can we locate ourselves on this line?
 
Hi Sylvain,

Glad to here the bit about Access not being phased out, it is a great
product, in my humble view one of the best MS has written. My concern over
..NET within Access is not about developing .NET within Access it is the code
based going over to managed code, (good to see VBA in there), whilst I think
..NET is great there are something's that should be considered very carefully
before switching away from VBA, the lost of VB6 as a supported product is a
big loss, I personally use it to write all my ActiveX components, and would
not want to re-write them in C++ (the thought of spending 5-6 times more
time writing anything does not appeal to me), someone tell how I am going to
write my client-side ActiveX or equivalent to enrich the client-side browser
without VB6. I feel I will be using VB6 for the next good few years as it is
another great MS product shame about the support, but I have lived without
the support for years already, I suppose Longhorn will throw a spanner in
the works killing it once and for all.

--
Regards

Alex White MCDBA MCSE
http://www.intralan.co.uk

Sylvain Lafontaine said:
I've just see this answer from Mary Chipman [MSFT] from m.p.dotnet.faqs
(answer on 5/9/2005, first post on 5/8/2005), that I'm quoting here:

« No, Access is not being phased out as a development platform, just the
opposite. The Access team is hard at work on the next version of Access
even as we speak. However, Access is not envisioned as a development tool
for .NET applications, if that is what you mean by the question. The Jet
engine can be used as a data store for a .NET application as long as it's
small and local in scope -- it is not suitable for a public web site or
enterprise-level applications that need to scale up or out. So the bottom
line is, if you want to continue to use Access/VBA, you're not going to be
building applications in the .NET space. If you want to use the Jet engine
as a data store for a .NET application, you can safely do so as long as
you don't attempt to exceed its somewhat limited capabilities. » -- Mary
Chipman

So, it looks like that MS is playing the Push-Pull game: they have stopped
the development of COM/COM+/DCOM, they don't offer free support for VB6
anymore; ASP and VBScript are phased out on IIS in favor of ASP.NET; the
next version of SQL-Server, including SQL-Server Express, is tightly
coupled to the .NET; the version of DTS running with VBScript is dropped
in favor of the version running with .NET; all support and development for
web services are now strictly .NET related (what was the last time that we
heard from MS about the SOAP and the XML development toolkits for
VStudio?) and they intend to introduce the equivalent of Applets from
.NET with the ClickOnce technology but at the same time, they tell us that
the couple Access/VBA is well alive and will be even better in the next
version of Access.

Where someone like you and I - searching for a good development platform
for creating front ends to SQL-Server - can we locate ourselves on this
line?

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC


Paul Ponzelli said:
Many thanks to the various contributors for your thoughtful and
enlightening comments.

This is very helpful.

Paul
Click to expand...
Click to expand...
 
I have the same opinion about Longhorn and VBA under Access and Office:
Longhorn is one to two years behind in schedule, they throw us a bone with a
new version of Access still running VBA in the meantime.

However, this will transform the classic VBasic (VB, VBScript and VBA,
excluding VB.NET) into an isolated island; an old vestige standing out from
the past. (This remember me these good old movies with dinosaurs scouring
on an isolated land.)

I agree that by itself, the lack of support for VB6 is not a big deal but
this put you in the uncomfortable situation of having to tell to your
clients that even if you give them the source code of your ActiveX
components; they don't have anymore the legal right of buying VB6 for
updating and recompiling them (unless they buy MSDN). Not an pleasant
tought when it's about a critical component for an enterprise.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC


Alex White MCDBA MCSE said:
Hi Sylvain,

Glad to here the bit about Access not being phased out, it is a great
product, in my humble view one of the best MS has written. My concern over
.NET within Access is not about developing .NET within Access it is the
code based going over to managed code, (good to see VBA in there), whilst
I think .NET is great there are something's that should be considered very
carefully before switching away from VBA, the lost of VB6 as a supported
product is a big loss, I personally use it to write all my ActiveX
components, and would not want to re-write them in C++ (the thought of
spending 5-6 times more time writing anything does not appeal to me),
someone tell how I am going to write my client-side ActiveX or equivalent
to enrich the client-side browser without VB6. I feel I will be using VB6
for the next good few years as it is another great MS product shame about
the support, but I have lived without the support for years already, I
suppose Longhorn will throw a spanner in the works killing it once and for
all.

--
Regards

Alex White MCDBA MCSE
http://www.intralan.co.uk

Sylvain Lafontaine said:
I've just see this answer from Mary Chipman [MSFT] from m.p.dotnet.faqs
(answer on 5/9/2005, first post on 5/8/2005), that I'm quoting here:

« No, Access is not being phased out as a development platform, just the
opposite. The Access team is hard at work on the next version of Access
even as we speak. However, Access is not envisioned as a development tool
for .NET applications, if that is what you mean by the question. The Jet
engine can be used as a data store for a .NET application as long as it's
small and local in scope -- it is not suitable for a public web site or
enterprise-level applications that need to scale up or out. So the bottom
line is, if you want to continue to use Access/VBA, you're not going to
be building applications in the .NET space. If you want to use the Jet
engine as a data store for a .NET application, you can safely do so as
long as you don't attempt to exceed its somewhat limited
capabilities. » -- Mary Chipman

So, it looks like that MS is playing the Push-Pull game: they have
stopped the development of COM/COM+/DCOM, they don't offer free support
for VB6 anymore; ASP and VBScript are phased out on IIS in favor of
ASP.NET; the next version of SQL-Server, including SQL-Server Express, is
tightly coupled to the .NET; the version of DTS running with VBScript is
dropped in favor of the version running with .NET; all support and
development for web services are now strictly .NET related (what was the
last time that we heard from MS about the SOAP and the XML development
toolkits for VStudio?) and they intend to introduce the equivalent of
Applets from .NET with the ClickOnce technology but at the same time,
they tell us that the couple Access/VBA is well alive and will be even
better in the next version of Access.

Where someone like you and I - searching for a good development platform
for creating front ends to SQL-Server - can we locate ourselves on this
line?

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC


Paul Ponzelli said:
Many thanks to the various contributors for your thoughtful and
enlightening comments.

This is very helpful.

Paul
Click to expand...
Click to expand...
Click to expand...
 
Back
Top