Queries VS VBA Design

Hi David,
Picture this, A clipper programmer is told he has to develop the
new version of the inhouse software in Access. At this point I did not know
about the news groups and I could not find anyone who had develop software in
access. So I winged it! Grant you I split up the Tables (databases) more
than I needed too.

However, The program was relativily fast, easy to read, easy to
maintain. When we updated the software last year the company we hired
(Pinnicle) got a copy of the software and they were impressed. they really
did not think such a large program could be done in access.

Looking at it now I would do things differently. I wonder how
fast, easy to read, easy to maintain it would be?

How about you David, every look backup and wonder what you were thinking
when you wrote program "X"?

Scott Burke



"David W. Fenton" wrote:

=?Utf-8?B?U2NvdHQgQnVya2U=?=
wrote in :

"David W. Fenton" wrote:

=?Utf-8?B?U2NvdHQgQnVya2U=?=
wrote in
:

I develeoped a system here where there are 73 backends and 30
front ends. I use both VBA and Queries. It has been running
extreamly well for 9 years now.
Its all in the design.

You are insane.

It was fun and I learned a lot.
I will NOT do that again!

I can't understand why there could ever be any justification
whatseover for multiple back ends to any front end -- it sounds like
the data has been split up incorrectly to me.

I hear that SQL is eayier.

For what? What do you use to develop the front end?


--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

=?Utf-8?B?U2NvdHQgQnVya2U=?=
wrote in :

How about you David, every look backup and wonder what you were
thinking when you wrote program "X"?

Yes, of course. Just this week I've had my nose rubbed in two apps I
wrote back in 1997, and one that dates from before that. Ugly, ugly,
ugly. And incredily hard to maintain because of that ugliness.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

We maintain the Retail Banking module separate from the Fixed
Interest module. They both lock into the same framework, and
have a shared library. There wouldn't be any particular advantage
to putting the instruments into a shared table, and there would
certainly be no advantage to putting the two tables into the same file.

If they use an ODBC back-end, they are required to put both
tables on the same server, because Access can't handle multiple
ODBC servers, but we don't let that entirely dictate our design.

(david)

"David W. Fenton" wrote in message
36.90...
=?Utf-8?B?U2NvdHQgQnVya2U=?=
wrote in :

"David W. Fenton" wrote:

=?Utf-8?B?U2NvdHQgQnVya2U=?=
wrote in
:

I develeoped a system here where there are 73 backends and 30
front ends. I use both VBA and Queries. It has been running
extreamly well for 9 years now.
Its all in the design.

You are insane.

It was fun and I learned a lot.
I will NOT do that again!

I can't understand why there could ever be any justification
whatseover for multiple back ends to any front end -- it sounds like
the data has been split up incorrectly to me.

I hear that SQL is eayier.

For what? What do you use to develop the front end?


--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/