Access 2007 SQL over WAN

[aaron.kempf]

the handwriting was NEVER on the wall.

just because a retard in a wheelchair doesn't like ADP; just because
he doesn't have the mental capacity to learn SQL Server-- does that
mean that we all need to act like cripples and retards?


ADP won the war a long time ago.

and re:

I don't quite understand the logic here. Why would you do the work
to engineer an unbound app for running across a WAN when it's going
to take much, much less work (and far less cost) to simply run the
damned thing on Terminal Server? Yes, of course, once you've already
made the investment, TS becomes more expensive comparatively, but it
looks to me like a bad decision to begin with.



I completely call bullshit on unbound forms. but the ability to move
to ADP and work on SOMEONES DESKTOP instead of in a terminal session?

IT IS PRICELESS.

Microsoft will fix ADP or else

ADP is what the world needs.
Microsoft just hasn't released the new .NET version yet.

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

In the same way that's your responsability to learn how to drive
with a manual transmission if you want to conduct a big truck with
over 50,000 pounds of stock to drag behind, if you responsability
to take the situation in your own hands and go with unbound forms
if the situation become too complicated to be adequately fulfilled
by the automated process of Access.

I don't quite understand the logic here. Why would you do the work
to engineer an unbound app for running across a WAN when it's going
to take much, much less work (and far less cost) to simply run the
damned thing on Terminal Server? Yes, of course, once you've already
made the investment, TS becomes more expensive comparatively, but it
looks to me like a bad decision to begin with.

[]

I don't know if this problem will be corrected someday but even if
it's corrected in the next SP for Office, I would no longer
suggest to anyone to invest any effort into going with ADP for any
new project against SQL-Server.

Why is anyone surprised at this? MS has been deprecating ADPs for
several years now, starting with A2K3. They clearly had no clear
development path for them, and nobody on the development really on
top of them (there wouldn't have been so many reversions of fixed
bugs and new bugs in the 2nd and 3rd generation of ADP if that were
the case), and, frankly, the whole justification for the ADP never
made any sense to me in the first place. It all seemed that it was
based entirely around an irrational fear of Jet, and in taking Jet
out of the equation, they had to add a layer to replace it that
introduced problems of its own. And, of course, in somce
circumstances, ADO/OLEDB did just as much incorrect guessing about
what you wanted as Jet did.

To me, the handwriting was on the wall a long time ago, so I just
don't get why people went so heavily into ADP development as they
did.

 

[aaron.kempf]

re: Why is anyone surprised at this? MS has been deprecating ADPs for
several years now, starting with A2K3


what in the hell are you talknig about, David

Seriously... stop smoking pole and smoking crack.

ADP won the war.

Profiler-- Index Tuning Wizard-- ADP won the war; meanwhile Vb6 has
been killed off.

if you're using MDB for anything; you're helpless beyond all relief.

ADP rocks.

PRESSURE MICROSOFT TO FIX IT INSTEAD OF SPREAD MIS-INFORMATION

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

In the same way that's your responsability to learn how to drive
with a manual transmission if you want to conduct a big truck with
over 50,000 pounds of stock to drag behind, if you responsability
to take the situation in your own hands and go with unbound forms
if the situation become too complicated to be adequately fulfilled
by the automated process of Access.

I don't quite understand the logic here. Why would you do the work
to engineer an unbound app for running across a WAN when it's going
to take much, much less work (and far less cost) to simply run the
damned thing on Terminal Server? Yes, of course, once you've already
made the investment, TS becomes more expensive comparatively, but it
looks to me like a bad decision to begin with.

[]

I don't know if this problem will be corrected someday but even if
it's corrected in the next SP for Office, I would no longer
suggest to anyone to invest any effort into going with ADP for any
new project against SQL-Server.

Why is anyone surprised at this? MS has been deprecating ADPs for
several years now, starting with A2K3. They clearly had no clear
development path for them, and nobody on the development really on
top of them (there wouldn't have been so many reversions of fixed
bugs and new bugs in the 2nd and 3rd generation of ADP if that were
the case), and, frankly, the whole justification for the ADP never
made any sense to me in the first place. It all seemed that it was
based entirely around an irrational fear of Jet, and in taking Jet
out of the equation, they had to add a layer to replace it that
introduced problems of its own. And, of course, in somce
circumstances, ADO/OLEDB did just as much incorrect guessing about
what you wanted as Jet did.

To me, the handwriting was on the wall a long time ago, so I just
don't get why people went so heavily into ADP development as they
did.

 

