Report Writer

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have been asked twice in the last week if there is some way to create a
Report Writer with Access so users can query their data and create their own
reports. Has anyone else had this request and, if so, did you come up with
any solutions?
 
I have been asked twice in the last week if there is some way to create a
Report Writer with Access so users can query their data and create their own
reports. Has anyone else had this request and, if so, did you come up with
any solutions?

Access comes with an excellent report designer right out of the box, but
it requires some experience to use it effectively. Also, anyone
creating reports also needs to understand querying techniques and their
own database structure.

If you're looking for easy end-user reporting, an Access developer can
build reports that prompt the user for criteria before they run, and can
even turn sections of the report on or off dynamically. There are lots
of examples on the web for doing this, including
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp. (see
Report Selection Example and Customizable Reports.)
 
Lambi000 said:
I have been asked twice in the last week if there is some way to create a
Report Writer with Access so users can query their data and create their
own
reports. Has anyone else had this request and, if so, did you come up
with
any solutions?

I kind of thought that the above is a description of the report writer and
query builder in ms-access? (did I miss something here?).

If you can design something for your users that allows you to build quires
and relational data joins without any training, then I would suggest you get
right on it, as millions, and perhaps billions will be your reward. (you
will become the next bill gates if you can accomplish this task).

On the other hand, if you talking about how does one handle the need for
prompting the user for critea etc. for a report?

The normal approach is to build a un-bound form (a un-bound form is a form
that is NOT attached to a table - these forms are typicaly desiged for user
interface face stuff like promtps, print buttions etc).

The following screen shots are all un-bound forms, and they simply prompt
the user for informaton.

http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html

The above shold give you some ideas

So, the solution use now is simply to take the values from the form, and
build your own where clause in code. That way, you simply design the reports
(or forms), and attached them to the query. And, NO FORMS conditions are
placed in the query.

To "send" the conditions to the report (or form), you simply use the "where"
clause. This is exactly why ms-access has this feature...and it solves a
zillion problems...and will reduce your development costs by a substantial
amount.

The code to make those above screens work and launch the report with the
selected restrictions when you hit the "print" button is easy:


dim strWhere as string

' select sales rep combo

if isnull(cboSalesRep) = false then

strWhere = "SalesRep = '" & cboSalesRep & "'"

end if

' select what City for the report

if isnull(cboCity) = false then
if strWhere <> "" then
strWhere = strWhere " and "
endif
strWhere = strWhere & "City = '" & cobCity & "'"
end if

Note how the 2nd combo test is setup. You can add as "many" more conditions
you want. Lets say we have a check box to only include Special Customers. We
can add to our very nice prompt screen a check box to

[x] Show Only Special customers

The code we add would be:

if chkSpeicalOnly = True then
if strWhere <> "" then
strWhere = strWhere " and "
endif
strWhere = strWhere & "SpecialCust = true"
endif

For sure, each combo and control we add to the nice report screen takes a
bit of code, but no more messy then the query builder..and this way, each
query is nice and clean, and free of a bunch of HIGHLY un-maintainable
forms! expressions.

Further, it means you can re-use the same query for different reports, and
have no worries about some form that is supposed to be open. So, a tiny bit
more code eliminates the messy query problem.. For me, this is very worth
while trade.

For a date range, we could put two calendar contorls on the screen. The code
could be:


dim strWhere as string
dim strStartDate as string
dim strEndDate as string


strStartDtae = "#" & format(me.StartDateContorl,"mm/dd/yyyy") & "#"
strEndDate = "#" & format(me.EndDateContorl,"mm/dd/yyyy") & "#"

strWhere = "InvoiceDate is between " & strStartDate & " and " & strEndDate

docmd.openReport "InvoiceReport",acViewPreview,,strWhere

So, really, a product sales report can really only be grouped by perhaps
sales report, location, and filtered by perhaps location and sales rep.

Hence, your choice is build a nice screen with some prompts for the report,
or simply assume that users can deal with building queries and reports
themselves.
 
Hmmm, a few billion sounds like something I could use right now. I'll get
right on it.

Thanks for the feedback. I really don't know what the users want and I
seriously doubt they do either. But what they'll get is what you're
suggesting.

Thanks for the ideas!

Albert D. Kallal said:
Lambi000 said:
I have been asked twice in the last week if there is some way to create a
Report Writer with Access so users can query their data and create their
own
reports. Has anyone else had this request and, if so, did you come up
with
any solutions?

I kind of thought that the above is a description of the report writer and
query builder in ms-access? (did I miss something here?).

