I asked a question and recieved an answer, tried the answer and it didn't work.
Now I have questions about the answer but can't find my original post.

My question was about 3 buttons on an unbound form that when pressed would
look at the UserName (not CurrentUser), and depending on that name, certain
Users could access only those buttons that they were approved for.

so... here's the response I received:

"I would suggest that instead of having a message pop up when they click a
forbidden button, that you instead hide the button from them. I think users
get annoyed to see an area of an application, and then be told 'you can't go
there'.

In the open event of your unbound form..
Private Sub Form_Open(Cancel As Integer)
Select Case fOSUserName()
Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
Me!PremButn.Visible = True
Me!ProcButn.Visible = False
Me!EnrolButn.Visible = False
Case "jdoe"
Me!PremButn.Visible = False
Me!ProcButn.Visible = True
Me!EnrolButn.Visible = False
End Select
End Sub


THIS IS HOW I ACTUALLY USED IT. BUT IT'S NOT HIDING ANY OF THE BUTTONS ON
OPENING THE FORM.

Private Sub Form_Open(Cancel As Integer)
Select Case fOSUserName()
Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
Me!PremButn.Visible = True
Me!ProcButn.Visible = False
Me!EnrolButn.Visible = False
Case "jdoe"
Me!PremButn.Visible = False
Me!ProcButn.Visible = True
Me!EnrolButn.Visible = False
End Select
End Sub

Thanks for any help!
Connie

Hi Connie,
Put a Debug.Print line in (as below). It sounds to me that the user you are
testing as, is not listed in your Case statements. It's a good idea to
include a Case Else to handle this situation.

Anyway when you open the form, hit Ctrl-G and see what the debug.Print
returns.

"Connie" <(E-Mail Removed)> wrote in message
news:F99F7CDB-BCA6-4807-9DC7-(E-Mail Removed)...
>
> THIS IS HOW I ACTUALLY USED IT. BUT IT'S NOT HIDING ANY OF THE BUTTONS ON
> OPENING THE FORM.
>
> Private Sub Form_Open(Cancel As Integer)

Debug.Print fOSUserName()

> Select Case fOSUserName()
> Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
> Me!PremButn.Visible = True
> Me!ProcButn.Visible = False
> Me!EnrolButn.Visible = False
> Case "jdoe"
> Me!PremButn.Visible = False
> Me!ProcButn.Visible = True
> Me!EnrolButn.Visible = False
> End Select
> End Sub




--
Joan Wild
Microsoft Access MVP

Joan, Thank goodness you found my post! Thanks for the tip.
If you look at the post I posted, you'll see I was using my name crifenburg
.....but look closely... <blush> I spelled my own name wrong!! So OF COURSE
IT WASN'T SHOWING ME THE BUTTONS!

Once I caught it THAT boo-boo, and one other thing I didn't know I needed to
do, such as, turn all the button's visible to "No" (False) to start with,
your suggestion worked just great!!

Solved my problem of the 4 front ends, now I only have one FE with just a
few buttons and my own set of command button menus instead of the wizard
switchboard. This was first for me, and I'm really pleased with the outcome
so far.

I had one more thing that confused me, how to exit the database with using
the Wizard Switchboard Exit application. I made a macro with "Close Form"
and "Quit" and that shuts down the database ok... but is there a better way?

Thanks again for all your help... even though I can't find my original post!

Connie

"Joan Wild" wrote:

> Hi Connie,
> Put a Debug.Print line in (as below). It sounds to me that the user you are
> testing as, is not listed in your Case statements. It's a good idea to
> include a Case Else to handle this situation.
>
> Anyway when you open the form, hit Ctrl-G and see what the debug.Print
> returns.
>
> "Connie" <(E-Mail Removed)> wrote in message
> news:F99F7CDB-BCA6-4807-9DC7-(E-Mail Removed)...
> >
> > THIS IS HOW I ACTUALLY USED IT. BUT IT'S NOT HIDING ANY OF THE BUTTONS ON
> > OPENING THE FORM.
> >
> > Private Sub Form_Open(Cancel As Integer)
>
> Debug.Print fOSUserName()
>
> > Select Case fOSUserName()
> > Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
> > Me!PremButn.Visible = True
> > Me!ProcButn.Visible = False
> > Me!EnrolButn.Visible = False
> > Case "jdoe"
> > Me!PremButn.Visible = False
> > Me!ProcButn.Visible = True
> > Me!EnrolButn.Visible = False
> > End Select
> > End Sub
>
>
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
>
>

"Connie" <(E-Mail Removed)> wrote in message
news:B2087576-D391-4ADA-B4D8-(E-Mail Removed)...
> Joan, Thank goodness you found my post! Thanks for the tip.
> If you look at the post I posted, you'll see I was using my name
> crifenburg
> ....but look closely... <blush> I spelled my own name wrong!! So OF
> COURSE
> IT WASN'T SHOWING ME THE BUTTONS!

That's a good reason to include a Case Else statement to cover off cases
that don't fit.

Case Else
MsgBox "You are not registered...", vbOKOnly
End Select

That would have caught your error.

> I had one more thing that confused me, how to exit the database with using
> the Wizard Switchboard Exit application. I made a macro with "Close Form"
> and "Quit" and that shuts down the database ok... but is there a better
> way?

I assume you have a button on your main menu form to exit the application?
And that is where you are using this macro?

If so, your macro just needs to use the Quit action (close form isn't needed
as that will happen anyway when you quit).


--
Joan Wild
Microsoft Access MVP