[aaron.kempf]

Vb.net is a sad replacement for ADP.

There exists room for all 3-- but MDB is lame.
When WinFS hits the real world you guys will all see-- of course it is
faster to run SQL natively-- on the hardware level-- EMBEDDED-- then
use MDB.


ADP supports 16gb of ram on a _SERVER_.

MDB does not.

MDB can lick my nuts; as can anyone that uses it for anyone.


-Aaron

For TS, I agree with you that's often the right decision and one of my
client is precisely using it. However, like any other tools, it cannot
solve all problems and there is a lot of situations where JET with linked
tables and with or without TS can't do it; either because of a security
problem (I wouldn't trust any company who would give access to a table
containing my credit card number using an ODBC linked table), a capacity
problem (if the box or the network are already saturated, adding JET over
the equation will only be suicidal) or a performance problem (queries are
already too complicated to be made with JET/VBA in an efficient way).

Like any toolbox, the more tools you have in it, the better your capacity to
find the right tool for each job. You know the old proverb: if you only
have a hammer in your toolbox, everything around you will start looking like
a nail.

For ADP, they have started developing it for solving many problems with JET
and ODBC linked tables but obviously, the navire changed its direction at
mid-course and is now steered toward .NET technologies. Three years ago,
the possibilities for working with SQL-Server were JET/ODBC linked
tables/Passthrough queries at one side of the balance and ADP at the other
side but now, ADP seems to have been replaced with .NET for the other side.

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

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote innews:#[email protected]:

I don't quite understand the logic here. Why would you do the work
to engineer an unbound app for running across a WAN when it's going
to take much, much less work (and far less cost) to simply run the
damned thing on Terminal Server? Yes, of course, once you've already
made the investment, TS becomes more expensive comparatively, but it
looks to me like a bad decision to begin with.

[]

I don't know if this problem will be corrected someday but even if
it's corrected in the next SP for Office, I would no longer
suggest to anyone to invest any effort into going with ADP for any
new project against SQL-Server.

Why is anyone surprised at this? MS has been deprecating ADPs for
several years now, starting with A2K3. They clearly had no clear
development path for them, and nobody on the development really on
top of them (there wouldn't have been so many reversions of fixed
bugs and new bugs in the 2nd and 3rd generation of ADP if that were
the case), and, frankly, the whole justification for the ADP never
made any sense to me in the first place. It all seemed that it was
based entirely around an irrational fear of Jet, and in taking Jet
out of the equation, they had to add a layer to replace it that
introduced problems of its own. And, of course, in somce
circumstances, ADO/OLEDB did just as much incorrect guessing about
what you wanted as Jet did.

To me, the handwriting was on the wall a long time ago, so I just
don't get why people went so heavily into ADP development as they
did.

- Show quoted text -

 

[aaron.kempf]

I just swear that there is something simple going wrong here.

Have you ran profiler and looked for abnormalities?

ADP in general-- is a vastly superior platform

 

[aaron.kempf]

and of course-- the punchline?

DAP is the best thign to happen to MS Access ever.

DAP is almost as awesome as ADP.
does AJAX have anything comparable to DAP?

HELL NO

DAP work great for many users; it actually works quite a bit nicer
than ADP; becuase you can do web deployment.

I've done _EXTENSIVE_ development with Office Web Components.
and from where I'm sitting? As an Analysis Services _BADASS_?

Office 2007 can **** itselt until it has a good replacement for OFFICE
WEB COMPONENTS.
Office 2007 can **** itselt until it has a good replacement for OFFICE
WEB COMPONENTS.
Office 2007 can **** itselt until it has a good replacement for OFFICE
WEB COMPONENTS.
Office 2007 can **** itselt until it has a good replacement for OFFICE
WEB COMPONENTS.

For TS, I agree with you that's often the right decision and one of my
client is precisely using it. However, like any other tools, it cannot
solve all problems and there is a lot of situations where JET with linked
tables and with or without TS can't do it; either because of a security
problem (I wouldn't trust any company who would give access to a table
containing my credit card number using an ODBC linked table), a capacity
problem (if the box or the network are already saturated, adding JET over
the equation will only be suicidal) or a performance problem (queries are
already too complicated to be made with JET/VBA in an efficient way).

Like any toolbox, the more tools you have in it, the better your capacity to
find the right tool for each job. You know the old proverb: if you only
have a hammer in your toolbox, everything around you will start looking like
a nail.