If you can design something for your users that allows you to build quires
and relational data joins without any training, then I would suggest you get
right on it, as millions, and perhaps billions will be your reward. (you
will become the next bill gates if you can accomplish this task).

On the other hand, if you talking about how does one handle the need for
prompting the user for critea etc. for a report?

The normal approach is to build a un-bound form (a un-bound form is a form
that is NOT attached to a table - these forms are typicaly desiged for user
interface face stuff like promtps, print buttions etc).

The following screen shots are all un-bound forms, and they simply prompt
the user for informaton.

http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html

The above shold give you some ideas

So, the solution use now is simply to take the values from the form, and
build your own where clause in code. That way, you simply design the reports
(or forms), and attached them to the query. And, NO FORMS conditions are
placed in the query.

To "send" the conditions to the report (or form), you simply use the "where"
clause. This is exactly why ms-access has this feature...and it solves a
zillion problems...and will reduce your development costs by a substantial
amount.

The code to make those above screens work and launch the report with the
selected restrictions when you hit the "print" button is easy:


dim strWhere as string

' select sales rep combo

if isnull(cboSalesRep) = false then

strWhere = "SalesRep = '" & cboSalesRep & "'"

end if

' select what City for the report

if isnull(cboCity) = false then
if strWhere <> "" then
strWhere = strWhere " and "
endif
strWhere = strWhere & "City = '" & cobCity & "'"
end if

Note how the 2nd combo test is setup. You can add as "many" more conditions
you want. Lets say we have a check box to only include Special Customers. We
can add to our very nice prompt screen a check box to

[x] Show Only Special customers

The code we add would be:

if chkSpeicalOnly = True then
if strWhere <> "" then
strWhere = strWhere " and "
endif
strWhere = strWhere & "SpecialCust = true"
endif

For sure, each combo and control we add to the nice report screen takes a
bit of code, but no more messy then the query builder..and this way, each
query is nice and clean, and free of a bunch of HIGHLY un-maintainable
forms! expressions.

Further, it means you can re-use the same query for different reports, and
have no worries about some form that is supposed to be open. So, a tiny bit
more code eliminates the messy query problem.. For me, this is very worth
while trade.

For a date range, we could put two calendar contorls on the screen. The code
could be:


dim strWhere as string
dim strStartDate as string
dim strEndDate as string


strStartDtae = "#" & format(me.StartDateContorl,"mm/dd/yyyy") & "#"
strEndDate = "#" & format(me.EndDateContorl,"mm/dd/yyyy") & "#"

strWhere = "InvoiceDate is between " & strStartDate & " and " & strEndDate

docmd.openReport "InvoiceReport",acViewPreview,,strWhere

So, really, a product sales report can really only be grouped by perhaps
sales report, location, and filtered by perhaps location and sales rep.

Hence, your choice is build a nice screen with some prompts for the report,
or simply assume that users can deal with building queries and reports
themselves.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal
 
I really don't know what the users want and I
seriously doubt they do either.

From experience... what they want is software which will take their
vaguely formatted desires and cast them into elegantly formatted,
clear, meaningful printouts, with no mental effort or planning
required on their part.

Good luck. You'll need it. <wry grin>

John W. Vinson[MVP]
 
jwm said:
One tool I've used with good success is DatabaseCreations Report Manager.

http://www.databasecreations.com/prod_rptmgrpro.htm

I have no fiduciary interest in the company, though they are in receipt of
several of my rubles.

Useful for classic VB, C++, etc., and DotNet reporting. I don't think the
OP's users will find it even as easy as Access' own reporting, much less
easier.

Q. Have you really "used it with good success" in an Access application?
(Access _is_ the subject of this newsgroup.) If so, you'll be the first I
know who has/does.

Larry Linson
Microsoft Access MVP
 
Hi Larry;

Obviously, I can only speak for myself, but, yes, I've used it in several of
our applications to allow users to sort their reports based upon their
differing criteria requirements. One thing that I've found useful is the
ability for the user to save a report, or group of reports, for reuse.

Likewise, the built in ability to use dynamic dating saved me a lot of time,
since I don't do this for a living.

A couple of the projects were for non-profits with which my wife has
associations, and they seem to like its capabilities. Likewise, I've used it
for my own company's needs and none of the folks using it have had any
problems, or complaints ( at least expressed to me) with it

I also put together an application using it as the report manager for an
internal requirement for the Ministry of Defense for the Republic of Georgia
and had no complaints. :)

Regards...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top