Ambitious report idea......... "Favorites"

Greetings

This is rather ambitious:

I have a split database that contains many different reports. I have a
form that the end user launches the reports from. They select the
report criteria from several combo boxes, click a "Go" command button
to launch the report. I then pass the report criteria to various
report "templates" as an SQL string.

I would like to have a section of the report form, or a new form, have
command buttons for the end user to store their most commonly used
combinations of reports/criteria. They would select their criteria,
then press an "Add to Favorites" button, be prompted for a "favorites
name", then click OK. The end result would create a new command
button,(or make an existing one visible), then change a label to their
chosen "Favorites" name. Obviously, their criteria would need to be
stored, also.

I am flexible on how I accomplish this. I am just looking for some
basic outlines on how this might be done. I started an attempt at this
with a command button that had a complex IIf behind it, looking at the
machine name, but it quickly got too confusing!

Has anyone here ever done something similar to this? Or, am I outside
the realm of Access?

I am not a "power programmer", but I can usually muddle my through
relatively complex stuff. Also, I would prefer not to involve Access
security in this, but if necessary.........

Any ideas would be appreciated.

Thanks in advance,

Dennis

re: Ambitious report idea......... "Favorites"

"Dennis Ruppert" <druppert@ruppertweb.com> wrote in message
news:f7160683.0407100641.78c45f@posting.google.com ...[color=blue]
> Greetings
>
> This is rather ambitious:
>
> I have a split database that contains many different reports. I have a
> form that the end user launches the reports from. They select the
> report criteria from several combo boxes, click a "Go" command button
> to launch the report. I then pass the report criteria to various
> report "templates" as an SQL string.
>
> I would like to have a section of the report form, or a new form, have
> command buttons for the end user to store their most commonly used
> combinations of reports/criteria. They would select their criteria,
> then press an "Add to Favorites" button, be prompted for a "favorites
> name", then click OK. The end result would create a new command
> button,(or make an existing one visible), then change a label to their
> chosen "Favorites" name. Obviously, their criteria would need to be
> stored, also.
>
> I am flexible on how I accomplish this. I am just looking for some
> basic outlines on how this might be done. I started an attempt at this
> with a command button that had a complex IIf behind it, looking at the
> machine name, but it quickly got too confusing!
>
> Has anyone here ever done something similar to this? Or, am I outside
> the realm of Access?
>
> I am not a "power programmer", but I can usually muddle my through
> relatively complex stuff. Also, I would prefer not to involve Access
> security in this, but if necessary.........[/color]

I'm not sure I understand what the stumbiling block is. You obviously
already know how to open a report after building a query from selected
criteria. You will already have the recordsource string built when the user
wants to save it. All that remains is to store the report name and the
recordsource string in a local table instead of the backend.

re: Ambitious report idea......... "Favorites"

druppert@ruppertweb.com (Dennis Ruppert) wrote in message news:<f7160683.0407100641.78c45f@posting.google.co m>...[color=blue]
> Greetings
>
> This is rather ambitious:
>
> I have a split database that contains many different reports. I have a
> form that the end user launches the reports from. They select the
> report criteria from several combo boxes, click a "Go" command button
> to launch the report. I then pass the report criteria to various
> report "templates" as an SQL string.
>
> I would like to have a section of the report form, or a new form, have
> command buttons for the end user to store their most commonly used
> combinations of reports/criteria. They would select their criteria,
> then press an "Add to Favorites" button, be prompted for a "favorites
> name", then click OK. The end result would create a new command
> button,(or make an existing one visible), then change a label to their
> chosen "Favorites" name. Obviously, their criteria would need to be
> stored, also.
>
> I am flexible on how I accomplish this. I am just looking for some
> basic outlines on how this might be done. I started an attempt at this
> with a command button that had a complex IIf behind it, looking at the
> machine name, but it quickly got too confusing!
>
> Has anyone here ever done something similar to this? Or, am I outside
> the realm of Access?
>
> I am not a "power programmer", but I can usually muddle my through
> relatively complex stuff. Also, I would prefer not to involve Access
> security in this, but if necessary.........
>
> Any ideas would be appreciated.
>
> Thanks in advance,
>
> Dennis[/color]


