ADPs /// idull thoughts

[Lyle Fairfield]

Recently I've used ADPs in ways in which I have not previously used MDBs.
I've been encouraged to do so because of ADPs clear separation from the
data in the db, and by their ability to use MS-SQL permissions to
compartmentalize things.

1. Recently I've received requests for spin-offs from an installed
application, mostly to accommodate other departments in the same
organization who want reports based on the data input and generated by the
main application. How to do this? Include the reports in the main
operation? Well, it's sufficiently complicated as it is, and the owning
department doesn't feel so comfortable about sharing it. My solution is to
build tiny ADPs with a few reports, to set server level permissions which
allow the members of the peripheral department to execute the stored
procedures and to deliver those tiny ADPs. No danger that something one
does to facilitate these reports screws up the main application. No danger
the report users will muck up something in the main application; all they
have is an ADP with a menu bar that allows them to view and print a few
reports. In one case, where there the ADP is only one report, the ADP opens
to the report, and closes when the report is closed.

2. I've never been quite satisfied with the division among data, ui, and
business logic one gets with an Access application. But I'm experimenting
with a situation where this will be pretty clear-cut. The data is in an MS-
SQL db. The UI is a web-based ASP-html application. The application is
quite calculation intensive, in fact it exists only to provide data for the
calculation. So the calculation is done from anyone of three ADPS on three
different machines (one should do but why takes chances!). They are
programmed to examine the db every 5 minutes; if they find a switch has
been set to calculate, they turn the switch off and calculate. Since the
calculations are discreet for each user, there is no chance of overlapping.
Advantages, well it keeps the code every safe. Calculations which are
pretty intensive don't slow down the server or the user's machine. And the
calculations can be modified without disturbing the ui, or the db.

<drivel ... no point to flame me coz I'm going to be away for a couple of
weeks>

Mary: Do you want the good news or the bad news?
Bill: Give me the bad news first.
Mary: It seems a lot of the developers are too stupid, too lazy or too
ornery to learn to use ADPs.
Bill: Shit, how we gonna keep selling Access? We told these people ADPs was
the greatest thing since stealing Windoz.
Mary: That's the good news Bill. All the insiders are going to say that
MDBS with ODBC is the preferred way for Access to hook up to MS-SQl Server.
So the dinosaurs will feel vindicated and confirmed. And the cash registers
will keep-a-goin tinkle.
Bill: What about the non-insiders?
Mary: Bill, THIS IS AMERICA!

--
Lyle
--
use iso date format: yyyy-mm-dd
http://www.w3.org/QA/Tips/iso-date
--
The e-mail address isn't, but you could use it to find one.

[Larry Linson]

"Lyle Fairfield" wrote

. . .
<drivel ... no point to flame me coz I'm
going to be away for a couple of
weeks>
. . .

Flame you? Perish the thought, Lyle. You embarrass yourself in public quite
enough without any help from any of us.

[David W. Fenton]

Lyle Fairfield <Lo******@FFDBA.Com> wrote in
news:Xn*******************@130.133.1.4:

1. Recently I've received requests for spin-offs from an installed
application, mostly to accommodate other departments in the same
organization who want reports based on the data input and
generated by the main application. How to do this? Include the
reports in the main operation? Well, it's sufficiently complicated
as it is, and the owning department doesn't feel so comfortable
about sharing it. My solution is to build tiny ADPs with a few
reports, to set server level permissions which allow the members
of the peripheral department to execute the stored procedures and
to deliver those tiny ADPs. No danger that something one does to
facilitate these reports screws up the main application. No danger
the report users will muck up something in the main application;
all they have is an ADP with a menu bar that allows them to view
and print a few reports. In one case, where there the ADP is only
one report, the ADP opens to the report, and closes when the
report is closed.
So, exactly how is an ADP superior to an MDB for any of that?
2. I've never been quite satisfied with the division among data,
ui, and business logic one gets with an Access application. But
I'm experimenting with a situation where this will be pretty
clear-cut. The data is in an MS- SQL db. The UI is a web-based
ASP-html application. The application is quite calculation
intensive, in fact it exists only to provide data for the
calculation. So the calculation is done from anyone of three ADPS
on three different machines (one should do but why takes
chances!). They are programmed to examine the db every 5 minutes;
if they find a switch has been set to calculate, they turn the
switch off and calculate. Since the calculations are discreet for
each user, there is no chance of overlapping. Advantages, well it
keeps the code every safe. Calculations which are pretty intensive
don't slow down the server or the user's machine. And the
calculations can be modified without disturbing the ui, or the db.

