Question on conversion to ADP

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

I have inherited an access database that was converted from 2000 to 2007. The
tables were then uploaded to SQL and linked. Can the .mdb file be converted
to an .adp?
 
Well I can find nothing explicit in the MS documentation on how to do this.
so it looks like you would create an ADP project, link to the SQL database
and then import the forms and reports from the converted Access .mdb file,
correct?

Dave
 
Yes, and then fixup the things that are different in an adp. If you have SQL
strings, for example, SQL Server's sql syntax has some differences from
Access' sql syntax. Since the SQL would now be executing on the server, you
can't use any Access or VBA functions in the sql.
 
Like Paul has said, there is nothing magical with an ADP project: you can
take any form from a MDB database file and copy&paste or import them into an
ADP project. It's only after the forms has been copied (or imported) into
the ADP project that the fun begins.

If somes of your queries in the Querydef collections are simple enough, the
upsizing wizard or the Migration Assistant (SSMA-A) will be able to
translate them into SQL' views, stored procedures (SP) or functions (UDF);
saving you some manipulations. I think that the SSMA-A has a preference for
UDFs but personally, I prefer to use SP. However, both possibilities are
OK.
 
interesting.
yes, most poeple in the real world avoid UDF like the plague- until
SQL 2005 when SchemaBinding clause can increase performance 500%
 
Is there a particular reason that you feel you need to use ADP's
instead of linked tables? For new projects using Access-to-SQL Server,
Microsoft recommends using ODBC links, although of course ADP's are
also supported. Here are some other resources to help you decide which
approach best suits your business needs.

--Mary

TechEd Online Panel (video):
Go to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx and
search for:
"Are we there yet? Successfully navigating the bumpy road from Access
to SQL Server"

Microsoft Access or SQL Server 2005: What's Right in Your
Organization?
http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx

Optimizing Microsoft Office Access Applications Linked to SQL Server
http://msdn.microsoft.com/en-us/library/bb188204.aspx

What are the main differences between Access and SQL Server?
http://sqlserver2000.databases.aspf...ifferences-between-access-and-sql-server.html

"The Best of Both Worlds--Access MDBs and SQL Server"
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp

SQL Server Migration Assistant for Access (SSMA for Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx

FMS Upsizing Center
http://www.fmsinc.com/Consulting/sqlupsizedocs.aspx

Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/dp/0672319446
 
I don't suppose you'd care to venture an opinion as to WHY Microsoft makes
that recommendation, would you? Other than easier local caching of remote
data (which is still possible using an ADP, albeit much more unwieldy),
there seemed to be very little to recommend linked tables over an ADP last
time I looked.


Rob
 
Basically it boils down flexibility, security and managing server-side
objects. With a linked table app, users can create their own
queries/views and they are saved on the client. Allowing users to
create/save their own views and stored procedures can create
management problems with clutter, assigning permissions, etc. Although
you can work around not caching server-side objects in ADPs by using
XML (etc), it takes a lot more work. That being said, many people find
ADPs tremendously useful for certain scenarios. As with any database
application, there is no "one size fits all" and Microsoft certainly
does not discourage ADPs for those who have weighed the alternatives
and find that ADPs best suit a particular business need.

--Mary
 
It's hard to believe that it's you, Mary C., who have just wrote that.
However, now that you have wrote it, it will remains on the Internet
forever.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
 
I don't suppose you'd care to venture an opinion as to WHY
Microsoft makes that recommendation, would you? Other than easier
local caching of remote data (which is still possible using an
ADP, albeit much more unwieldy), there seemed to be very little to
recommend linked tables over an ADP last time I looked.
Click to expand...

Here's one statement by MS (under the header "Access Data Projects
(ADPs)"):

http://technet.microsoft.com/en-us/library/cc178973.aspx

Basically, it seems to me that MS realized that the effort to avoid
using Jet was cutting off their nose to spite their face, in that
whatever slowdowns Jet introduces (all of which can be worked
around) it is incredibly flexible in terms of working with multiple
data sources in different formats. The effort to eliminate the Jet
layer resulted in the creation of another layer, and the end result
is that they were back where the started from in terms of
performance while also having sacrificed the amazing features of Jet
that had been developed over the last 15 years.

MS's current policy is that MDB->ODBC->SQL Server is preferable to
the ADP. That's the official statement (though you'll find lots of
older MS documentation that still trumpets the ADP as the next best
thing until the Second Coming).
 
