Access with SQL [ADP?]

I would have thought an Access ADP would be the trick for what this many has
asked for.
The fact that nobody in this thread has even mentioned these ADPs is
somewhat troubling to me. Is this dead end stuff? When I first read about
ADP's, I thought, "Hey! I can leverage my existing knowledge of how to get
Access to get up and dance, and take advantage of the speed of SQL at the
same time" In the months (well year now) that I've been wanting to move to
this approach, I have heard less and less about ADPs.
Anyone have any input on ADPs, and why they might not be a good solution for
a client-serverh app like this?
-BrianDP
"James Goodman" <j a m e s@.norton-associates.co.u k> wrote in message
news:c08ddq$48t$1@.titan.btinternet.com...
> Is Access forming a front-end db for a SQL DB?
> Would it not be possible to utilise some kind of web site (ASP) or
similar.
> It will run much faster over a WAN.
> Or are you 'replicating' the SQL Server db to an AccessDB?
> You dont need MSDE to connect to a SQL Server DB. MSDE is the 'desktop'
> version of SQL Server.
>
>
> --
> Cheers,
> James Goodman MCSE, MCDBA
> http://www.angelfire.com/sports/f1pictures
>I'm in the final stages of converting an MDB to ADP. It is much faster, but
there are gotchas to work around. If you don't already know SQL Server, the
learning curve is even steeper.
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"dp" <nobody@.mrspam.com> wrote in message
news:Vxo3c.92640$C65.17470@.nwrddc01.gnilink.net...
> I would have thought an Access ADP would be the trick for what this many
has
> asked for.
> The fact that nobody in this thread has even mentioned these ADPs is
> somewhat troubling to me. Is this dead end stuff? When I first read
about
> ADP's, I thought, "Hey! I can leverage my existing knowledge of how to
get
> Access to get up and dance, and take advantage of the speed of SQL at the
> same time" In the months (well year now) that I've been wanting to move
to
> this approach, I have heard less and less about ADPs.
> Anyone have any input on ADPs, and why they might not be a good solution
for
> a client-serverh app like this?
> -BrianDP
>
> "James Goodman" <j a m e s@.norton-associates.co.u k> wrote in message
> news:c08ddq$48t$1@.titan.btinternet.com...
> similar.
>|||Well, I'm learning the curve. Data types are different, there are views,
and these crazy SP_MOFO_THIS. No, I'm excited about the power that SQL will
provide. I had one task - it was one screen that queried two tables HUGE
tables, > 1M recs each, and filtered out the information, sliced it and
diced it a certain way, then reported on it. The version I wrote as an MDB,
when you hit the "go" button, would take about 30 seconds. In the new ADP I
wrote, it takes 3 seconds.
This increase in speed is enough for me. I'll learn ADO, I'll learn to
store my procedures. I'll learn about views, and such.
What my real question though is, "Is microsoft planning on dropping this
'avenue' any time in the near future?" I don't mind learning a new
language, or new methods for an older language, what I DO mind, is learning
some new microsoft strategy that is only going to be "hot stuff" for about 5
months before they change the synatax, and start calling it something else -
like with DAO to ADO. Well, for whatever reason they had to go that
direction fine, I just want to know that if I sink my teeth into ADO, that
I'll be able to be comfortable there for a while (say 5 years or so) before
microsoft some along with the .NET and scoops me up into some new
handy-dandy record-handling language.
-Brian
"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
news:eIqA7vgBEHA.892@.TK2MSFTNGP09.phx.gbl...
> I'm in the final stages of converting an MDB to ADP. It is much faster,
but
> there are gotchas to work around. If you don't already know SQL Server,
the
> learning curve is even steeper.
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
> "dp" <nobody@.mrspam.com> wrote in message
> news:Vxo3c.92640$C65.17470@.nwrddc01.gnilink.net...
> has
> about
> get
the
> to
> for
'desktop'
>|||You're too late. The latest fad is already ADO.NET which bears little
resembalance to ADO.
No need to wonder - you are guaranteed to be victimized by a new fads on a
regular basis.
"dp" <nobody@.mrspam.com> wrote in message
news:YHq3c.80899$6K.23711@.nwrddc02.gnilink.net...
> Well, I'm learning the curve. Data types are different, there are views,
> and these crazy SP_MOFO_THIS. No, I'm excited about the power that SQL
will
> provide. I had one task - it was one screen that queried two tables HUGE
> tables, > 1M recs each, and filtered out the information, sliced it and
> diced it a certain way, then reported on it. The version I wrote as an
MDB,
> when you hit the "go" button, would take about 30 seconds. In the new ADP
I
> wrote, it takes 3 seconds.
> This increase in speed is enough for me. I'll learn ADO, I'll learn to
> store my procedures. I'll learn about views, and such.
> What my real question though is, "Is microsoft planning on dropping this
> 'avenue' any time in the near future?" I don't mind learning a new
> language, or new methods for an older language, what I DO mind, is
learning
> some new microsoft strategy that is only going to be "hot stuff" for about
5
> months before they change the synatax, and start calling it something
else -
> like with DAO to ADO. Well, for whatever reason they had to go that
> direction fine, I just want to know that if I sink my teeth into ADO, that
> I'll be able to be comfortable there for a while (say 5 years or so)
before
> microsoft some along with the .NET and scoops me up into some new
> handy-dandy record-handling language.
> -Brian
>
> "Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
> news:eIqA7vgBEHA.892@.TK2MSFTNGP09.phx.gbl...
> but
> the
many
to
> the
move
solution
> 'desktop'
>|||Will ADO as I know it, the connection string, etc, will that continue to
morph over time as well? Every time Microsoft releases a new version of
Access/SQL Server I'm going to have to go tweek my code? This doesn't seem
right. I mean, I realize people aren't (for the most part) out there still
programming in Cobol, and wondering why people are expecting them to move
on. I just want to know that Microsoft won't drop support for ADO in the
near future.
-Brian|||I expect it will continue to be supported for some time.
However it will continue to "morph". Morphing is not the problem.
There is a special place in DLL hell for users of Access - Jet - MDAC.
You stand a good chance of
1) do a forced upgrade
2) having such upgrade break your application
3) having data reliablity problems due to 1 and 2.
Unlike the SQL people, the Access - Jet - MDAC
people don't seem to understand that data is important.
"dp" <nobody@.mrspam.com> wrote in message
news:Jkj4c.6$F9.3@.nwrddc01.gnilink.net...
> Will ADO as I know it, the connection string, etc, will that continue to
> morph over time as well? Every time Microsoft releases a new version of
> Access/SQL Server I'm going to have to go tweek my code? This doesn't
seem
> right. I mean, I realize people aren't (for the most part) out there
still
> programming in Cobol, and wondering why people are expecting them to move
> on. I just want to know that Microsoft won't drop support for ADO in the
> near future.
> -Brian