Re: Question on conversion to ADP

I don't agree with that.

I talked to someone on the Access team about a year ago, and they told
me that it will be here in 10 years and in 20 years.
It will just be dotnetified.






On Nov 19, 9:35 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
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)

"Mary Chipman [MSFT]" <mc...@xxxxxxxxxxxxxxxxxxxx> wrote in messagenews:4fb8i45u0c19iqqq194ak23eqisvqjluoc@xxxxxxxxxx



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

On Tue, 18 Nov 2008 10:55:12 -0500, "Sylvain Lafontaine" <sylvain aei
ca (fill the blanks, no spam please)> wrote:

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.- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Alternatives to ADP?
    ... database (via the upsizing Wizard) and have found that keeping the front end ... excruciatingly SLOW execution speeds for the queries. ... So I am now testing the other upsizing option that creates an adp file. ... That Be to upgrade the database is to allow for future growth. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Official Status of SQLServer 2005 ADP
    ... Plus many sub-tables with there own multiple table queries. ... some data from a second SQL Server database. ... I liked the idea of being able to do everything from the ADP (create tables, ...
    (microsoft.public.access.adp.sqlserver)
  • Re: access 2003
    ... I would focus on the queries behind the combo boxes. ... the Access 97 database, I wouldn't have thought any expressions would be ... When you select a customer and a job in the two combo boxes, ...
    (microsoft.public.access.conversion)
  • Re: access 2003
    ... I would focus on the queries behind the combo boxes. ... the Access 97 database, I wouldn't have thought any expressions would be ... When you select a customer and a job in the two combo boxes, ...
    (microsoft.public.access.conversion)
  • Re: Access 2003 to SQL Server 2000 over a VPN
    ... sufficiently fast response times, ADP may be a good enough client, ... Replication can be another solution, ... you're careful about your database design, though, that may be the way to ... As a result of the difficulties I've had, I try to avoid SQL Server ...
    (microsoft.public.access.adp.sqlserver)