I'm not sure what your remarks mean, exactly. I've *always* been a
proponent of creating solutions that meet business needs, not the
other way around. Although I have in the past made many remarks to the
effect that I thought ADPs are a dead-end technology, that is strictly
my personal opinion. Many people have invested time and money in ADP
solutions, and Microsoft is committed to continuing to support them
while gently nudging new developers in the ODBC-linked table direction
for new Access-SQL apps. Hopefully the links to the whitepapers that
thoroughly explain the alternatives will achieve greater immortality
on the internet than my ramblings :)

--Mary
 
Oh, everyone here agree that ADP is a dead technology; doesn't take a big
brain to figure that but it's not because ADP is inferior to ODBC linked
tables but simply because MS has took the decision to put practically all
the money toward developping .NET technologies instead of Access. Unless
you're developping a database for storing the kitchen's recipes of your
great, great, grand-mother or the friday night's hockey pool of your local
pub, the gentle push that you're talking about is not toward ODBC linked
tables but toward .NET. In MS's opinion, Access is geared toward usage, not
development. This is why there is no Access certification at the present
time. It's hard to believe that MS itself is taking Access seriously when
there is not even any certification for it.

In your previous post, you have said the following statement: « Basically it
boils down flexibility, security and managing server-side objects. ... ».
Well, then, first, we'll take a look at the word "flexibility". If ODBC
linked tables are so flexible, can you explain to me why it's impossible to
make any little complex statements without having JET saying that the
expression is too complexe, to heavy on ressources, crashing or - in the
best case scenario - see the performance dropping faster than a rock in free
fall? Why is it that in 2008, something as simple as the following
statement:

SELECT T1.*, T2.*
FROM T1 LEFT JOIN T2 ON (T1.Id1 = T2.Id2 and T2.Id2 = 10)

make Access 2003 (didn't took the time to check for other versions) crash if
T1 and T2 are ODBC linked tables (and that it will also crash for a lot of
other simple constructs involving outer joins, subqueries and union
queries).

Make Access capable of doing some little complexe statements against ODBC
linked tables without crashing a regularly as crash test dummy and we could
talk about the technical capabilities of JET's ODBC linked tables. Make the
result of passthrough queries read/write instead of read only and also make
them available as record source for subreports and subforms for continuous
forms and maybe that some people dealing with real enterprise databases will
start looking at this stuff as potentially useful.

And while you're on it, take also the time of solving your case-sensitivity
and collation problems. The fact that in 2008, JET's queries against ODBC
linked tables are still not offering full support for Unicode is practically
unbelievable.

Second, you have wrote the word "security". So you really think that OBDC
linked tables are anything but unsecure? If someone were to store something
confidential like your credit card numbers, you would put your faith on an
ODBC linked table?

Question from the client: - We have a safe but we have some concerns about
the safekeeping of the key because we are keeping under the rug.

Solution from MS: no problem, we will remove it from under the mat and put
it in plain sight on a table nearby. This way, not only you're sure that
anyone around will see it but you're also sure that a thief won't hurt his
back by bending down to take it.

Client: - Great! But what happens if they are two or more thieves?

MS: - Maybe we could put a machine for duplicating keys nearby?

Client: - OK, but make sure that the user's manual is clear and easy to
follow and don't forget the blanks!


Finally, you have made a mention about the difficulty of managing
server-side objects. Great, the next time that a secretary will call me for
a request for a new set of data, I tell her that she'll have to look herself
at the database's schema and make her own set of queries. This is for
reading. Now, for writing, I wonder how many hours it will take before the
database become corrupted when the users will start making their very own
updating statements.

Your notions of security and centralized management of database objects
could be applied to a list of kitchen's recipes but I don't see how anyone
would use those for an enterprise level database or any other serious
business model.

You're totally right when you said that ADPs have their share of problems.
However, I'm afraid that the ADP's set of problem is only a very small
subset of the whole collection held by JET's ODBC linked tables and
passthrough queries. It's also true that MS is actually pushing people out
of ADP but what they are pushed toward is - how could I say that politely -
"questionable".

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
 
You raise many valid points. I have always publicly and privately
maintained that Microsoft wrongly neglected Access developers, but
unfortunately I'm pretty far down the food chain, so I'm pretty much
ignored every time I make that case :)

