Custom Query/Reporting Form

C

cseifferly

I have been asked to create a form that functions much like the Access simple
query wizard.

Users would like to create their own queries by selecting tables from a
listbox (which I can do) and then selecting the fields they want from another
listbox. I do not know how to do the later. Additionally, does anyone know
a solution to how I could allow them to set up joins and parameters.

I tried suggesting that I create stock queries and they email me with
special requests but that didn't fly.

Thanks in advance for any suggestions you may have.

Crystal
 
M

Marshall Barton

cseifferly said:
I have been asked to create a form that functions much like the Access simple
query wizard.

Users would like to create their own queries by selecting tables from a
listbox (which I can do) and then selecting the fields they want from another
listbox. I do not know how to do the later. Additionally, does anyone know
a solution to how I could allow them to set up joins and parameters.

I tried suggesting that I create stock queries and they email me with
special requests but that didn't fly.


They have got to be kidding! This would be an enormous job,
even for an expert in SQL, DAO and VBA.

If you really must pursue this, the Criteria part of the
problem can be dealt with by using the BuildCriteria
function. You can set a list box's RowSource propert to the
value selected in the tables list box. The table's fields
will by displayed by selecting Field List as the
RowSourceType. I think you are probably pretty much on your
own for doing all the other stuff.

Why not provide them with a playground mdb file with links
to all the tables and then let them use the real query
designer? Of course, you would probably want to implement
full security on the back end tables so they don't
inadvertantly modify the data.
 
A

Albert D. Kallal

It is too difficlt to have users understand relatonal database theory, and
even MORE diffcilt to have users build things like joins etc. If they can't
handle the query builder, then they not going to fair any better if you
build your own query builder.

However, you most certainly can build some prompt forms...

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
 
C

cseifferly

Thank you both for your comments. They have helped me back up my hesitation
to attempt building something like this.

I have opted to give users two options: build a SIMPLE query from ONE table
by chosing tables and fields from listboxes and selecting simple criteria for
those fields.

The other option is a set of stock queries are are most utilized. Any
others can be requested through a request process that is built into the
form. Users request a new query and the system will email me their request.

I did have to explain that I am a VBA programmer . . . not a magician. It's
a mouse and keyboard . . . not a crystal ball and wand.

Thanks again,
Crystal
 
M

Marshall Barton

cseifferly said:
Thank you both for your comments. They have helped me back up my hesitation
to attempt building something like this.

I have opted to give users two options: build a SIMPLE query from ONE table
by chosing tables and fields from listboxes and selecting simple criteria for
those fields.

The other option is a set of stock queries are are most utilized. Any
others can be requested through a request process that is built into the
form. Users request a new query and the system will email me their request.

This is the approach I've used a couple of times. The
search form that Dirk mentioned can be very powerful,
especially when you use the BuildCriteria function (same one
the query design window uses) to parse and construct complex
criteria expressions. Giving that much power to users is a
two edged sword though. As you undoubtably know, it takes
some training to use the query designer's Criteria row
effectively without making a mess of it.

I did have to explain that I am a VBA programmer . . . not a magician. It's
a mouse and keyboard . . . not a crystal ball and wand.

LOL
I'm sure they appreciated that little dose of reality ;-)
 
Top