Albert
I missed a typo in my request with acct # 201|. It should have been 201.
Ok..that helps. The problem here is that you still not asked a question in
the context of how you plan to group the data
The acct #s can be grouped however I know how
Ok, does mean you want to supply the list of accounts here?
to maintenance and chose to take on the responsibility of instituting
change
myself. I am from a technology prior to PC's in which one could add a
sub-total to a report rather easily.
I too have worked on a ton of mainframe systems. Going back to Sperry
mapper, Prime information, Microdata (MacDonald Douglas), Honeywell systems,
IBM's "Universe" systems (U2), and of course Pick. And, in fact a good deal
more systems then I can remember. I can't say any of those systems were even
in the same league, and remotely close to the report writer that I got in
ms-access. And, I used a ton of pc based systems from Advanced Revelation,
FoxPro/dbaseII, Knowledge man, 4th dimension (mac), and again a ton more
that I can't even remember...
Creating sub-totals in ms-access is breeze, and even more incredible is that
you don't even have to write any code....
ms-access is BETTER then any of the systems I have EVER used....
The problem here is not that some old mainframe system did this in a easier
fashion (which I doubt by the way). The problem here is lack of definition
of the problem.
Do you want to "prompt" the user for the accounts grouping? So, each time,
the user has to "enter" a bunch of accounts?
Or, do you need/plan to pre-define the grouping in some "setup" form?
Or, do you as the developer want to define this in the actual report (bad
idea).
It does not make sense to "hard code", or write some VB code to total
particular accounts here. This approach means that you have to write code,
or modify the report every you need a new grouping. This approach is just
not workable, and one that is not very maintainable either..
If you don't want to use my accounts+grouping idea, then another approach
would be to supply a list of accounts,and use a sub-report, and that can
generate the total for the accounts you choose.
So, if you need to "prompt" the end users, then we do need to then setup a
form, or some type of user interface that lets the user enter the accounts.
Further, do you want restrict the report to those accounts you choose?
I don't think you need to write code here (and, if you do, it would be
outside of the report to setup the data). I would NOT try to code the
groupings in the report unless you got no other choice, and have exhausted
the above suggestions.
There is a bunch of possibilities here, but you can't use concepts learned
in the old dbaseIII language in ms-access, as they don't work the same. And,
the approaches you used in one old system will not work the same in
ms-access. You have to modify the approach you use to problem solving here,
as the approaches used before change from platform to platform. I used to
record numbers all the time in FoxPro, but now ms-access does NOT have
record numbers. In fact, in ms-access data written to a file and then
retrieved does NOT necessary come back in the same order! (hint: you have to
"set" the order of data now). So, many concepts and ideas that used to make
sense do not anymore.
So, if you define the problem, then approaches can be suggested...not the
other way around....