If you want security, you must ALWAYS implement it on the data source,
in this case Windows/SQL Server. Nobody ever maintained that you could
secure an application through Access or the ODBC API. In the case of
an Access-SQL app, that means using integrated security, granting EXEC
perms on stored procedures and denying all direct access to tables
while creating an "unbound" front-end that passes stored procedure
parameters through VBA/pass-through queries. The linked table approach
is good here because you can fetch read-only data and cache it on the
client, reducing network/server load. Of course, you have to handle
concurrency yourself, opening another can of worms. An ADP is harder
to implement as "unbound", not easier.

That being said, there will always be tradeoffs between security and
flexibility. If you want the secretary to create data objects, then
you're not going to have a secure app no matter which approach you
choose.

The other point on which we concur is that there isn't enough
help/guidance coming from Microsoft for Access developers trying to
make the decision whether to use ADPs or linked tables for their SQLS
apps. As I said before, every application is unique, and people have
different business requirements. So I've taken to posting this list of
resources which will help people decide what works for them. If I've
missed any that you think will help, please let me know and i'll add
them to the list.-- Mary

TechEd Online Panel (video):
Go to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx and
search for:
"Are we there yet? Successfully navigating the bumpy road from Access
to SQL Server"

Microsoft Access or SQL Server 2005: What's Right in Your
Organization?
http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx

Optimizing Microsoft Office Access Applications Linked to SQL Server
http://msdn.microsoft.com/en-us/library/bb188204.aspx

What are the main differences between Access and SQL Server?
http://sqlserver2000.databases.aspf...ifferences-between-access-and-sql-server.html

"The Best of Both Worlds--Access MDBs and SQL Server"
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp

SQL Server Migration Assistant for Access (SSMA for Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx

FMS Upsizing Center
http://www.fmsinc.com/Consulting/sqlupsizedocs.aspx

Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/dp/0672319446
 
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in
It's hard to believe that MS itself is taking Access seriously
when there is not even any certification for it.
Click to expand...

I think your point of view is belied by the actions of the Access
development team in the recent time frame. Access has a new life
both as end-user tool and as developer platform, precisely because
of the decisions made in preparation for Access 2007.

Seems to me that MS has almost returned to the point of view about
Access that it had c. Office 95/97, where they were pushing Office
as a development platform for small and medium-sized businesses. MS
went way, way off track with Office 2000 and Access 2000, in my
opinion, and it's taken them this long to get back to the right
path.

In my opinion, ADPs were a bad idea based on stupid prejudices
rather than technical merit/need, and not really a
properly-implemented development platform. The development of ADPs
sapped resources that should have gone into the core Access
application. The fact that ADPs really are dead now (thankfully)
just points out the waste of resources. How much better Access could
have been for all users if they'd not been led down the garden path
by the crazy Enterprise development ideas that mostly came from
irrational fear of Jet.
 
David W. Fenton said:
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

I think your point of view is belied by the actions of the Access
development team in the recent time frame. Access has a new life
both as end-user tool and as developer platform, precisely because
of the decisions made in preparation for Access 2007.

Seems to me that MS has almost returned to the point of view about
Access that it had c. Office 95/97, where they were pushing Office
as a development platform for small and medium-sized businesses. MS
went way, way off track with Office 2000 and Access 2000, in my
opinion, and it's taken them this long to get back to the right
path.

In my opinion, ADPs were a bad idea based on stupid prejudices
rather than technical merit/need, and not really a
properly-implemented development platform. The development of ADPs
sapped resources that should have gone into the core Access
application. The fact that ADPs really are dead now (thankfully)
just points out the waste of resources. How much better Access could
have been for all users if they'd not been led down the garden path
by the crazy Enterprise development ideas that mostly came from
irrational fear of Jet.
Click to expand...

Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6,
etc., are all technologies based on COM/DCOM and MS is in the process of
killing all technologies based on these because you cannot make real object
oriented programming with COM/DCOM; only some sort of simulation; unlike
..NET which has been designed as an object oriented programming platform from
the ground up.

First, they have killed DNA (Distributed Network Architecture) before it got
even the chance of getting out of the laboratoray; then their next target
has been VB6 as well as a lot of smaller associated technologies like ADO,
VBScript, ASP Classic; etc. Did you really think that after having killed
these very big pieces of development platforms that were VB6, ASP Classic
and VBScript, that MS would be giving some serious toughts about keeeping
VBA and DAO in the long term?

I don't really understand how you can say that Access 2007 has got a new
life as a development platform when practically all the technological
development that have been made these last years are based on .NET and the
only thing that Access got was these small bones about Sharepoint; which, by
the way, are totally useless for anyone using SQL-Server as the backend.

They don't give a s**t about the technical merit/need of ADO vs DAO; all
they want is to get rid of COM/DCOM in the fatest way; so they are killing
these littles bunnies one after the other and it shouldn't take to long
before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally
absurd for anyone entering the field to learn VBA and DAO (as well as ADO);
so it doesn't take a big brain to see that there is absolutely no future
there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the
only difference if that some peoples using these don't know it yet.

The problem is not to know if there is a future or not for DAO and ADO
(there's none for both of them); the problem is to know what's the best
thing to do in the meantime before we can get our hands on a version of
Access with and integrated version to .NET.
 
David said:
Here's one statement by MS (under the header "Access Data Projects
(ADPs)"):

http://technet.microsoft.com/en-us/library/cc178973.aspx
Click to expand...

Yeah, seen that...their section on Access 2007 and SQL Server has been
copied without substantial change since the very first betas of Access 2007.

I just *love* the parts where they say it's "easier" (not necessarily
better) to optimize MDB/ACCDB solutions and then go on to admit that "there
are some scenarios where a report might be generated significantly faster in
an ADP file. [...] have the file load reports from a references ADP file."
Ummm...okay, so I'm jumping through the hoops of linking my perfectly viable
ADP solution into an MDB *why* again?
Basically, it seems to me that MS realized that the effort to avoid
using Jet was cutting off their nose to spite their face, in that
whatever slowdowns Jet introduces (all of which can be worked
around) it is incredibly flexible in terms of working with multiple
data sources in different formats. The effort to eliminate the Jet
layer resulted in the creation of another layer, and the end result
is that they were back where the started from in terms of
performance while also having sacrificed the amazing features of Jet
that had been developed over the last 15 years.
Click to expand...

And I'll agree, there are some advantages there, but honestly, I don't think
I've ever been called on to do things like joins from heterogeneous
sources...nor would I want to, generally, for the obvious performance
issues. If I *did* need to, I'd either go with a central-import solution or
do the reverse of the ADP linkage that MS suggests and link an MDB into an
ADP if I absolutely had to.
MS's current policy is that MDB->ODBC->SQL Server is preferable to
the ADP. That's the official statement (though you'll find lots of
older MS documentation that still trumpets the ADP as the next best
thing until the Second Coming).
Click to expand...

That's funny because I still think it is! Yeah, there are bugs, but the
fact that you don't need to worry about linking in new and existing objects
is probably the biggest thing in ADP's favour in my books, not to mention
the fact that you KNOW all the processing will be done server-side instead
of the possibility that it'll try to download a whole lot of data over
potentially very narrow bandwidth to try to process it client-side.

To this day, I don't get why you'd ever want to use MDBs in a strictly
Access to SQL Server environment. Granted, local caching is easier in an
MDB, but it's not entirely un-doable in an ADP...you just have to use some
form of storage other than the ADP itself.

I just don't get why MS thinks that because THEY think MDBs are back to
being the preferred format that everybody else will naturally agree...and I
know I've seen other developers who have similar opinions about ADPs (not
counting Aaron Kempf, who will rabidly promote ADPs/SQL Server for
everything from a single-table local database to the entire international
banking system <grin>).

But hey, to each his or her own.



Rob
 
Sylvain, David et al,

You all raise very valid points. I encourage you to go register on
http://connect.microsoft.com/SQLServer and file Feedback bugs. Then
enlist your friends/colleagues to vote on them. If enough customers
want/require some specific piece of functionality, then it will get
more consideration from the product team. This isn't going to apply to
Access-specific features, but it does apply to all data access
technologies, not just SQL Server. This includes ODBC, OLEDB (classic
ADO), ADO.NET, LINQ to SQL and the Entity Framework. Having been on
the outside and now on the inside, my own personal agenda in all this
is to try to make things easier for developers seeking to
migrate/develop SQL Server apps regardless of the front-end tools they
use, and Connect seems to be the best way to make your voices heard.