So, exactly how is an ADP superior to an MDB for any of that?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:ip********************************@4ax.com...

On Thu, 15 Jul 2004 02:25:34 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:

"Lyle Fairfield" wrote

. . .
<drivel ... no point to flame me coz I'm
going to be away for a couple of
weeks>
. . .

Flame you? Perish the thought, Lyle. You embarrass yourself in public

quiteenough without any help from any of us.

LOL!!!

Mind you, IMHO, he also enlightens us just as frequently.

Lyle da' man.

[Steve Jorgensen]

I have no problem with your personal preference of ADPs over MDBs. What I do
have a problem with is your insistence on insulting the intelligence down
those of us who have tried both, and find MDBs clearly superior for our needs.

Perhaps, if Microsoft would fix any of the 50,000 or so glaring bugs in ADPs,
more of us would choose to try to use them instead of giving up after the
work-arounds to the work-arounds to the work-arounds fail to get our ADP apps
to work.

On 14 Jul 2004 19:27:14 GMT, Lyle Fairfield <Lo******@FFDBA.Com> wrote:

Recently I've used ADPs in ways in which I have not previously used MDBs.
I've been encouraged to do so because of ADPs clear separation from the
data in the db, and by their ability to use MS-SQL permissions to
compartmentalize things.

1. Recently I've received requests for spin-offs from an installed
application, mostly to accommodate other departments in the same
organization who want reports based on the data input and generated by the
main application. How to do this? Include the reports in the main
operation? Well, it's sufficiently complicated as it is, and the owning
department doesn't feel so comfortable about sharing it. My solution is to
build tiny ADPs with a few reports, to set server level permissions which
allow the members of the peripheral department to execute the stored
procedures and to deliver those tiny ADPs. No danger that something one
does to facilitate these reports screws up the main application. No danger
the report users will muck up something in the main application; all they
have is an ADP with a menu bar that allows them to view and print a few
reports. In one case, where there the ADP is only one report, the ADP opens
to the report, and closes when the report is closed.

2. I've never been quite satisfied with the division among data, ui, and
business logic one gets with an Access application. But I'm experimenting
with a situation where this will be pretty clear-cut. The data is in an MS-
SQL db. The UI is a web-based ASP-html application. The application is
quite calculation intensive, in fact it exists only to provide data for the
calculation. So the calculation is done from anyone of three ADPS on three
different machines (one should do but why takes chances!). They are
programmed to examine the db every 5 minutes; if they find a switch has
been set to calculate, they turn the switch off and calculate. Since the
calculations are discreet for each user, there is no chance of overlapping.
Advantages, well it keeps the code every safe. Calculations which are
pretty intensive don't slow down the server or the user's machine. And the
calculations can be modified without disturbing the ui, or the db.

<drivel ... no point to flame me coz I'm going to be away for a couple of
weeks>

Mary: Do you want the good news or the bad news?
Bill: Give me the bad news first.
Mary: It seems a lot of the developers are too stupid, too lazy or too
ornery to learn to use ADPs.
Bill: Shit, how we gonna keep selling Access? We told these people ADPs was
the greatest thing since stealing Windoz.
Mary: That's the good news Bill. All the insiders are going to say that
MDBS with ODBC is the preferred way for Access to hook up to MS-SQl Server.
So the dinosaurs will feel vindicated and confirmed. And the cash registers
will keep-a-goin tinkle.
Bill: What about the non-insiders?
Mary: Bill, THIS IS AMERICA!

--
Lyle
--
use iso date format: yyyy-mm-dd
http://www.w3.org/QA/Tips/iso-date

[Michael \(michka\) Kaplan [MS]]

I will go so far as a Microsoft employee to state that any position that
insults customers is an unsupportable one from a corporate standpoint --
such behavior is not appropriate and it is not the sort of thing that
happens in strategic conversations about customers in any group (including
the Access group, where I used to work).

ADPs have (and had, and will continue to have) a bold promise and have many
important features that can make any reasonable developer want to use them.
Over time that list can only become more compelling in more areas, as new
features and functionalities are entered.