Rather than a command button I would use a list box.
That way you don't have to guess how many buttons might be needed (to
either hide them, or allow for the space on screen)

By using a list box you could store the SQL string in a 3 field table.
(IDNum(Primary Key), FavoriteName, SqlText)
Then display the FavoriteName in the list box, but use the sqlText
column (hidden) in the GO command procedure.

You will need to explore storing and handling "" marks, but I'm
guessing that you probably have already tackled that as you gather
this info and pass it on in your current method.

I have used this approach to have a "GO" button that opens reports, or
forms as selected from a list box. I have another column that defines
the TYPE form, report etc. that I then test for and do either a
docmd.openform.... or openreport....


HTH
Mal.

re: Ambitious report idea......... "Favorites"

rkc

Well...........I guess I was just looking for a "concept", thinking
someone else may have done something similar. The front end is under
almost constant development, so I have to find a way to let individual
users store their most common reports without re-doing it when the front
end is replaced. perhaps storing the report name and string on their own
table in the backend.

I am unsure how to manipulate the form components of this idea. In other
words, labeling a button as "My Yield Report" for user Joe Blow, only
visible to that user. Seperate forms for each user? A common form with
some IIf stuff behind it?

Obviously, this is just in the conceptual stage right now. I will
continue pondering until I come up with something. I just thought
someone out there might see this , and say "Hey! I did this once!"

Thanks for your reply.

Dennis


*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

re: Ambitious report idea......... "Favorites"

HTH

I like that idea. Then I could just filter the list so "My Yield
Report", or whatever, is visible to the appropriate operator.

I suppose I could prompt them when they save their "favorite" for a
FavoriteName, then capture their user ID and save that to the same table
to use in the filtering.


Anyway, thanks for the idea!

Dennis

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

re: Ambitious report idea......... "Favorites"

HTH

I like that idea. Then I could just filter the list so "My Yield
Report", or whatever, is visible to the appropriate operator.

I suppose I could prompt them when they save their "favorite" for a
FavoriteName, then capture their user ID and save that to the same table
to use in the filtering.


Anyway, thanks for the idea!

Dennis

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

re: Ambitious report idea......... "Favorites"

Dennis Ruppert <druppert@ruppertweb.com> wrote in message news:<40f04e84$0$16466$c397aba@news.newsgroups.ws> ...[color=blue]
> HTH
>
> I like that idea. Then I could just filter the list so "My Yield
> Report", or whatever, is visible to the appropriate operator.
>
> I suppose I could prompt them when they save their "favorite" for a
> FavoriteName, then capture their user ID and save that to the same table
> to use in the filtering.
>
>
> Anyway, thanks for the idea!
>
> Dennis
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it![/color]

Hey! I did this once. :-)

Instead of saving the entire SQL string, it may be advantageous to
store the values that were placed in the various criteria
boxes/checkboxes. When the user selects the predefined name from a
combobox, you fill in the values selected previously and let the form
create the SQL string again based on the predefined values or on
modified ones. If you want users to have their own individual list of
custom selections, you could put the table in a local database such
as: C:\Databases\Custom.mdb and the link will find each user's custom
definitions. When the front end gets replaced it won't wipe out the
custom table.

James A. Fortune

re: Ambitious report idea......... "Favorites"

Dennis,
Methinks I'd build my own switchboard and keep a table tracking user, object
name, and a count of how many times an object has been accessed by that
user. Then favorites would be the objects that get used the most. You
could select for the top n objects and order by usage count in descending
order so the most frequently used show up first. I'd probably give the user
a combo box that let them sort by frequency of use or object name similar to
what you see on shopping web sites.