That being said, there are often reasons for certain decisions that
are not made public, such as potential security vulnerabilities or
lack of internal resources. For example, updating ADPs to work with
later versions of SQL Server with the same range of functionality that
ADPs originally had would have been prohibitively expensive given the
relatively small number of Access-SQL developers compared to the
number of Access developers overall (somewhere in the neighborhood of
50 million). They would have had to cut features in the core product
that would have benefitted many to cater to the few. So it isn't about
Microsoft arbitrarily deciding to kill off various technologies --
these are business decisions, and sometimes Microsoft gets it wrong.
If you think they got it wrong for Access-SQL developers, go file a
Connect bug (or two).

--Mary

David W. Fenton said:
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

I think your point of view is belied by the actions of the Access
development team in the recent time frame. Access has a new life
both as end-user tool and as developer platform, precisely because
of the decisions made in preparation for Access 2007.

Seems to me that MS has almost returned to the point of view about
Access that it had c. Office 95/97, where they were pushing Office
as a development platform for small and medium-sized businesses. MS
went way, way off track with Office 2000 and Access 2000, in my
opinion, and it's taken them this long to get back to the right
path.

In my opinion, ADPs were a bad idea based on stupid prejudices
rather than technical merit/need, and not really a
properly-implemented development platform. The development of ADPs
sapped resources that should have gone into the core Access
application. The fact that ADPs really are dead now (thankfully)
just points out the waste of resources. How much better Access could
have been for all users if they'd not been led down the garden path
by the crazy Enterprise development ideas that mostly came from
irrational fear of Jet.
Click to expand...

Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6,
etc., are all technologies based on COM/DCOM and MS is in the process of
killing all technologies based on these because you cannot make real object
oriented programming with COM/DCOM; only some sort of simulation; unlike
.NET which has been designed as an object oriented programming platform from
the ground up.

First, they have killed DNA (Distributed Network Architecture) before it got
even the chance of getting out of the laboratoray; then their next target
has been VB6 as well as a lot of smaller associated technologies like ADO,
VBScript, ASP Classic; etc. Did you really think that after having killed
these very big pieces of development platforms that were VB6, ASP Classic
and VBScript, that MS would be giving some serious toughts about keeeping
VBA and DAO in the long term?

I don't really understand how you can say that Access 2007 has got a new
life as a development platform when practically all the technological
development that have been made these last years are based on .NET and the
only thing that Access got was these small bones about Sharepoint; which, by
the way, are totally useless for anyone using SQL-Server as the backend.

They don't give a s**t about the technical merit/need of ADO vs DAO; all
they want is to get rid of COM/DCOM in the fatest way; so they are killing
these littles bunnies one after the other and it shouldn't take to long
before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally
absurd for anyone entering the field to learn VBA and DAO (as well as ADO);
so it doesn't take a big brain to see that there is absolutely no future
there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the
only difference if that some peoples using these don't know it yet.

