Question on conversion to ADP

[Sylvain Lafontaine]

Sorry, wrong reference:
http://blogs.msdn.com/clintcovington/archive/2007/02/15/macros-in-access-2007.aspx .

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

 

[a a r o n . k e m p f]

ADP were never a stupid idea, and they were never harder to use AT
ALL.
The development for queries - sprocs / views - is 100 times more
powerful than anything available in Jet.

Simple binding of a form to a sproc in Jet takes about 10 steps,
coding, and single-user access to the frontend.

None of those are necessary with GODS PLATFORM-- ADP.

 

[a a r o n . k e m p f]

Irrational fear of jet?

The P.O.C. database crashes and runs slow with ~~25 mb of data!!!!

 

[a a r o n . k e m p f]

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.

 

[a a r o n . k e m p f]

I'm sorry; I don't understand

'caching server side objects with XML'-- I know what you're talking
about.. I just don't think that any of that junk is necessary.


If your server objects don't run fast enough; take a class on SQL
Server

 

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

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

I don't believe this for a moment. What will replace the Office
programs and the Office automation that millions of MS's customers
depend on?

I've been hearing "VBA IS DEAD!!!" and ".NET will replace VBA in the
next version of Office" for about half a decade or more now, and
nobody at MS ever says that this is true at all.

The reason I believe it's not true is because it's way too much work
to kill all those technologies without rewriting the entire Office
suite from the ground up. You may not have followed the Office Mac
VBA fiasco, but what happened there was the MS killed VBA in Office
2008 because they couldn't make it work as a universal Mac binary.
After that release, for whatever reason, MS decided it was worth
making it work after all, and the next version of Office Mac will
have VBA back.

Completely rewriting a non-Windows version of Office to use VBA does
not look to me like an indication of the imminent abandonment of
VBA. And the existence of VBA implies all the rest.

MS may *wish* it could force its customer base to stop mucking
around in all those technologies that make its job hard (in part
because MS didn't do its job properly in designing them in the first
place, 15-20 years ago), but that isn't going to happen because MS
would then be driving away most of its customer base.

Vista has shown that MS can't thrust bad products down the throat of
its customers. They aren't going to run the risk again of losing
their customers just to do the right thing (which the low-level
redesign in Vista clearly was).

 

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

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).

Uh-huh. Access developers had this experience c. 1999, when MS told
them to switch to all the new technologies they introduced in Access
2000. Now, all those new technologies are completely dead, while all
the technologies that Access supported *before* that version are
still running strong and are in current development by the Access
team.

So, you might understand why, as an Access developer, I'm somewhat
skeptical of claims about new technologies from outside Access
replacing those that are so well-developed and widely supported
within Access itself.

 

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

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.

If that's the case, it won't be Access any longer.

And, FWIW, I have not acquired Access 2007 and won't take any
development projects for it that are not done as MDBs. In other
words, no ribbon, no ACCDB. My clients don't need (and don't want)
these things, so I'm not about to invest any time in learning them.

 

[Robert Morley]

David W. Fenton wrote:

MS may *wish* it could force its customer base to stop mucking
around in all those technologies that make its job hard (in part
because MS didn't do its job properly in designing them in the first
place, 15-20 years ago), but that isn't going to happen because MS
would then be driving away most of its customer base.

Vista has shown that MS can't thrust bad products down the throat of
its customers. They aren't going to run the risk again of losing
their customers just to do the right thing (which the low-level
redesign in Vista clearly was).

Don't be so sure...they forced VB.NET onto VB6 developers with no recourse
but to adopt the new technology or switch to another platform altogether
(Delphi seems to be popular) if you wanted unmanaged code. Or stick with
the older VB, which many have, despite being...what?...10 years since the
last release?


Rob

 

[David W. Fenton]

David W. Fenton wrote:


Don't be so sure...they forced VB.NET onto VB6 developers with no
recourse but to adopt the new technology or switch to another
platform altogether (Delphi seems to be popular) if you wanted
unmanaged code. Or stick with the older VB, which many have,
despite being...what?...10 years since the last release?

I have Access97 apps in production use at multiple clients. I don't
see a problem.

 

[Sylvain Lafontaine]

« I have Access97 apps in production use at multiple clients. I don't see a
problem. »

Well, you have been able to describe the problem in a few words: since their
creation in 95, there have been practically no change in the way you can
access a SQL-Server from a MDB database file beside the use of ODBC linked
tables and passthrough queries. For all these years; the same complaints
have been made again and again ad viternam:

- When passthrough queries will become read/write instead of read-only?

- When will we be able to use passthrough queries for subreports and
subforms?

- When will we be able to use stored procedure for Insert/Update/Delete on
bound forms?

- When there will be support for application role?

- When will we get support for transactions on bound forms?

- When will we get something better than the current OLE Document Control
for storing and displaying images?

- When will full support for Unicode be implemented?

- Etc., etc., etc.

The only time that they have made something new was with adding the ADO
support and the ADP projects for working with SQL-Server. However, while OK
on many points and an amelioration in comparaison to ODBC linked tables and
passthrough queries; the ADPs have always remained an half baked product
with a lot of missing features and now, as they are going back in the past
by ceasing support for them and hinting that they will be removed in a
future version of Access, you call this an amelioration and a victory!?!?!

Since when doing nothing and resting at the same place over 13 years is an
amelioration and a victory?!?!?

Heck, even the Report Builder available for free for SQL-Express 2008 is now
better and more advanced than the reports available with Access. The only
thing that we have got for reports with Access 2007 is that we have lost the
possibility of setting a specific printer for each report. I don't call
this an amelioration.

