Re: Future of ADP's

There's also the Query Analyzer for building other things like functions and
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" <reese@xxxxxxxxxxxxxxxxx> wrote in message
news:eCO8nqH0HHA.5764@xxxxxxxxxxxxxxxxxxxxxxx
OK. Ignore that last question.

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" <reese@xxxxxxxxxxxxxxxxx> wrote in message
news:eB8GUnH0HHA.5644@xxxxxxxxxxxxxxxxxxxxxxx
Baz & Robert,

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" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uBtu9GH0HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
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" <bazz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:46aa09ec$0$15224$fa0fcedb@xxxxxxxxxxxxxxxxx
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" <reese@xxxxxxxxxxxxxxxxx> wrote in message
news:u6p4%232F0HHA.5772@xxxxxxxxxxxxxxxxxxxxxxx
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




"Baz" <bazz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:46a9afaa$0$31714$db0fefd9@xxxxxxxxxxxxxxxxx
ADP's are as good as dead. While they are still supported by Access
2007,
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" <reese@xxxxxxxxxxxxxxxxx> wrote in message
news:us4bRD8zHHA.1212@xxxxxxxxxxxxxxxxxxxxxxx
Here's a brief summary of my career:

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.
Data*** 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
















.

Loading