I will add the Case Else as you suggested. When I put the vbOKOnly on the
last part of the Case, it created a compile error. I wasn't sure that was
part of the code so I deleted it and it worked ok. Does this have anything
to do with the Library 3.6 compile problems I've had? It took me the longest
time to finally find information regarding checking that library in the tools
area and it fixed the compile problems I was having that I had looked for for
hours and hours.... and hours... and... well, you get the picture.

Re: the Quit. I will take the "close form" out of the macro on the command
button that I'm using now. I have the database compacting on closing, so it
takes a while to close. (or seems to) Any thing I can do to cover that
"pause" . It's not a very clean close.

Thanks for all your help. It has been a learning experience on this database
since I've had to search out code to do things I haven't needed to do on
previous databases. Thank goodness for this Community forum, and all you
that help!!

Connie

"Joan Wild" wrote:

> "Connie" <(E-Mail Removed)> wrote in message
> news:B2087576-D391-4ADA-B4D8-(E-Mail Removed)...
> > Joan, Thank goodness you found my post! Thanks for the tip.
> > If you look at the post I posted, you'll see I was using my name
> > crifenburg
> > ....but look closely... <blush> I spelled my own name wrong!! So OF
> > COURSE
> > IT WASN'T SHOWING ME THE BUTTONS!
>
> That's a good reason to include a Case Else statement to cover off cases
> that don't fit.
>
> Case Else
> MsgBox "You are not registered...", vbOKOnly
> End Select
>
> That would have caught your error.
>
> > I had one more thing that confused me, how to exit the database with using
> > the Wizard Switchboard Exit application. I made a macro with "Close Form"
> > and "Quit" and that shuts down the database ok... but is there a better
> > way?
>
> I assume you have a button on your main menu form to exit the application?
> And that is where you are using this macro?
>
> If so, your macro just needs to use the Quit action (close form isn't needed
> as that will happen anyway when you quit).
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
>
>

Connie wrote:
>
> Re: the Quit. I will take the "close form" out of the macro on the
> command button that I'm using now. I have the database compacting on
> closing, so it takes a while to close. (or seems to) Any thing I
> can do to cover that "pause" . It's not a very clean close.

Is your database split? If so the compact on close will only affect the
frontend. It usually isn't necessary to compact a frontend.

You'll want to compact the backend regularly, however I would just do this
separately.
Backup; compact.

>
> Thanks for all your help. It has been a learning experience on this
> database since I've had to search out code to do things I haven't
> needed to do on previous databases. Thank goodness for this
> Community forum, and all you that help!!

You're welcome!
>

--
Joan Wild
Microsoft Access MVP

> Connie
>
> "Joan Wild" wrote:
>
>> "Connie" <(E-Mail Removed)> wrote in message
>> news:B2087576-D391-4ADA-B4D8-(E-Mail Removed)...
>>> Joan, Thank goodness you found my post! Thanks for the tip.
>>> If you look at the post I posted, you'll see I was using my name
>>> crifenburg
>>> ....but look closely... <blush> I spelled my own name wrong!! So OF
>>> COURSE
>>> IT WASN'T SHOWING ME THE BUTTONS!
>>
>> That's a good reason to include a Case Else statement to cover off
>> cases that don't fit.
>>
>> Case Else
>> MsgBox "You are not registered...", vbOKOnly
>> End Select
>>
>> That would have caught your error.
>>
>>> I had one more thing that confused me, how to exit the database
>>> with using the Wizard Switchboard Exit application. I made a macro
>>> with "Close Form" and "Quit" and that shuts down the database ok...
>>> but is there a better way?
>>
>> I assume you have a button on your main menu form to exit the
>> application? And that is where you are using this macro?
>>
>> If so, your macro just needs to use the Quit action (close form
>> isn't needed as that will happen anyway when you quit).
>>
>>
>> --
>> Joan Wild
>> Microsoft Access MVP

Joan Wild wrote:

(snip)

> It usually isn't necessary to compact a frontend.


The compiled query plans are stored in the frontend. Those all get out
of date, over time, as records are added to the backend tables.
Compacting the frontend decompiles the queries, causing them to be
recompiled (in due course) against the new, backend record counts.

Cheers,
TC

That's why I said usually. But she was using compact on close - I don't
think that is necessary.

--
Joan Wild
Microsoft Access MVP

TC wrote:
> Joan Wild wrote:
>
> (snip)
>
>> It usually isn't necessary to compact a frontend.
>
>
> The compiled query plans are stored in the frontend. Those all get out
> of date, over time, as records are added to the backend tables.
> Compacting the frontend decompiles the queries, causing them to be
> recompiled (in due course) against the new, backend record counts.
>
> Cheers,
> TC

I disagree with "usually". A properly designed, nontrivial, relational
database will always have queries. The queries are in the FE. Therefore
it is always beneficial to compact the FE from time to time, to update
the query plans. But I agree that doing it every time (on close) is
overkill.

TC

> I disagree with "usually". (isn't necessary to compact a frontend)

For the record, I doubt more than 10% of (customers-in-the-wild) I know EVER
compact a Front-end, and they do so only because they are told to for other
reasons. So that makes about 0% plus or minus a few. And I venture to say,
customers being customers ;-), the same proportion (90%) never compact a
Back-end either!

I am not saying this is good policy. But without a speedometer, odometer, and
chronometer, the result of compacting is usually pretty hard to tell vs
performance. (there are other much more major factors like network
performance, PC performance-get a 10% faster PC and forget about FE
compacting<g>).

Hey I'm allowed to support Joan, alright? :-)
Chris