But ADPs have (and had, and will continue to have) technical issues and
limitations that can make any reasonable developer decide to not use them,
until and unless those issues are addressed or the limitations do not apply
to their work any more. Some will doubtlessly be fixed (as has happened
across the last several versions) while others are "by design" issues for
SQL Server itself and are the cost of using SQL Server as a direct datastore
without a local intermediary such as Jet.

Anyone who is not willing to see that both of the above paragraphs are true,
and who would go so far as to call people in the group to which they do not
belong "stupid" or be otherwise pejorative towards them, has an opinion that
I would hope that all reasonable developers see as entirely unsupportable.

And I will stand by all of these statements and remove the usual "no
warrenty" boileplate to make that clear (because if any of them ever turned
out to not be true about Microsoft then I would not want to work for
Microsoft any longer).
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
Windows International Division

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:2e********************************@4ax.com...

I have no problem with your personal preference of ADPs over MDBs. What I do have a problem with is your insistence on insulting the intelligence down
those of us who have tried both, and find MDBs clearly superior for our needs.
Perhaps, if Microsoft would fix any of the 50,000 or so glaring bugs in ADPs, more of us would choose to try to use them instead of giving up after the
work-arounds to the work-arounds to the work-arounds fail to get our ADP apps to work.

On 14 Jul 2004 19:27:14 GMT, Lyle Fairfield <Lo******@FFDBA.Com> wrote:

Recently I've used ADPs in ways in which I have not previously used MDBs.
I've been encouraged to do so because of ADPs clear separation from the
data in the db, and by their ability to use MS-SQL permissions to
compartmentalize things.

1. Recently I've received requests for spin-offs from an installed
application, mostly to accommodate other departments in the same
organization who want reports based on the data input and generated by themain application. How to do this? Include the reports in the main
operation? Well, it's sufficiently complicated as it is, and the owning
department doesn't feel so comfortable about sharing it. My solution is tobuild tiny ADPs with a few reports, to set server level permissions which
allow the members of the peripheral department to execute the stored
procedures and to deliver those tiny ADPs. No danger that something one
does to facilitate these reports screws up the main application. No dangerthe report users will muck up something in the main application; all they
have is an ADP with a menu bar that allows them to view and print a few
reports. In one case, where there the ADP is only one report, the ADP opensto the report, and closes when the report is closed.

2. I've never been quite satisfied with the division among data, ui, and
business logic one gets with an Access application. But I'm experimenting
with a situation where this will be pretty clear-cut. The data is in an MS-SQL db. The UI is a web-based ASP-html application. The application is
quite calculation intensive, in fact it exists only to provide data for thecalculation. So the calculation is done from anyone of three ADPS on threedifferent machines (one should do but why takes chances!). They are
programmed to examine the db every 5 minutes; if they find a switch has
been set to calculate, they turn the switch off and calculate. Since the
calculations are discreet for each user, there is no chance of overlapping.Advantages, well it keeps the code every safe. Calculations which are
pretty intensive don't slow down the server or the user's machine. And thecalculations can be modified without disturbing the ui, or the db.

<drivel ... no point to flame me coz I'm going to be away for a couple of
weeks>

Mary: Do you want the good news or the bad news?
Bill: Give me the bad news first.
Mary: It seems a lot of the developers are too stupid, too lazy or too
ornery to learn to use ADPs.
Bill: Shit, how we gonna keep selling Access? We told these people ADPs wasthe greatest thing since stealing Windoz.
Mary: That's the good news Bill. All the insiders are going to say that
MDBS with ODBC is the preferred way for Access to hook up to MS-SQl Server.So the dinosaurs will feel vindicated and confirmed. And the cash registerswill keep-a-goin tinkle.
Bill: What about the non-insiders?
Mary: Bill, THIS IS AMERICA!

--
Lyle
--
use iso date format: yyyy-mm-dd
http://www.w3.org/QA/Tips/iso-date

[David W. Fenton]

"Michael \(michka\) Kaplan [MS]" <mi*****@online.microsoft.com>
wrote in news:40********@news.microsoft.com:

Anyone who is not willing to see that both of the above paragraphs
are true, and who would go so far as to call people in the group
to which they do not belong "stupid" or be otherwise pejorative
towards them, has an opinion that I would hope that all reasonable
developers see as entirely unsupportable.

Lyle is the only one who has ever questioned the competence of those
of us who register our dismay over the state of ADPs.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc