ADPs ... another view

[Lyle Fairfield]

I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta,
and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the
internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly. The "school board" application
above is in the process of reverting to using the Board's SQL server over
their intranet. This was a planned change and is in place to comply with
their policies, and not for any performance or known security issue.

I have not experienced any major problems with ADPs. There were three
issues which I found puzzling for a brief time:

1. I could not get sub forms to link properly; I can now, but I cannot
explain what I am doing new, or differently (incidentally, I started
linking my own "sub forms" and found this to be simple and powerful);

2. I could not filter the record source for a report at run time; in MS's
ADP newsgroup, someone pointed out that a report's Input Parameters could
be set to a form control's value, or to a public function, and that solved
that problem completely;

3. I found that ADPs seem very sensitive to the proper installation of MDAC
(specifically ADO). If it’s not A-1 they crash, with an error message which
is not so helpful, and, AFAIK, undocumented. Finding MS's Comcheck utility
allowed me to check and verify what the problem was, but this still
troubles me, as I find that IT departments can be lax about these
installations.

Typically my applications have hundreds of stored procedures, and only a
few small VBA modules. Often my VBA provides parameters for SPROCs only. I
have learned just how powerful VIEWS can be, and I am especially impressed
with updating them; that is one can update a VIEW which is scripted in some
particular way, and this updates one of the source tables for the VIEW. I
also note that one can use a VIEW as the source for a SPROC, combining the
filtering of the one, with the immediacy of the other.

Although I don't use much VBA, in the school board application I have a
time tabling segment. As it looks at many possible solutions (factorials in
some cases) it is very code intensive, and for this I use VBA, preferring
not to have so much drain on the Server CPU (SPROC solution), when I can
distribute that drain among many client machines (VBA solution). For the
time tabling, I use batch updates. To date, these many thousands of updates
have not resulted in any problems or errors. The VBA solution and the SPROC
solution take about the same time to do the same thing. BTW, do you know
that one can largely duplicate one's VBA code in SPROCS because one has
IFS, CASE and LOOPS available, variables, and UDFs there?

I could not advise anyone else about whether or not to use MDBs, or ADPs.
I've never used ODBC. I am by nature a problem solver, and quite compulsive
about code. I prefer a platform that does less for me, rather than one that
does more. I develop in ADPs and not in MDBs, and probably would not take
on an MDB job, even if it were quite lucrative. I think that ADPs are very
much advanced over MDBs in both concept and realization.

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems
his clients are happy.

I have been working with databases since the time of DBaseIII, about 1983
(I think). I have progressed through FoxBase, FoxPro, Clipper and ...
Access. Clipper is likely to remain for me the most useful p-coding
language with which I have ever dealt, but I do like ADPs.

I am sorry if you feel that I should have attached this to one of the
current threads on this subject. I feel that I could not have done so
without contradicting what others have said, or confronting them. And I
simply wish to state my views, based on my experience. It is that ADPs are
great.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[DFS]

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta,
and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the
internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly.
You do know you can buy a Developer version of SQL Server 2000 for about
$50?
The "school board" application
above is in the process of reverting to using the Board's SQL server over
their intranet. This was a planned change and is in place to comply with
their policies, and not for any performance or known security issue.

I have not experienced any major problems with ADPs. There were three
issues which I found puzzling for a brief time:

1. I could not get sub forms to link properly; I can now, but I cannot
explain what I am doing new, or differently (incidentally, I started
linking my own "sub forms" and found this to be simple and powerful);

2. I could not filter the record source for a report at run time; in MS's
ADP newsgroup, someone pointed out that a report's Input Parameters could
be set to a form control's value, or to a public function, and that solved
that problem completely;

3. I found that ADPs seem very sensitive to the proper installation of MDAC (specifically ADO). If it’s not A-1 they crash, with an error message which is not so helpful, and, AFAIK, undocumented. Finding MS's Comcheck utility
allowed me to check and verify what the problem was, but this still
troubles me, as I find that IT departments can be lax about these
installations.

Typically my applications have hundreds of stored procedures, and only a
few small VBA modules. Often my VBA provides parameters for SPROCs only. I
have learned just how powerful VIEWS can be, and I am especially impressed
with updating them; that is one can update a VIEW which is scripted in some particular way, and this updates one of the source tables for the VIEW. I
also note that one can use a VIEW as the source for a SPROC, combining the
filtering of the one, with the immediacy of the other.

Although I don't use much VBA, in the school board application I have a
time tabling segment. As it looks at many possible solutions (factorials in some cases) it is very code intensive, and for this I use VBA, preferring
not to have so much drain on the Server CPU (SPROC solution), when I can
distribute that drain among many client machines (VBA solution). For the
time tabling, I use batch updates. To date, these many thousands of updates have not resulted in any problems or errors. The VBA solution and the SPROC solution take about the same time to do the same thing. BTW, do you know
that one can largely duplicate one's VBA code in SPROCS because one has
IFS, CASE and LOOPS available, variables, and UDFs there?

I could not advise anyone else about whether or not to use MDBs, or ADPs.
I've never used ODBC. I am by nature a problem solver, and quite compulsive about code. I prefer a platform that does less for me, rather than one that does more. I develop in ADPs and not in MDBs, and probably would not take
on an MDB job, even if it were quite lucrative. I think that ADPs are very
much advanced over MDBs in both concept and realization.

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems
his clients are happy.

I have been working with databases since the time of DBaseIII, about 1983
(I think). I have progressed through FoxBase, FoxPro, Clipper and ...
Access. Clipper is likely to remain for me the most useful p-coding
language with which I have ever dealt, but I do like ADPs.

I am sorry if you feel that I should have attached this to one of the
current threads on this subject. I feel that I could not have done so
without contradicting what others have said, or confronting them. And I
simply wish to state my views, based on my experience. It is that ADPs are
great.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Peter Doering]

On Thu, 8 Jan 2004 17:38:49 -0500, DFS wrote:

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

Initially my applications have started as accessing MS-SQL Server over the
internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly.

You do know you can buy a Developer version of SQL Server 2000 for about
$50?

Correct, e.g.
http://www.amazon.com/exec/obidos/AS...359866-8410550

Peter

--
No mails please.

[TC]

"DFS" <no****@nospam.com> wrote in message
news:vv************@corp.supernews.com...

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta, and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly.

You do know you can buy a Developer version of SQL Server 2000 for about
$50?

YIKES! I assumed there'd be some zeros on the end of that! And the other
respondent's link identifies "used" copies for $25 !!

TC

[(Pete Cresswell)]

RE/

There were three
issues

I dabbled in the Access 2000 version, but didn't feel comfortable enough to try
it on my new project at the time - especially after reading a passage in an MS
Access 2000 "How-To" book that said the 2000 version was "almost ready for prime
time".

I'd still like to try it - especially after hearing that you've got apps that
work over an internet connection. I'm squashing the final bugs in a project
control app that the client swore was just for his and a couple of other local
divisions - and now they're taking it national (Philadelphia is the client's
location and Chicago is their parent org) over the corporate WAN. Works OK,
but I'm dreading the day somebody wants to use it from home over dialup.

Have you figured out a way to pre-populate combo boxes? - i.e. load them up
before a form opens so the user does not have to wait for a large list to load.
Currently I resort to having AutoExec load JET cache tables in a work DB in
C:\TEMP.

Also, do you implement disconnected edits? - i.e. user clicks an "Edit" button,
the form's controls become editable, but nothing goes into the DB until the user
clicks "Save"....and clicking "Cancel" repopulates the form as it was before the
user clicked "Edit"...?
--
PeteCresswell

[Lyle Fairfield]

"(Pete Cresswell)" <x@y.z> wrote in
news:3o********************************@4ax.com:

RE/

There were three
issues

I dabbled in the Access 2000 version, but didn't feel comfortable enough
to try it on my new project at the time - especially after reading a
passage in an MS Access 2000 "How-To" book that said the 2000 version
was "almost ready for prime time".