Other products like SQL-Server got tons of new features with each new
versions while in the meantime, JET has been left in the cold for all these
years; with practically zero complaints solved. We are in 2008 and it's
still impossible to make something as simple as adding a few comments inside
a querydef! I won't pass any comment on the absence of Full Outer Join or
of any new other structure, on the insane need of putting parenthesis around
everything when doing multiple joins, its partical support for Unicode, the
absence of any graphical tool to see how your queries are executed by JET
and with which indexes or simply the concupiscious way that JET have in
reformating the text of querydefs. I won't even speak about the possibility
of having some advanced coding capabilities in querydefs like you can do
with stored procedures on SQL-Server since around the same time as Access
95.

When was the last time that you have seen something new for the JET engine?

Excerpt for some cosmetical changes here and there; practically nothing new
has been brought to Access over the last 13 years; not only for those
working with SQL-Server as the backend but also for all the other peoples
who use JET exclusively. The only thing that appears to happen is the
removal of features: they have removed its security model (it was weak but
at least, it was there) and its replication feature for the new ACCDB file
format, they are in the process of removing ADP, they have removed DAP
(instead of correcting its many bugs/flaws) and now, they want you to go
back to the use Macros instead of VBA code (or of any another advanced
scripting language).

You have said in a previous post: « - 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. ».

I don't know from where you are taking this perception about Access 2007 but
it must be from some parallel universe; where the laws of physic are
different.

 

[a a r o n . k e m p f]

wow dude so you're still stuck using Access 97?

get with the times!!! RichText rocks!

 

[a a r o n . k e m p f]

stability, performance, limited database size, bloat

you don't see a problem?

or you spend all your time writing workarounds?

 

[a a r o n . k e m p f]

I don't think that ADP are a half-baked product. I think that they're
great!
I really don't think that I've hit a bug in ADP in the past 5-6 years,
honestly.

 

[a a r o n . k e m p f]

David;

those new techs are not dead-- ADP is alive and well, and it will be
for a long time.

And really-- honestly-- Jet still corrupts, it still bloats, and it's
still too slow for enterprise use.
So if you've got a choice between 'good enough' and 'not good enough'
then ADP falls in the good enough category, where Jet hasn't been
reliable enough for me for a long long long time.

I've worked in a dozen environments where we have ~~1gb of data in
jet.

Every single time- moving to SQL Server (ADP) is a no-brainer.

Do you thnk that Starbucks uses Jet to manage their operations
centers? Their products? Their financials?
Do you thnk that Microsoft uses Jet to manage their product lineup? Do
you think that Jet is used for anything at Microsoft?
Do you thnk that Safeco uses Jet to manage their claims?
Do you think that Expedia uses Jet to manage their financial
applications?

 

[a a r o n . k e m p f]

Vista was a success. MacFags don't change anything.

Re: 'MS didn't do its job properly in designing them in the first
place, 15-20 years ago'

THAT IS WHY THEY CAME OUT WITH A MULTIUSER VERSION OF MS ACCESS BACK
IN 2000. IT IS CALLED ADP, AND IT TRUMPS ANYTHING AVAILABLE IN JET!

 

[Sylvain Lafontaine]

I've been in this newsgroup since 5-6 years and I've seen a collection of
them (bugs); including many of them who have been followed by hotfixes.
However, by half-baked, I'm not speaking about the bugs - every application
has them - I'm speaking about the missing features; some of them that have
been promised for so long that they have even been included in the official
documentation for some time (here, I'm talking about the control over
transactions for bound forms).

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


message
I don't think that ADP are a half-baked product. I think that they're
great!
I really don't think that I've hit a bug in ADP in the past 5-6 years,
honestly.

 

[a a r o n _ k e m p f]

well I've been using them since 99 (member of Office Premium Partner
program back then) and I haven't had any problems with them since
about 2002.

I just think that they're a wonderful platform. SQL Server-- even
with the other components is just an awesome platform.
Jet isn't usable for 25mb of data.

I've not had a problem in ADP in the past 5-6 years.

Meanwhile, Jet makes you write connection strings when you move
servers, etc.
In ADP, it's a single file,connection-- I just think that companies
should use ADP for everything.

And Jet isn't reliable enough for a simple library / tracking
database.

-Aaron

 

[a a r o n _ k e m p f]

I also think that Microsoft needs to take the ADP model and apply it
to EXCEL.
Not excel services (the opposite) or Excel dumbed down - for lists-
like in SharePoint.

I think that MS needs to make Excel run on top of SQL Server, that
would be a lot of fun.

As it is-- Jet isn't reliable enough for anything.
So any sane person has their choice between Excel and SQL Server.

Excel is fucking lame-- it doesn't support multiple users-- and SQL
Server is _EASIER_ development than Jet / ACCDB.
With Jet, you can't even horizontally partition a table (for security
purposes) but this is quite easy using Views in SQL Server.

 

[a a r o n _ k e m p f]

and I don't think that I have any problems with transactions and bound
forms.
I use bound forms for almost everything I do.

Sometimes, I have to write a line or two of VBA-- that's not the end
of the world.
And I might requery a form or two 10% more often than I absolutely
need to.

But the ability to _INDEX_ SQL Server means that it's possible, it's
easy-- to adequately index SQL Server.
the same thing in Jet takes hours and hours of manual tests.

A _LOT_ of the ADPs that I use.. and simply a development point for
writing procedural scripts that run in VBA, these are quite easy to
move to SQL Server Agent.

Scheduling code to run over time is priceless-- and I'll put that in
the category of 'Stuff that Jet Doesn't Have, and it never will'.