For ADP, they have started developing it for solving many problems with JET
and ODBC linked tables but obviously, the navire changed its direction at
mid-course and is now steered toward .NET technologies. Three years ago,
the possibilities for working with SQL-Server were JET/ODBC linked
tables/Passthrough queries at one side of the balance and ADP at the other
side but now, ADP seems to have been replaced with .NET for the other side.

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

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote innews:#[email protected]:

I don't quite understand the logic here. Why would you do the work
to engineer an unbound app for running across a WAN when it's going
to take much, much less work (and far less cost) to simply run the
damned thing on Terminal Server? Yes, of course, once you've already
made the investment, TS becomes more expensive comparatively, but it
looks to me like a bad decision to begin with.

[]

I don't know if this problem will be corrected someday but even if
it's corrected in the next SP for Office, I would no longer
suggest to anyone to invest any effort into going with ADP for any
new project against SQL-Server.

Why is anyone surprised at this? MS has been deprecating ADPs for
several years now, starting with A2K3. They clearly had no clear
development path for them, and nobody on the development really on
top of them (there wouldn't have been so many reversions of fixed
bugs and new bugs in the 2nd and 3rd generation of ADP if that were
the case), and, frankly, the whole justification for the ADP never
made any sense to me in the first place. It all seemed that it was
based entirely around an irrational fear of Jet, and in taking Jet
out of the equation, they had to add a layer to replace it that
introduced problems of its own. And, of course, in somce
circumstances, ADO/OLEDB did just as much incorrect guessing about
what you wanted as Jet did.

To me, the handwriting was on the wall a long time ago, so I just
don't get why people went so heavily into ADP development as they
did.

- Show quoted text -

 

[Tony Toews [MVP]]

I no you intended an "h" to be included in that one word, but I
think it works OK as it.

<guffaw>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews [MVP]]

I disagree.

Microsoft understands the importance of ADP. First and foremost.

they just haven't given us the new version yet.

AFAIK there's nothing new in ADPs in A2007.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[David W. Fenton]

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

For TS, I agree with you that's often the right decision and one
of my client is precisely using it. However, like any other
tools, it cannot solve all problems and there is a lot of
situations where JET with linked tables and with or without TS
can't do it; either because of a security problem (I wouldn't
trust any company who would give access to a table containing my
credit card number using an ODBC linked table),

Who said anything about linked tables?

a capacity
problem (if the box or the network are already saturated, adding
JET over the equation will only be suicidal)

Er, if your back end is SQL Server, why would Jet saturate the
network? If you have a query Jet can't handle efficiently, then do a
passthrough in its place.

or a performance problem (queries are
already too complicated to be made with JET/VBA in an efficient
way).

Then why are they not made as views on the SQL Server? Or SPs, when
that's appropriate? Or passthroughs?

There are any number of ways to avoid the Jet performance
bottlenecks that do occur.

Like any toolbox, the more tools you have in it, the better your
capacity to find the right tool for each job. You know the old
proverb: if you only have a hammer in your toolbox, everything
around you will start looking like a nail.

ADPs *reduce* the number of tools you have available, and are simply
inconsistent and buggy.

For ADP, they have started developing it for solving many problems
with JET and ODBC linked tables but obviously, the navire changed
its direction at mid-course and is now steered toward .NET
technologies. Three years ago, the possibilities for working with
SQL-Server were JET/ODBC linked tables/Passthrough queries at one
side of the balance and ADP at the other side but now, ADP seems
to have been replaced with .NET for the other side.

That's not really comparable in terms of RAD to an Access solution.

 

[Sylvain Lafontaine]

«

Er, if your back end is SQL Server, why would Jet saturate the
network? If you have a query Jet can't handle efficiently, then do a
passthrough in its place. ....
Then why are they not made as views on the SQL Server? Or SPs, when
that's appropriate? Or passthroughs?

»

I don't really understand the purpose of your last post and personally, I
don't see any purpose in using Access if it's to use passthrough queries
thoughout the GUI and I think that other solutions are far more evolued than
that.

It looks like that you are trying to prove that Access with linked tables
and TS is the only solution to access a database over the WAN. Maybe you
have a personal interest in trying to prove this but for me, this kind of
debate is without any real interest.

 

[aaron.kempf]

what the hell f'in dipshit

what about SQL Server 2005 support?

there's nothing new in MDB; and there hasn't been in 15 years u f'in
crackhead


go play in the freeway, lamer

 

[aaron.kempf]

the new .NET version will be out in Office 2009.. that's when
everyone's going to finally upgrade to vienna