"Dennis Ruppert" <druppert@ruppertweb.com> wrote in message
news:f7160683.0407100641.78c45f@posting.google.com ...[color=blue]
> Greetings
>
> This is rather ambitious:
>
> I have a split database that contains many different reports. I have a
> form that the end user launches the reports from. They select the
> report criteria from several combo boxes, click a "Go" command button
> to launch the report. I then pass the report criteria to various
> report "templates" as an SQL string.
>
> I would like to have a section of the report form, or a new form, have
> command buttons for the end user to store their most commonly used
> combinations of reports/criteria. They would select their criteria,
> then press an "Add to Favorites" button, be prompted for a "favorites
> name", then click OK. The end result would create a new command
> button,(or make an existing one visible), then change a label to their
> chosen "Favorites" name. Obviously, their criteria would need to be
> stored, also.
>
> I am flexible on how I accomplish this. I am just looking for some
> basic outlines on how this might be done. I started an attempt at this
> with a command button that had a complex IIf behind it, looking at the
> machine name, but it quickly got too confusing!
>
> Has anyone here ever done something similar to this? Or, am I outside
> the realm of Access?
>
> I am not a "power programmer", but I can usually muddle my through
> relatively complex stuff. Also, I would prefer not to involve Access
> security in this, but if necessary.........
>
> Any ideas would be appreciated.
>
> Thanks in advance,
>
> Dennis[/color]

re: Ambitious report idea......... "Favorites"

James

I knew someone had to have done this!

I like your idea, it should be much easier than storing and passing the
actual strings themselves.

About the Custom.mdb; In the "old days", programs used .ini files to
store stuff. It seems I remember mentions of this with Access apps, but
I haven't really investigated this any further. My app has other per
user parameters that I currently handle with IIf and Case statements. It
is getting to be a little high maintenance.

Is an.ini a practical solution, or is a seperate .mdb the best solution.
Am I correct in assuming that either method will be easy to "package",
(I use MOD XP)?

Also, I have tried to stay away from making this app dependant on Access
Security, for any of it's functionality, as eventually it may be
distributed to customers, on non-networked PCs. Am I losing out on some
"workgroup file" related options for customizations per user, as I am
trying to do here?

Thanks,

Dennis


*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

re: Ambitious report idea......... "Favorites"

Dennis Ruppert <druppert@ruppertweb.com> wrote in message news:<40f27ea2$0$16462$c397aba@news.newsgroups.ws> ...[color=blue]
> James
>
> I knew someone had to have done this!
>
> I like your idea, it should be much easier than storing and passing the
> actual strings themselves.
>
> About the Custom.mdb; In the "old days", programs used .ini files to
> store stuff. It seems I remember mentions of this with Access apps, but
> I haven't really investigated this any further. My app has other per
> user parameters that I currently handle with IIf and Case statements. It
> is getting to be a little high maintenance.
>
> Is an.ini a practical solution, or is a seperate .mdb the best solution.
> Am I correct in assuming that either method will be easy to "package",
> (I use MOD XP)?
>
> Also, I have tried to stay away from making this app dependant on Access
> Security, for any of it's functionality, as eventually it may be
> distributed to customers, on non-networked PCs. Am I losing out on some
> "workgroup file" related options for customizations per user, as I am
> trying to do here?
>
> Thanks,
>
> Dennis[/color]

Although using a .ini file sounds a little backward I have never tried
it with Access and don't know how well it would work. A local .mdb
isn't all that great of an idea either. It was just a quick and dirty
way to do it. I didn't spend much time devising the best way to do
it. For most situations, using a single table linked to a shared BE
and filtering by the user should be O.K. I can easily see how other
kinds of user specific information could get to be high maintenance.
You can use an API call to get their network login name so you aren't
dependent on having Access Security. Instead of linking to a local
..mdb you could run code that exports the local tables to the local
..mdb. Then when you have replaced the FE you run some more code that
gets the local table data back. I dunno.

James A. Fortune