The problem is not to know if there is a future or not for DAO and ADO
(there's none for both of them); the problem is to know what's the best
thing to do in the meantime before we can get our hands on a version of
Access with and integrated version to .NET.
Click to expand...
 
Oh, first thing, I would say that I'm totally in accord with the decision of
replacing VB6, VBScript and other things like ADO with .NET and that the
sooner the same will be done with VBA and DAO in Access, the better it will
be.

The problem that I have is with the message that MS is sending in the
meantime. When you read some of the posts from MS these last years, my
clients have the impression that keeping running with ADP is a dead-end
(right) but that going with VBA and DAO will be an investment in the future
(wrong).

Some years ago, any computer library would have been full of books on VB6,
VBSCript, ASP Classic and ADO; now, all these books are gone. However, when
you read some posts from MS, my clients got the impression that these books
have been replaced with books on DAO and VBA; clearly not the case when you
take a look by yourself but this is not something that my clients will do;
otherwise, they wouldn't pay me if they were capable of doing my job
themselves.

Furthermore, when you take a look at some posts like the following one from
Clint Covington about Macro coding under A2007:
http://blogs.msdn.com/clintcovingto...s-template-downloads-5-new-free-database.aspx ;
I'm not even sure if any scripting capabilities other than macros is in the
future of Access or if the decision has not already be made to transform
Access into some kind of point&click only interface. I can tell you that I
won't be surprised at all if the next version has some new features that can
be accessed only through macros, not VBA.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


Mary Chipman said:
Sylvain, David et al,

You all raise very valid points. I encourage you to go register on
http://connect.microsoft.com/SQLServer and file Feedback bugs. Then
enlist your friends/colleagues to vote on them. If enough customers
want/require some specific piece of functionality, then it will get
more consideration from the product team. This isn't going to apply to
Access-specific features, but it does apply to all data access
technologies, not just SQL Server. This includes ODBC, OLEDB (classic
ADO), ADO.NET, LINQ to SQL and the Entity Framework. Having been on
the outside and now on the inside, my own personal agenda in all this
is to try to make things easier for developers seeking to
migrate/develop SQL Server apps regardless of the front-end tools they
use, and Connect seems to be the best way to make your voices heard.

That being said, there are often reasons for certain decisions that
are not made public, such as potential security vulnerabilities or
lack of internal resources. For example, updating ADPs to work with
later versions of SQL Server with the same range of functionality that
ADPs originally had would have been prohibitively expensive given the
relatively small number of Access-SQL developers compared to the
number of Access developers overall (somewhere in the neighborhood of
50 million). They would have had to cut features in the core product
that would have benefitted many to cater to the few. So it isn't about
Microsoft arbitrarily deciding to kill off various technologies --
these are business decisions, and sometimes Microsoft gets it wrong.
If you think they got it wrong for Access-SQL developers, go file a
Connect bug (or two).

--Mary

David W. Fenton said:
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in
It's hard to believe that MS itself is taking Access seriously
when there is not even any certification for it.

I think your point of view is belied by the actions of the Access
development team in the recent time frame. Access has a new life
both as end-user tool and as developer platform, precisely because
of the decisions made in preparation for Access 2007.

Seems to me that MS has almost returned to the point of view about
Access that it had c. Office 95/97, where they were pushing Office
as a development platform for small and medium-sized businesses. MS
went way, way off track with Office 2000 and Access 2000, in my
opinion, and it's taken them this long to get back to the right
path.

In my opinion, ADPs were a bad idea based on stupid prejudices
rather than technical merit/need, and not really a
properly-implemented development platform. The development of ADPs
sapped resources that should have gone into the core Access
application. The fact that ADPs really are dead now (thankfully)
just points out the waste of resources. How much better Access could
have been for all users if they'd not been led down the garden path
by the crazy Enterprise development ideas that mostly came from
irrational fear of Jet.
Click to expand...

Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript,
VB6,
etc., are all technologies based on COM/DCOM and MS is in the process of
killing all technologies based on these because you cannot make real
object
oriented programming with COM/DCOM; only some sort of simulation; unlike
.NET which has been designed as an object oriented programming platform
from
the ground up.

First, they have killed DNA (Distributed Network Architecture) before it
got
even the chance of getting out of the laboratoray; then their next target
has been VB6 as well as a lot of smaller associated technologies like ADO,
VBScript, ASP Classic; etc. Did you really think that after having killed
these very big pieces of development platforms that were VB6, ASP Classic
and VBScript, that MS would be giving some serious toughts about keeeping
VBA and DAO in the long term?

I don't really understand how you can say that Access 2007 has got a new
life as a development platform when practically all the technological
development that have been made these last years are based on .NET and the
only thing that Access got was these small bones about Sharepoint; which,
by
the way, are totally useless for anyone using SQL-Server as the backend.

They don't give a s**t about the technical merit/need of ADO vs DAO; all
they want is to get rid of COM/DCOM in the fatest way; so they are killing
these littles bunnies one after the other and it shouldn't take to long
before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally
absurd for anyone entering the field to learn VBA and DAO (as well as
ADO);
so it doesn't take a big brain to see that there is absolutely no future
there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the
only difference if that some peoples using these don't know it yet.

The problem is not to know if there is a future or not for DAO and ADO
(there's none for both of them); the problem is to know what's the best
thing to do in the meantime before we can get our hands on a version of
Access with and integrated version to .NET.
Click to expand...
Click to expand...
 
Back
Top