I'd still like to try it - especially after hearing that you've got apps
that work over an internet connection. I'm squashing the final bugs in
a project control app that the client swore was just for his and a
couple of other local divisions - and now they're taking it national
(Philadelphia is the client's location and Chicago is their parent org)
over the corporate WAN. Works OK, but I'm dreading the day somebody
wants to use it from home over dialup.

Have you figured out a way to pre-populate combo boxes? - i.e. load them
up before a form opens so the user does not have to wait for a large
list to load. Currently I resort to having AutoExec load JET cache
tables in a work DB in C:\TEMP.

Also, do you implement disconnected edits? - i.e. user clicks an "Edit"
button, the form's controls become editable, but nothing goes into the
DB until the user clicks "Save"....and clicking "Cancel" repopulates the
form as it was before the user clicked "Edit"...?

Yes ... a lot. I also write HTA applications, and with them, this is the
only way, with Reset returning the form to its original state.

I've never experienced any difficulty with waits for combo boxes to populate.
But then when a combo box list's count is likely to be more than a few dozen,
I will probably program this as an external popup form.

I have not used dialup connections extensively with ADPs, and would recommend
something quicker. But I do know that with one small app I wrote, various
people were using the app simultaneously across the USA, as a pseudo
"whiteboard" for committee meetings and deliberations and that some of these
people were on dialups in hotel rooms. As I heard no complaints, and as the
committee deliberations were completed, I think it worked. But this was a
very skinny app that I wrote for this purpose only. Which gets to another
nice point about ADPs, they can be very small, less than a meg. This helps
(me at least) in that I can give bits and pieces to people in the
organization who have limited needs or permissions. They never see, or even
know about the main application. And their SPs, Views etc can be specifically
enabled for them, while nothing else is.

I find that with a cable modem (one server in Atlanta, another in Palo Alto),
my processing is as quick as with using MSDE situated on my work machine, and
in fact during development time, I have to examine my connection to know
which one I am using.

I've posted before that using CurrentProject.Connection can be many, many
times slower for ADO/VBA stuff than using a new connection based on
CurrentProject.BaseConnectionString. I believe it is because of the nature of
the connection, Access's being optimized to do everything of course, while
the lesser one is more single task intensive.
--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

If your a certified partner or subscribe to the Action Pack, you already
have it.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"DFS" <no****@nospam.com> wrote in message
news:vv************@corp.supernews.com...

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta, and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly.

You do know you can buy a Developer version of SQL Server 2000 for about
$50?

The "school board" application
above is in the process of reverting to using the Board's SQL server over their intranet. This was a planned change and is in place to comply with
their policies, and not for any performance or known security issue.

I have not experienced any major problems with ADPs. There were three
issues which I found puzzling for a brief time:

1. I could not get sub forms to link properly; I can now, but I cannot
explain what I am doing new, or differently (incidentally, I started
linking my own "sub forms" and found this to be simple and powerful);

2. I could not filter the record source for a report at run time; in MS's ADP newsgroup, someone pointed out that a report's Input Parameters could be set to a form control's value, or to a public function, and that solved that problem completely;

3. I found that ADPs seem very sensitive to the proper installation of

MDAC

(specifically ADO). If it's not A-1 they crash, with an error message

which

is not so helpful, and, AFAIK, undocumented. Finding MS's Comcheck utility allowed me to check and verify what the problem was, but this still
troubles me, as I find that IT departments can be lax about these
installations.

Typically my applications have hundreds of stored procedures, and only a
few small VBA modules. Often my VBA provides parameters for SPROCs only. I have learned just how powerful VIEWS can be, and I am especially impressed with updating them; that is one can update a VIEW which is scripted in

some

particular way, and this updates one of the source tables for the VIEW. I also note that one can use a VIEW as the source for a SPROC, combining the filtering of the one, with the immediacy of the other.

Although I don't use much VBA, in the school board application I have a
time tabling segment. As it looks at many possible solutions (factorials

in

some cases) it is very code intensive, and for this I use VBA, preferring not to have so much drain on the Server CPU (SPROC solution), when I can
distribute that drain among many client machines (VBA solution). For the
time tabling, I use batch updates. To date, these many thousands of

updates

have not resulted in any problems or errors. The VBA solution and the

SPROC

solution take about the same time to do the same thing. BTW, do you know
that one can largely duplicate one's VBA code in SPROCS because one has
IFS, CASE and LOOPS available, variables, and UDFs there?

I could not advise anyone else about whether or not to use MDBs, or ADPs. I've never used ODBC. I am by nature a problem solver, and quite

compulsive

about code. I prefer a platform that does less for me, rather than one

that

does more. I develop in ADPs and not in MDBs, and probably would not take on an MDB job, even if it were quite lucrative. I think that ADPs are very much advanced over MDBs in both concept and realization.

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems his clients are happy.

I have been working with databases since the time of DBaseIII, about 1983 (I think). I have progressed through FoxBase, FoxPro, Clipper and ...
Access. Clipper is likely to remain for me the most useful p-coding
language with which I have ever dealt, but I do like ADPs.

I am sorry if you feel that I should have attached this to one of the
current threads on this subject. I feel that I could not have done so
without contradicting what others have said, or confronting them. And I
simply wish to state my views, based on my experience. It is that ADPs are great.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

> I write this to point out that at least one developer, (me), is both

committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems
his clients are happy.
Lyle, that is a great way to put it, but... I would have though you could
say that (at least) 1 other developer shares in your good experiences.

The largest ADP I have done (and even still continue to build on) has billed
out at over 100k so far, talks seamlessly to and from Accounting databases
using Views, completely useable as a local project over broadband (which is
necessary for local features like automating pcAnywhere and a local modem),
and so on... no corruption and no problems. I too have not found anything I
could not do. There is no software they could have purchased that could do
anything close to what this stuff does for the money they have spent.

I would like to hear more about your complex time table solution.

For Sql Server... it's like I said in my earlier posting, working with ADP's
makes you a better Sql Server programmer. I have as many as 390 sprocs in a
single project and I am very fond of every one of them.

One thing that does bother me about Access in venereal is the amount of
memory it consumes. I destroy all non bound recordsets the moment I no
longer need them or when the form closes and you just can't seem to keep
memory down. I have noticed this on both mdb's and adp's. I have users
that never close the adp and after a couple of weeks the memory usage is no
more than it was after one hour of working (40-50mb), however it takes
forever for Access to come alive on XP after the unit rests for an hour.
The hard drive smokes for about 30 seconds as if it unloaded everything
Access had in ram. This drives some users nuts.

Actually, I think it was I who initially showed you about Input
Parameters... glad to see you found that valuable, I was exited to discover
that myself.
http://groups.google.com/groups?q=ly...igy.com&rnum=1

Good luck sir!

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4... I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta,
and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the
internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly. The "school board" application
above is in the process of reverting to using the Board's SQL server over
their intranet. This was a planned change and is in place to comply with
their policies, and not for any performance or known security issue.

I have not experienced any major problems with ADPs. There were three
issues which I found puzzling for a brief time:

1. I could not get sub forms to link properly; I can now, but I cannot
explain what I am doing new, or differently (incidentally, I started
linking my own "sub forms" and found this to be simple and powerful);

2. I could not filter the record source for a report at run time; in MS's
ADP newsgroup, someone pointed out that a report's Input Parameters could
be set to a form control's value, or to a public function, and that solved
that problem completely;

3. I found that ADPs seem very sensitive to the proper installation of MDAC (specifically ADO). If it's not A-1 they crash, with an error message which is not so helpful, and, AFAIK, undocumented. Finding MS's Comcheck utility
allowed me to check and verify what the problem was, but this still
troubles me, as I find that IT departments can be lax about these
installations.

Typically my applications have hundreds of stored procedures, and only a
few small VBA modules. Often my VBA provides parameters for SPROCs only. I
have learned just how powerful VIEWS can be, and I am especially impressed
with updating them; that is one can update a VIEW which is scripted in some particular way, and this updates one of the source tables for the VIEW. I
also note that one can use a VIEW as the source for a SPROC, combining the
filtering of the one, with the immediacy of the other.

Although I don't use much VBA, in the school board application I have a
time tabling segment. As it looks at many possible solutions (factorials in some cases) it is very code intensive, and for this I use VBA, preferring
not to have so much drain on the Server CPU (SPROC solution), when I can
distribute that drain among many client machines (VBA solution). For the
time tabling, I use batch updates. To date, these many thousands of updates have not resulted in any problems or errors. The VBA solution and the SPROC solution take about the same time to do the same thing. BTW, do you know
that one can largely duplicate one's VBA code in SPROCS because one has
IFS, CASE and LOOPS available, variables, and UDFs there?

I could not advise anyone else about whether or not to use MDBs, or ADPs.
I've never used ODBC. I am by nature a problem solver, and quite compulsive about code. I prefer a platform that does less for me, rather than one that does more. I develop in ADPs and not in MDBs, and probably would not take
on an MDB job, even if it were quite lucrative. I think that ADPs are very
much advanced over MDBs in both concept and realization.

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems
his clients are happy.

I have been working with databases since the time of DBaseIII, about 1983
(I think). I have progressed through FoxBase, FoxPro, Clipper and ...
Access. Clipper is likely to remain for me the most useful p-coding
language with which I have ever dealt, but I do like ADPs.

I am sorry if you feel that I should have attached this to one of the
current threads on this subject. I feel that I could not have done so
without contradicting what others have said, or confronting them. And I
simply wish to state my views, based on my experience. It is that ADPs are
great.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

> I've posted before that using CurrentProject.Connection can be many, many

times slower for ADO/VBA stuff than using a new connection based on
CurrentProject.BaseConnectionString. I believe it is because of the nature of the connection, Access's being optimized to do everything of course, while
the lesser one is more single task intensive.
Really? I never gave that a second thought! Good point...

In looking at the two, I can see that using the base string works directly
with the SQLOLEDB provider while the other works with the MSDataShape
provider. Interesting.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4... "(Pete Cresswell)" <x@y.z> wrote in
news:3o********************************@4ax.com:

RE/

There were three
issues
I dabbled in the Access 2000 version, but didn't feel comfortable enough
to try it on my new project at the time - especially after reading a
passage in an MS Access 2000 "How-To" book that said the 2000 version
was "almost ready for prime time".

I'd still like to try it - especially after hearing that you've got apps
that work over an internet connection. I'm squashing the final bugs in
a project control app that the client swore was just for his and a
couple of other local divisions - and now they're taking it national
(Philadelphia is the client's location and Chicago is their parent org)
over the corporate WAN. Works OK, but I'm dreading the day somebody
wants to use it from home over dialup.

Have you figured out a way to pre-populate combo boxes? - i.e. load them
up before a form opens so the user does not have to wait for a large
list to load. Currently I resort to having AutoExec load JET cache
tables in a work DB in C:\TEMP.

Also, do you implement disconnected edits? - i.e. user clicks an "Edit"
button, the form's controls become editable, but nothing goes into the
DB until the user clicks "Save"....and clicking "Cancel" repopulates the
form as it was before the user clicked "Edit"...?

Yes ... a lot. I also write HTA applications, and with them, this is the
only way, with Reset returning the form to its original state.

I've never experienced any difficulty with waits for combo boxes to

populate. But then when a combo box list's count is likely to be more than a few dozen, I will probably program this as an external popup form.

I have not used dialup connections extensively with ADPs, and would recommend something quicker. But I do know that with one small app I wrote, various
people were using the app simultaneously across the USA, as a pseudo
"whiteboard" for committee meetings and deliberations and that some of these people were on dialups in hotel rooms. As I heard no complaints, and as the committee deliberations were completed, I think it worked. But this was a
very skinny app that I wrote for this purpose only. Which gets to another
nice point about ADPs, they can be very small, less than a meg. This helps
(me at least) in that I can give bits and pieces to people in the
organization who have limited needs or permissions. They never see, or even know about the main application. And their SPs, Views etc can be specifically enabled for them, while nothing else is.

I find that with a cable modem (one server in Atlanta, another in Palo Alto), my processing is as quick as with using MSDE situated on my work machine, and in fact during development time, I have to examine my connection to know
which one I am using.

I've posted before that using CurrentProject.Connection can be many, many
times slower for ADO/VBA stuff than using a new connection based on
CurrentProject.BaseConnectionString. I believe it is because of the nature of the connection, Access's being optimized to do everything of course, while
the lesser one is more single task intensive.
--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Lyle Fairfield]

"Jerry Boone" <je***@antech.biz.killspam> wrote in
news:WA*****************@newssvr22.news.prodigy.co m:

Actually, I think it was I who initially showed you about Input
Parameters... glad to see you found that valuable, I was exited to
discover that myself.
http://groups.google.com/groups?q=ly...rameters+group
:comp.databases.ms-access&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.database
s.ms-access&selm=jQz4a.644%24zu4.270459998%40newssvr11. news.prodigy.com&r
num=1

It seems you are correct; it was you. And here I thought it was a beautiful
woman who had shown me that ... oh well, as I age I tend to hallucinate as
much as when I was younger.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Lyle Fairfield]

"Jerry Boone" <je***@antech.biz.killspam> wrote in
news:WA*****************@newssvr22.news.prodigy.co m:

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it
seems his clients are happy.

Lyle, that is a great way to put it, but... I would have though you
could say that (at least) 1 other developer shares in your good
experiences.

I was hoping that several would say, as you are saying, "Me too!".

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

Yeah... it's kind of a "leap of faith" thing... isn't it? Oh, and sorry I
didn't turn out to be a hot chick... I admit that would be disappointing!
Oh well...

I guess "if it were easy, everyone would do it" and we would be talking
about more advanced things like new ways to use Input Parameters, updateable
views and stuff...

Odds are that there are many others who would say "Me Too!" if they were not
put on the spot for the direction in which they believe in. Like John
Winterbottom -- he is heavy into adp's since early 2001 and released some
laboratory (lims) applications. The company he works or worked for is
http://www.assaynet.com and there is a neat slide show on the finished
project.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

"Jerry Boone" <je***@antech.biz.killspam> wrote in
news:WA*****************@newssvr22.news.prodigy.co m:

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it
seems his clients are happy.

Lyle, that is a great way to put it, but... I would have though you
could say that (at least) 1 other developer shares in your good
experiences.

I was hoping that several would say, as you are saying, "Me too!".

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Lyle Fairfield]

Lyle Fairfield <Mi************@Invalid.Com> wrote in
news:Xn*******************@130.133.1.4:

"Jerry Boone" <je***@antech.biz.killspam> wrote in
news:WA*****************@newssvr22.news.prodigy.co m:

Actually, I think it was I who initially showed you about Input
Parameters... glad to see you found that valuable, I was exited to
discover that myself.
http://groups.google.com/groups?q=ly...arameters+grou
p
:comp.databases.ms-access&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.databas
:e
s.ms-access&selm=jQz4a.644%24zu4.270459998%40newssvr11. news.prodigy.com&
r num=1

It seems you are correct; it was you. And here I thought it was a
beautiful woman who had shown me that ... oh well, as I age I tend to
hallucinate as much as when I was younger.

Upon further review ... the play as called on the field is ... well ...
modified at least.

I used to think that for a SPROC with input parameters

@DebitAccountID int=0,
@CreditAccountID int=0,
@MethodID int=0

one could assign the input parameters as one string (returned from ONE
function:

@DebitAccountID int=4,@CreditAccountID int=4,@MethodID int=4

but I was wrong.

What is required for 3 parameters is 3 functions and Input Parameters
Property to be assigned as:

@DebitAccountID int=GetDebitAccountID(),@CreditAccountID
int=GetCreditAccountID(),@MethodID int=GetMethodID()

with public functions available as:

Public Function GetDebitAccountID() As Long
GetDebitAccountID = 4
End Function

Public Function GetCreditAccountID() As Long
GetCreditAccountID = 4
End Function

Public Function GetMethodID() As Long
GetMthodID = 4
End Function

STOP me if this is not as you understand it.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

Yes, you should stay with the functions. It's the only way I have ever been
able to get Access to do the things I needed in these cases, at least since
A97... as far as I know or remember.

Using Forms!Field!Value (or whatever it is) seems to work also, but you
can't pre-validate questionable info that way.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

Lyle Fairfield <Mi************@Invalid.Com> wrote in
news:Xn*******************@130.133.1.4:

"Jerry Boone" <je***@antech.biz.killspam> wrote in
news:WA*****************@newssvr22.news.prodigy.co m:

Actually, I think it was I who initially showed you about Input
Parameters... glad to see you found that valuable, I was exited to
discover that myself.
http://groups.google.com/groups?q=ly...arameters+grou p
:comp.databases.ms-access&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.databas :e
s.ms-access&selm=jQz4a.644%24zu4.270459998%40newssvr11. news.prodigy.com& r num=1

It seems you are correct; it was you. And here I thought it was a
beautiful woman who had shown me that ... oh well, as I age I tend to
hallucinate as much as when I was younger.

Upon further review ... the play as called on the field is ... well ...
modified at least.

I used to think that for a SPROC with input parameters

@DebitAccountID int=0,
@CreditAccountID int=0,
@MethodID int=0

one could assign the input parameters as one string (returned from ONE
function:

@DebitAccountID int=4,@CreditAccountID int=4,@MethodID int=4

but I was wrong.

What is required for 3 parameters is 3 functions and Input Parameters
Property to be assigned as:

@DebitAccountID int=GetDebitAccountID(),@CreditAccountID
int=GetCreditAccountID(),@MethodID int=GetMethodID()

with public functions available as:

Public Function GetDebitAccountID() As Long
GetDebitAccountID = 4
End Function

Public Function GetCreditAccountID() As Long
GetCreditAccountID = 4
End Function

Public Function GetMethodID() As Long
GetMthodID = 4
End Function

STOP me if this is not as you understand it.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Still Using A97]

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

I have developed ADPs now for three years, in Ac2K and AcXP. I have sold
two ADP applications for > $30,000 USD, one to a large company in Atlanta,
and one to a local (Ontario, Canada) school board, and numerous smaller
ones.

Initially my applications have started as accessing MS-SQL Server over the
internet. For development purposes I use MSDE, or rent an SQL Server DB
from my site provider for $15 USD monthly. The "school board" application
above is in the process of reverting to using the Board's SQL server over
their intranet. This was a planned change and is in place to comply with
their policies, and not for any performance or known security issue.

I have not experienced any major problems with ADPs. There were three
issues which I found puzzling for a brief time:

1. I could not get sub forms to link properly; I can now, but I cannot
explain what I am doing new, or differently (incidentally, I started
linking my own "sub forms" and found this to be simple and powerful);

2. I could not filter the record source for a report at run time; in MS's
ADP newsgroup, someone pointed out that a report's Input Parameters could
be set to a form control's value, or to a public function, and that solved
that problem completely;

3. I found that ADPs seem very sensitive to the proper installation of MDAC (specifically ADO). If it's not A-1 they crash, with an error message which is not so helpful, and, AFAIK, undocumented. Finding MS's Comcheck utility
allowed me to check and verify what the problem was, but this still
troubles me, as I find that IT departments can be lax about these
installations.

Typically my applications have hundreds of stored procedures, and only a
few small VBA modules. Often my VBA provides parameters for SPROCs only. I
have learned just how powerful VIEWS can be, and I am especially impressed
with updating them; that is one can update a VIEW which is scripted in some particular way, and this updates one of the source tables for the VIEW. I
also note that one can use a VIEW as the source for a SPROC, combining the
filtering of the one, with the immediacy of the other.

Although I don't use much VBA, in the school board application I have a
time tabling segment. As it looks at many possible solutions (factorials in some cases) it is very code intensive, and for this I use VBA, preferring
not to have so much drain on the Server CPU (SPROC solution), when I can
distribute that drain among many client machines (VBA solution). For the
time tabling, I use batch updates. To date, these many thousands of updates have not resulted in any problems or errors. The VBA solution and the SPROC solution take about the same time to do the same thing. BTW, do you know
that one can largely duplicate one's VBA code in SPROCS because one has
IFS, CASE and LOOPS available, variables, and UDFs there?

I could not advise anyone else about whether or not to use MDBs, or ADPs.
I've never used ODBC. I am by nature a problem solver, and quite compulsive about code. I prefer a platform that does less for me, rather than one that does more. I develop in ADPs and not in MDBs, and probably would not take
on an MDB job, even if it were quite lucrative. I think that ADPs are very
much advanced over MDBs in both concept and realization.

I write this to point out that at least one developer, (me), is both
committed to, and successful with ADPs, and has found no unsolvable
problems in working with them. He has sold ADP applications, and it seems
his clients are happy.

I have been working with databases since the time of DBaseIII, about 1983
(I think). I have progressed through FoxBase, FoxPro, Clipper and ...
Access. Clipper is likely to remain for me the most useful p-coding
language with which I have ever dealt, but I do like ADPs.

I am sorry if you feel that I should have attached this to one of the
current threads on this subject. I feel that I could not have done so
without contradicting what others have said, or confronting them. And I
simply wish to state my views, based on my experience. It is that ADPs are
great.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

Very interesting. But what is an ADP?

[(Pete Cresswell)]

RE/

Yes ... a lot. I also write HTA applications, and with them, this is the
only way, with Reset returning the form to its original state.

How do you do it? ADO disconnected recordset?
--
PeteCresswell

[(Pete Cresswell)]

RE/

But what is an ADP?

Access Data Project.

A different type of MS Access application that doesn't do DAO...instead it's
designed to do everything against a "real" client/server DB.
--
PeteCresswell

[Lyle Fairfield]

"(Pete Cresswell)" <x@y.z> wrote in news:5fduvvgqkv4q3bm184tr3uffllg8jo7to9
@4ax.com:

RE/

Yes ... a lot. I also write HTA applications, and with them, this is the
only way, with Reset returning the form to its original state.

How do you do it? ADO disconnected recordset?

Disconnecting ADO recordsets in HTA-HTMAL JScript can be a bit challening.
What is VBA's "nothing" in JScript? A look at my variable declaration will
give a clue as to how I do this:
var c=new ActiveXObject('ADODB.Connection');
var m=new ActiveXObject('ADODB.Command');
var e=new ActiveXObject('ADODB.Error');
var r=new ActiveXObject('ADODB.Recordset');
var acNothing=r.ActiveConnection;

After I get the recordset I want, I set its connection back to !whatever!
it was before I set a connection for it. This seems to effect a
disconnection.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Larry Linson]

Pete -- why do you bother to respond to this person who hides behind the
semi-anonymizing news server, teranews, known to be used by Don P Mellon?

[(Pete Cresswell)]

RE/

Pete -- why do you bother to respond to this person who hides behind the
semi-anonymizing news server, teranews, known to be used by Don P Mellon?

Same reason I'm never bothered by political infighting at the client sites I
serve: I'm just not that perceptive - all that stuff just flys right over my
head. I'll walk out of a meeting and some guy will say "Did you see *that*?
Man, did you hear that zinger..." and so-forth.... Nope..all I was thinking
about was "What do these guys want?".....

Being a little dense *does* have it's advantages sometimes...maybe not here and
now...but sometimes.
--
PeteCresswell