Future of ADP's
Reese Watt
I started out as an actuary using Excel spreadsheets.
I realized Excel wasn't a database, so I learned Access and VBA
I learned Access had limits, so I learned SQL-Server and ADP projects.
I became a developer and developed a really nice application using
SQL-Server/ADP that is helping lots of people be much more efficient.
Now, we're consider marketing this application to other firms and I want to
be sure I have a platform that will be good for the long-term investment of
future clients.
From what I'm reading, I feel like a cartoon character with my left foot in
one car and my right foot in another and straight ahead is a fork in the
road. The left fork is the VB.Net/SQL-Server road. The right fork is the
Access/ACCDB road. I want to continue to use Access for the front end and
SQL Server for the back end, but it may not be possible.
Here are my questions:
1) Is my perception correct, that Microsoft really doesn't have an
all-in-one application to design front-ends to SQL Server, other than the
ADP route? I know there is VB.Net, but even there you need Crystal Reports
to design your reports.
2) Are there things that I do in Access reports that can't be done in
Crystal Reports?
3) Is VB.Net really as slow to develop as it seems to me? I taught myself
Access, VBA and SQL-Server, so I have a fairly good idea of the pain that is
required to learn a new technology. I've also done a few projects using
VB.Net. It just doesn't seem like VB.Net is nearly as easy to use. Here
are a few examples:
There is no AfterUpdate event, nor a host of other easy-to-use events.
It seems like combo boxes are much more complicated.
Datasheet forms (datagrid) are much more difficult to work with.
In other words, if I bite the bullet and take six months to really learn
VB.Net, will I even then be able to develop applications as fast I can in
Access right now?
5) Are there any third-party interfaces that make VB.Net more of a RAD
environment?
6) Is there any way for me to get in contact with a knowledgable person at
Microsoft to a) express my support for ADP's and b) get a better idea of
what the future may hold?
Thanks to all
Baz
it's clear that Microsoft has lost interest and has no intention of
developing the technology further.
However, there's nothing wrong with using mdb's (or accdb's) with linked SQL
Server tables. It's a technology that worked well for years before ADP's
were invented.
The learning curve for VB.Net is steep, especially if Access is the only
technology with which you have prior experience. Even if you become an
expert you will still lack much of the Access functionality that you know
and love (e.g. subforms, continuous forms), and it will still take you much
longer to develop a database application than with Access (despite what some
one-eyed dotnet-heads might claim).
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:us4bRD8z...@TK2MSFTNGP05.phx.gbl...
Vayse
pushing this instead of crystal reports.
I like Report Viewer, its certainly easier to use than Crystal.
However, Report Viewer has the same problem as Visual Basic 2005. Its still
not stable, and Microsoft aren't going to fix it - they've moved onto the
next version. Everything will probably work fine for you, but it may not.
And the new version is just around the corner.......
Access 2007 seems to have a lot of issues. If you are considering marketing
to other firms, then you may need the access runtime.
Be aware that the Access 2007 runtime was only released this week, and that
ADP reports won't work with it. Which could be a bit of an issue! :)
http://blogs.msdn.com/clintcovington/archive/2007/07/20/the-runtime-is-available-for-download.aspx
As Baz said, mdb/accdb still works, and this may be the way to proced. Tonys
blog is interesting
http://msmvps.com/blogs/access/
and discusses some ways to speed up the new versions of access, and
improving Access on Vista.
Personally, I like using dotnet. Its flashy, and I find it very useful for
small to medium apps. Style over substance!
However, for anything complex, I would stay with Access 2003. It is faster
to develop in, and relatively stable.
Vayse
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
news:46a9afaa$0$31714$db0f...@news.zen.co.uk...
Reese Watt
Thanks for the response. It feels like I would be going backwards to revert
to mdb's & ODBC, but I guess that is the way Microsoft is pushing me if I
don't want to go to .Net.
Regarding linked SQL tables inside an mdb, I understand there is no way to
edit the structure of those SQL tables. I really like the fact that in an
ADP, I have the ability to edit the structure of views, queries, stored
procedures, tables, etc. without having to open another application.
Does Access 2007 and/or SQL 2005 give me any better tools for editing those
SQL objects than what I find in the Enterprise Manager for SQL 2000?
Thanks,
Reese
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
news:46a9afaa$0$31714$db0f...@news.zen.co.uk...
Reese Watt
Thanks for the reply. I wasn't aware of Report Viewer, so that helps. Do
you know of any Microsoft or third party products than can convert from
Access reports to Report Viewer?
Another question related to combo boxes. I've done some work in VB.Net 2003
and it seemed very complex to put a combo box in a datagrid (compared to
putting a combo box on a datasheet view in Access). Is that any easier to
do in VB.Net 2005?
Thanks,
Reese
"Vayse" <vvv> wrote in message news:OxbP2tF0...@TK2MSFTNGP05.phx.gbl...
Baz
with mdb (and maybe accdb) with linked tables, I've done lots of
applications like this and also lots of ADP's, I don't find a great deal
between them.
Personally I don't like the database design features of ADP's. I much
prefer Enterprise Manager, and I always have it open on another screen while
I'm working on an ADP.
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:u6p4%232F0H...@TK2MSFTNGP02.phx.gbl...
Robert Morley
one simple reason (which I admit may be more specific to this project than
some other types of projects): we have a lot of ad-hoc queries in our
group. It's nice to know that if I create a new View (or Table or anything
else, for that matter), I don't have to worry about doing anything special
to make those queries accessible to users. You just open (or refresh) the
ADP, and they're all there automatically.
Granted, I put a nicer front-end on the app, and refreshing an ADP when
you're not showing the main database window is a bit of a challenge, but not
having to dynamically re-link views is a major bonus for me, and one of the
biggest reasons that I still refuse to go back to MDB/ACCDB format, no
matter how hard MS tries to push me in the direction they somehow think will
be better for me, even though they know nothing about my environment.
Rob
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
news:46aa09ec$0$15224$fa0f...@news.zen.co.uk...
Reese Watt
You both say that you prefer designing in SQL EM versus the ADP.
Is there some kind of query builder in EM that I'm missing? Or do you
actually type out every new view/stored procedure?
Thanks,
Reese
"Robert Morley" <rmo...@magma.ca.N0.Freak1n.sparn> wrote in message
news:uBtu9GH...@TK2MSFTNGP06.phx.gbl...
Reese Watt
When I right-click and select new View, then I see a query builder. But
it's only there for views, not for functions and stored procedures.
I'll guess I'll need to start them all out as views, and then just copy the
SQL over.
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:eB8GUnH0...@TK2MSFTNGP05.phx.gbl...
Robert Morley
SPs. I personally despise the thing as a design tool, but I know I'm one of
only a very few who feels that way about it, so you might find it useful.
To get there from the main window of SQL EM, click on Tools, then SQL Query
Analyzer.
Regardless of how I feel about it as a design tool, it does have several
other useful features such as timing how long it takes a query to return
results, analyzing your query to show you the plan it intends to use, and
how intensive each portion of the query is, that sort of thing. I really
only know some of its basic functions; I'm sure someone better versed in it
and who uses it frequently can give you a better idea (or perhaps point you
to a web page).
Rob
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:eCO8nqH0...@TK2MSFTNGP03.phx.gbl...
Baz
SP's that aren't in the EM.
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:eCO8nqH0...@TK2MSFTNGP03.phx.gbl...
Baz
advantages and disadvantages.
The biggest problem with ADP's is Microsoft's attitude. They seem to have
decided to drop them like a hot potato, which means that we're unlikely to
get fixes for the many bugs, let alone new features. What's more, they will
probably do a VB6 on it in some future version of Access i.e. kill it off
completely and ignore the howls of anguish from those of us with a big
investment in the technology.
"Robert Morley" <rmo...@magma.ca.N0.Freak1n.sparn> wrote in message
news:uBtu9GH...@TK2MSFTNGP06.phx.gbl...
Robert Morley
process of doing it. It's really frustrating, doubly so when you take into
account that only a few years ago, they were encouraging everybody to move
to the latest & greatest technology that was ADP's. And suddenly it's like,
"Oh, we're not excited about this any more, so if you took our advice of a
couple of years ago, you're up the creek now. We're not really even sorry
about it, cuz we've got something new that we're all excited about now."
I think MS needs the corporate equivalent of a time-out or a "think about
what you did wrong and what the consequences were to others besides
yourself".
Rob
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
news:46ab17cc$0$15226$fa0f...@news.zen.co.uk...
Vadim Rapp
RW> all-in-one application to design front-ends to SQL Server, other than
RW> the ADP route?
Correct.
RW> 2) Are there things that I do in Access reports that can't be done in
RW> Crystal Reports?
I once actually forced myself to overcome the bias stemming from the fact of
trialware included in paid-for product, and actually installed crystal
reports component. Uninstalled it like a nightmare 30 minutes later.
RW> 3) Is VB.Net really as slow to develop as it seems to me?
Yes.
RW> I taught myself Access, VBA and SQL-Server, so I have a fairly good
RW> idea of the pain that is required to learn a new technology. I've also
RW> done a few projects using VB.Net. It just doesn't seem like VB.Net is
RW> nearly as easy to use.
RW> In other words, if I bite the bullet and take six months to really
RW> learn VB.Net, will I even then be able to develop applications as fast
RW> I can in Access right now?
Whatever you are programming in vb.net, every 5 minutes there's some new
surprise obstacle that you have to research in order to move forward.
Nothing unresolvable, usually 15 minutes is enough to find the solution
(usually in form of yet another line in yet another configuration xml file
that you have to put there using notepad) and move ahead. What's most
surprising is that this interval does not depend on your experience. In six
months, and in two years, it's still the same every 5 mintues.
RW> 6) Is there any way for me to get in contact with a knowledgable person
RW> at Microsoft to a) express my support for ADP's and b) get a better
RW> idea of what the future may hold?
I think they don't know it themselves. For now, the recommended way is using
accdb. That's where the development is.
There's another way though - sql server reporting services. You design
reports in them, and view on the intranet. This is indeed much more scalable
solution, with potential for future enhancements, publishing on public
website etc. We actually moved this way 2 years ago, and everybody agrees
that it's big solid progress. Including higher management.
regards
Vadim Rapp
RW> But it's only there for views, not for functions and stored procedures.
right-click a table, open table->query. That way, you don't have to create
new view in order to run it.
Once created, copy the text and paste to query analyzer.
There's no point in creating stored procedures consisting of one query; I
always put direct sql in datasource of forms and in other places, including
sql server agent jobs. The only exception is, access adp does not like when
the query is tooo big. Then I create a view.
Vadim Rapp
Vadim Rapp
B> advantages and disadvantages.
B> The biggest problem with ADP's is Microsoft's attitude. They seem to
B> have decided to drop them like a hot potato, which means that we're
B> unlikely to get fixes for the many bugs, let alone new features. What's
B> more, they will probably do a VB6 on it in some future version of Access
B> i.e. kill it off completely and ignore the howls of anguish from those
B> of us with a big investment in the technology.
So what. Pretty much all functionality really required for resolving
real-life business problems, was here years ago, in vb6 + the same access.
Regardless of what all those ad-sponsored "professional" magazines say.
Microsoft now can happily concentrate on such "important" developments as
new toolbars in Office (oh, no, not toolbars - they call it "strip"), "user
experience", and similar "smart tags". Really, is there much you can't do
with your existing tools in order to resolve real-life business problem?
Vadim Rapp
Vayse
I didn't use VB Net 2003, but I can tell you that combo boxs in a grid is
easy now.
"Reese Watt" <re...@hallmarkstone.com> wrote in message
news:uROwo7F0...@TK2MSFTNGP04.phx.gbl...
Baz
real-life business problems, but what am I supposed to do with my existing
applications when Microsoft not only drops ADP's from some future version of
Access, but also introduces another version of Windows which doesn't support
old, ADP-capable Access versions? Either I'll have to rewrite the
applications, or tell my clients to stay on Windows XP, or Vista or whatever
forever.
Just look at all the legacy software that doesn't work with Vista...
"Vadim Rapp" <v...@nospam.myrealbox.com> wrote in message
news:eFbAY$h0HHA...@TK2MSFTNGP06.phx.gbl...
Vadim Rapp
B> real-life business problems, but what am I supposed to do with my
B> existing applications when Microsoft not only drops ADP's from some
B> future version of Access, but also introduces another version of Windows
B> which doesn't support old, ADP-capable Access versions? Either I'll
B> have to rewrite the applications, or tell my clients to stay on Windows
B> XP, or Vista or whatever forever.
Simple. Tell your clients to stay with whatever is working. If Microsoft is
pursuing the ways that don't work, like Vista, then stay. If at some point
the direction of Microsoft movement reverses to the users' productivity
(including your productivity as IT professional and resulting cost of your
services), then go.
One indicator of returning to senses would be stopping crying wolf about
security, which now seems to constitute 90% of all concerns.
Vadim Rapp
Armando Vargas
"Developers", that really started in Access and continued with Access
because it is real easy and quick to develop a solution, and enable us to
make a living deploying solutions to small to medium business.
I think that many of us are worried not about ADPs but how are we going to
continue to work, or if there is a future for us in the IT world.
Maybe that most of us are self learing and will take a lot of time to lear
something new and if it going to be time-cost effective as Access is.
Please, write your suggestion that we should lear, or start to use like:
Ms Access ADPs and SQL Server 2005 Express
SQL Server 2005 Express and ASP.Net, or see some web applications.
All your help and commerts are really important for all of us that fell our
work is about to end.
Thanks for your time and support.
Armando Vargas.
"Reese Watt" <re...@hallmarkstone.com> escribió en el mensaje
news:us4bRD8z...@TK2MSFTNGP05.phx.gbl...
Baz
itself has just made a huge commitment to Access with all the new stuff in
Access 2007, it isn't going to disappear anytime soon. As far as I can see
the only aspect of Access which is seriously under threat is ADP's. That
isn't any kind of show-stopper for new applications with server database
engines, though: I have very happily worked with linked tables in the past
and I will continue to do so in future. The main issue is that those of us
who have already built ADP solutions are probably going to have to convert
them to linked tables at some time in the future.
"Armando Vargas" <traba...@hotmail.com> wrote in message
news:%235MbPOy...@TK2MSFTNGP02.phx.gbl...
Armando Vargas
I agree with that. Access may not disapper, but, I feel that is been
downgraded, I use ADPs because, the links with SQL, but I havent tryed the
linking tables with MDB and a SQL. Maybe it would work real fine.
I stop using linking tables, because I develop some applications that conect
throuth the internet, (ADP and SQL) thing that could not be done by a MDB.
(Link tables) I wonder if linking tables in Access2007 and SQL will work
fine, and give the same performance that ADP gave in the past.
All your comments are welcomed.
Thanks,
Armando Vargas.
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> escribió en el mensaje
news:46aee120$0$15215$fa0f...@news.zen.co.uk...
Baz
The sidelining of ADP's is disappointing, but against that everything else
has been seriously upgraded. MS has made it very clear that it is fully
committed to Access and has made a huge investment in Access 2007.
ODBC linked tables can perform as well as ADP's, but it takes some care.
The flexibility of Access/Jet is such that it is possible to create queries
which exceed the capabilities of ODBC and/or the server, in which case the
queries will run on the client. This can be a performance problem on a LAN,
and this will obviously be greatly magnified on a WAN. The solutions are
not difficult: modify the design, use a passthrough query, build a
server-side view and link to it, and so on.
If I were happy for a given ADP application to be split across a WAN then I
would be happy to build an equivalent linked-tables application in the same
environment.
"Armando Vargas" <traba...@hotmail.com> wrote in message
news:eLPJ1h40...@TK2MSFTNGP06.phx.gbl...
Armando Vargas
This is a releif, I was already for something else to learn and then work
with it. Thanks Now I can focus in creating some new application this way.
Thanks, and hope the best for Access and all it folowers.
(Y)
Armando Vargas.
"Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> escribió en el mensaje
news:46b0172a$0$24761$da0f...@news.zen.co.uk...
David W. Fenton
news:46b0172a$0$24761$da0f...@news.zen.co.uk:
> The sidelining of ADP's is disappointing, but against that
> everything else has been seriously upgraded.
Not really. The new database format eliminates user-level security
and replication. Those are as important to some developers as ADPs
are to you folks.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Baz
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns997FC4DA3C3C6f9...@127.0.0.1...
Point taken. I've never found a serious use for those things (I only ever
do SQL Server back-ends these days) but then again I know that some people
feel the same about ADP's.
Vayse
and users, or that all security is through groups?
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns997FC4DA3C3C6f9...@127.0.0.1...
Douglas J. Steele
.accde)
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)
"Vayse" <vvv> wrote in message
news:uq27%230N1H...@TK2MSFTNGP03.phx.gbl...
Armando Vargas
Any comments on how to handle this? using tables to control Form access?
Thanks
Armando V.
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> escribió en el
mensaje news:uoZBQdU1...@TK2MSFTNGP03.phx.gbl...
Douglas J. Steele
details.
You might check out microsoft.public.access.security
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)
"Armando Vargas" <traba...@hotmail.com> wrote in message
news:%23RW%23uxU1H...@TK2MSFTNGP05.phx.gbl...
David W. Fenton
> Any comments on how to handle this? using tables to control Form
> access?
ULS (and replication) still work with MDBs. They are just not
supported for the new file format (which shows the direction MS
wants to take Access in).
DAVID
> "Armando Vargas" <traba...@hotmail.com> wrote in
> news:#RW#uxU1HH...@TK2MSFTNGP05.phx.gbl:
>
>> Any comments on how to handle this? using tables to control Form
>> access?
>
> ULS (and replication) still work with MDBs. They are just not
> supported for the new file format (which shows the direction MS
> wants to take Access in).
>
And also not supported are dao transactions on linked SQL
Server tables.
Also gone are the Access extensions built in Access
(as the original report export utilities and upsizing
utilities were), and VBA extensions built in Access (as
the original wizards were).
Nor AFAIK, are there any MS applications left that
are built in Access.
But the runtime is free. They don't think anyone will
be making money from selling runtime applications...
... and they don't want to damage Excel or Word by
adding extra database menu items.
(david)
Sylvain Lafontaine fill the blanks, no spam please
any real big advantage over using linked tables in comparaison of what's
really needed to fully access the power of SQL-Server. It's like attaching
a trailer to a car when what you need is a truck: it's slightly better than
having only a car without a trailer but not really much better for any real
hard work.
The solution to your post depends on how you see SQL-Server. If you see it
only as a bunch of tables located on a server - much like a MDB file
backend - then yes using ODBC linked tables is good enough for most
applications and using ADP will give you a slight advantage over them in
term of speed and convenience (for complexe queries). However, if you want
to see SQL-Server as it is - as a fully powered database server with lot of
functionalities under the hood - then both ODBC linked tables and ADP are
totally insufficient and not up to the task.
With ADP, MS has tried to do what they were unable to do with ODBC linked
tables but with the goal of keeping their ease of use; something like trying
to drive a big truck like if it was only car. Clearly this was a wrong
combination. If you want to tame the full power of SQL-Server then you will
need to learn it and work your a** out; not to rely on an automated process
such as JET with ODBC linked tables or ADP.
Both JET/ODBC linked tables and ADP are automated processes and as such,
they are practically undistinguishable from each other; so clearly, two is
probably one too many.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Reese Watt" <re...@hallmarkstone.com> wrote in message
Robert Morley
is too slow and awkward to program in compared to Access (not to mention the
disk and memory requirements for the framework itself), ACCDB/MDB format
don't offer you easy access to things like Views, Functions, SPs, etc. (and
every time you create a new one, you have to manually re-link them, or
re-program for it, or whatever; in ADPs, they're just there, no questions
asked, no programming required). For now, I'll ignore the design abilities
of ADPs, since you can do more and better in SQL EM or similar tools, though
they're certainly handy to have at times.
So what do you suggest to replace ADPs? I think MS's suggestion of ACCDB
format is an absolute joke, made by people who think and program a certain
way, and are incapable of considering that not everyone follows their
paradigm. There are advantages to ACCDB/MDB, I'll grant, such as the
ability to cache tables client-side, but it's a very different environment
than ADPs, and does not make a suitable "replacement".
Rob
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:u3ZrKwS...@TK2MSFTNGP02.phx.gbl...
Sylvain Lafontaine fill the blanks, no spam please
on client side; particularly with the WinForms (but I do not feal the same
weight with WebForms/ASP.NET). However, many particularities of SQL-Server
2005 - like the Notification Services - can only be adressed correctly with
.NET and other things like web services also can only be accessed correctly
from the .NET and with the upcoming VS 2008 and SQL-Server 2008, the
situation will become more and more pointing toward the .NET framework.
I know that there are some kits for accessing some web services from Access
but like ADP, these are fossils from the past. You can also circumvent some
of the problems of ADP/ODBC linked tables by using unbound forms but by
doing so not only you loose a good part of the easiness of Access but again,
many new (and future) features like the notification services (and up to a
certain point, web services) remain inaccessible and the situation will
become worse in 2008.
The question is not to know if you will switch to .NET but when you will do
so and the answer to this lies under a variety of factors; like the costs of
quad cores (now at about the same prices as the double cores of last year),
the number of installation of ADP (or MDB/ACCDB) at your clients' sites,
their needs in term of features, security, fiability, etc. In all cases,
it's more a personal and business decision than a magical recipe.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Robert Morley" <rmo...@magma.ca.N0.Freak1n.sparn> wrote in message
news:uHUc8vT2...@TK2MSFTNGP03.phx.gbl...
Robert Morley
concern for me, what other reasons are there to switch from Access (of
whatever form) to .NET? The last time I looked at it, I found no compelling
reasons to move in that direction at all, and in fact, found several major
blocks to moving in that direction.
Rob
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:uMKo9UX2...@TK2MSFTNGP06.phx.gbl...
Sylvain Lafontaine fill the blanks, no spam please
at.
The first chapter would probably deal with a list of the many limitations
and bugs of ADP. For example, ADP is practically unable to understand more
than a single schema name (with exception here and there) and it shows
additional bugs when this schema name is anything but dbo. A little problem
at the beginning when SQL-Server 2000 started but now a much bigger problem
with SQL-Server 2005 (and soon 2008) and one that will become worse and
worse as people start using the advanced features of schema naming provided
by SQL-Server 2005-8. Of course, if you don't use these and the only schema
present in your database is dbo. then you don't have this problem but in all
case, should be very long before you arrive at a new client site and notice
an extensive use of advanced schema naming.
Another problem is the lack of control over the transactions for bound
forms. Notice that at the beginning, after the launch of ADP-2000, they
have been promised by MS that they will be included in the 2002 version,
then in the 2003 version, then nothing.
The lack of control over the parameters for the resync command (nothing else
but the primary key), the absence of any Insert, Update and Delete commands,
the inability to access anything else but a direct link to a single database
at a time all severily limit the capabilities of ADP. (Not only .NET can
access/update multiple databases at a single time for a single form but it
can also use anything else, for example it can use a web service to access a
database protected by a firewall on a local LAN or even over the WAN;
something totally unavailable with ADP unless you start coding your own
messy code using unbound forms.).
Finally, I won't pass any comments on the support for Images and other Blob
files offered by Access and on these little things like the near total
absence of control over localisation/internationalisation/collation
problems. Of course, other things like the Notification Services, Microsoft
Message Queuing (MSMQ) Services or using a local storage are totally out of
question or might be very complicated to access for ADP or MDB/ACCDB.
(Notice that I don't want to enter into the details of each particular case
here in order to simplify the discussion.)
It's a fact that .NET is slow and need a powerful motor to make it advance
at a reasonable peace but at least, it offering you access and control about
anything you might think of. Excerpt for the speed problem (something that
will soon be solved by more powerfull hardware), you'll find it hard to
simply find something that it's not there. With ADP or MDB/ACCDB, doesn't
take long before having your head hitting the walls/ceiling and unlike the
speed problem of .NET, this is something that will never get solved. With
the soon the be released version of SQL-Server 2008 and VS 2008, the
situation will become even more unconfortable for ADP and MDB/ACCDB.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Robert Morley" <rmo...@magma.ca.N0.Freak1n.sparn> wrote in message
news:%2380RGwX...@TK2MSFTNGP02.phx.gbl...
Robert Morley
concerns for me at the moment (nor are they likely to be in the immediate
future), so .NET remains off my radar, but at least I know what sorts of
things it's good for, should my needs ever change.
Rob
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:OnZaRNe2...@TK2MSFTNGP06.phx.gbl...
John H
Should I get up in the morning? Like you all I have invested a lot of time
in the adp, the best feature for me is the close link with the stored
procedure to loose this would be a great shame and make me look at other
products - yes even outside microsoft. - In fact in the latest project I
have no tables just very keen fast sp's so for me to loose this power would
be a great shame and involve huge loss
I have in the mean time to come up with a plan to keep my sanity, and to
help me with this I need some advice or even examples of how to use oledb
from an mdb or accdb just NO ODBC its primative and makes access all that we
dont want it to be - a non enterprise product!
Please help me before I loose my marbles (If found please return to author)
Kindest regards to all adp lovers (an under estimated bunch with an
undervalued product)
John Hart
PS Microsoft give us some good news!
"Robert Morley" wrote:
> Yes, I expect that's exactly what they'll do, if they aren't already in the
> process of doing it. It's really frustrating, doubly so when you take into
> account that only a few years ago, they were encouraging everybody to move
> to the latest & greatest technology that was ADP's. And suddenly it's like,
> "Oh, we're not excited about this any more, so if you took our advice of a
> couple of years ago, you're up the creek now. We're not really even sorry
> about it, cuz we've got something new that we're all excited about now."
>
> I think MS needs the corporate equivalent of a time-out or a "think about
> what you did wrong and what the consequences were to others besides
> yourself".
>
>
> Rob
>
> "Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
> news:46ab17cc$0$15226$fa0f...@news.zen.co.uk...
> >I don't disagree with anything you say. Both technologies have their
> > advantages and disadvantages.
> >
> > The biggest problem with ADP's is Microsoft's attitude. They seem to have
> > decided to drop them like a hot potato, which means that we're unlikely to
> > get fixes for the many bugs, let alone new features. What's more, they
> > will
> > probably do a VB6 on it in some future version of Access i.e. kill it off
> > completely and ignore the howls of anguish from those of us with a big
> > investment in the technology.
> >
> > "Robert Morley" <rmo...@magma.ca.N0.Freak1n.sparn> wrote in message
> > news:uBtu9GH...@TK2MSFTNGP06.phx.gbl...
> >> Like you, I prefer designing in SQL EM, but I prefer working with ADPs
> >> for
> >> one simple reason (which I admit may be more specific to this project
> >> than
> >> some other types of projects): we have a lot of ad-hoc queries in our
> >> group. It's nice to know that if I create a new View (or Table or
> > anything
> >> else, for that matter), I don't have to worry about doing anything
> >> special
> >> to make those queries accessible to users. You just open (or refresh)
> >> the
> >> ADP, and they're all there automatically.
> >>
> >> Granted, I put a nicer front-end on the app, and refreshing an ADP when
> >> you're not showing the main database window is a bit of a challenge, but
> > not
> >> having to dynamically re-link views is a major bonus for me, and one of
> > the
> >> biggest reasons that I still refuse to go back to MDB/ACCDB format, no
> >> matter how hard MS tries to push me in the direction they somehow think
> > will
> >> be better for me, even though they know nothing about my environment.
> >>
> >>
> >>
> >> Rob
> >>
> >> "Baz" <ba...@REMOVEbcap.THEeuro1net.CAPScom> wrote in message
> >> news:46aa09ec$0$15224$fa0f...@news.zen.co.uk...
> >> > Yes, that is exactly the way MS is pushing you. I can't see anything
> >> > wrong
> >> > with mdb (and maybe accdb) with linked tables, I've done lots of
> >> > applications like this and also lots of ADP's, I don't find a great
> >> > deal
> >> > between them.
> >> >
> >> > Personally I don't like the database design features of ADP's. I much
> >> > prefer Enterprise Manager, and I always have it open on another screen
> >> > while
> >> > I'm working on an ADP.
> >> >
> >> > "Reese Watt" <re...@hallmarkstone.com> wrote in message
> >> > news:u6p4%232F0H...@TK2MSFTNGP02.phx.gbl...
> >> >> Baz,
> >> >>
> >> >> Thanks for the response. It feels like I would be going backwards to
> >> > revert
> >> >> to mdb's & ODBC, but I guess that is the way Microsoft is pushing me
> >> >> if
> > I
> >> >> don't want to go to .Net.
> >> >>
> >> >> Regarding linked SQL tables inside an mdb, I understand there is no
> >> >> way
> >> >> to
> >> >> edit the structure of those SQL tables. I really like the fact that
> >> >> in
> >> >> an
> >> >> ADP, I have the ability to edit the structure of views, queries,
> >> >> stored
> >> >> procedures, tables, etc. without having to open another application.
> >> >>
> >> >> Does Access 2007 and/or SQL 2005 give me any better tools for editing
> >> > those
> >> >> SQL objects than what I find in the Enterprise Manager for SQL 2000?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Reese