Access 2007 Front End for SQL 2005

G

Guest

I'm sorry : my posting was not so explicit. I was expressing my strong
disappointment that ADP technology is to be abandonned, as it appears from
this whole discussion above.
I know, by solid experience, that developping big or small applications with
ADP presents huge advantages : you get the best of two worlds : SQL Server
for data manipulations, and ACCESS for user interface (easy-to-use filter for
data browsing, report generator, ......). In addition, the macros of ACCESS
can boost developments when used as VB code generator.
The option of MDB with ODBC links is definitely not compatible with strong
multi-users applications.
I would be glad to learn that SQL Server 2005 databases could be accessed in
future with ADP ........
 
A

aaron.kempf

I'm glad also.

but Microsoft isn't clearly communicating this.

words like 'reccomendation'
WTF is this company thinking?

i mean; they're going to support it.
but they're reccomending that people use MDB or ACCDB linked tables?

ROFL
what an ass-backwards company

-Aaron
 
B

Bill Mosca, MS Access MVP

The option of MDB with ODBC links is definitely not compatible with strong
multi-users applications.

I guess all the MDEs I've developed and supported over the last 8 years
which use ODBC to SQL Server databases with up to 150 concurrent users were
just one big bad idea, huh? <g>
 
D

dbahooker

exactly.

it would have been much easier, and much more valuable-- to develop
these applications as Access Data Projects.

yet another Access MVP that doesn't know jack shit about SQL

aren't you tired of re-linking and re-freshing and pushing around query
defs?
keeping everything in 1 place is archtecticurally a much better
solution.

easier to develop; easier to manage; and better peformance

-Aaron
 
D

dbahooker

8 years?

ADP has been out 7 years; did you ever consider using a real database
ENGINE?

MDB is like running around like a chicken with your head cut off

-Aaron
ADP Nationalist
 
G

Guest

Anyway, it is clear to me that it is better to have run by SQL engine what
SQL engine is good for : security, data transformation and updating, complex
queries and analyses. Needless to add that it is preferable to have complex
queries executed on the server rather than on clients.
 
R

Rick Brandt

Jason said:
Anyway, it is clear to me that it is better to have run by SQL engine what
SQL engine is good for : security, data transformation and updating, complex
queries and analyses. Needless to add that it is preferable to have complex
queries executed on the server rather than on clients.

And anyone using an MDB/MDE against a SQL Server back end can leverage all of
those features from the server. Any query I want executed on the server I can
send to the server. I can also use DTS, Stored Procedures, Views, Replication,
basically any feature that is available in SQL Server can be utilized by an
MDB/MDE front end.

Is there some reason you believe this not to be the case?
 
A

aaron.kempf

you can't (practically) use Sprocs with MDB.

I mean; what a joke.. what is it 10 steps?

coding and DAO and a whole bunch of work?

in Access Data Projects; it is easy as pie


-Aaron
ADP Nationalist
 
A

aaron.kempf

I mean seriously... please detail the steps for sprocs.. bind a sproc
to a form; and allow people to change sproc parameters.

in an ADP it doesn't take ANY CODE to bind a sproc to a form.

in an MDB it takes 10 silly steps.

INSERT, AUTOFORM works for me on sprocs

-Aaron
 
D

dbahooker

also; how are you going to LAUNCH DTS packages from the client?

you need to make sure that the end users have DTS tools installed?

ROFL

with ADP; you can launch a DTS package _FROM_ the database server
itself.

it's all a matter of context and location.
and MDB has NEITHER

-Aaron
 
G

Guest

OK, but it has nothing to do with adp platform, which allows direct
manipulations of SQL objects in Access, most often without writing any code.
By this way, development is 3, 4 or 5 times faster ...
 
B

Bill Mosca, MS Access MVP

Jason

I've worked with both. I don't try to do the design through code. You are
absolutely right. That would be way to slow. I use the Enterprise Manager
and Query Analyzer to work on the back end.

I just don't like the loss of functionality and features when working with
an ADP.
 
G

Guest

Anyway, it is no use complaining. I'll have to go back to odbc. But I was
accustomed to do the maximum of "hard" job in SQL 2000 : stored procs, views,
creation/killing of temporary tables, use of cursors when necessary, ... And
I was using Access 1. to build the user interface, and 2. as front end to
run application on the server. And I found all this terrifically productive
....
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top