Access runtime vs. full retail question

[Gregg Hill]

Hello!

I know virtually nothing about Access, and the person who designed my
client's database has vaporized into thin air.

I have a client with an Access 2000 database that has some features locked
out unless one logs into the computer using the "Admin" user name (an actual
name of "Admin" and not to be confused with the Administrator user account).
If they have retail Access 2000 installed on that computer, and the user
logs on as any name except for "admin," the database opens with a restricted
version that does not show some buttons on the front-end GUI that allow
editing paint formulas.

If the computer has the Access 2000 runtime installed, it does not matter
what login name is used, it has the front-end GUI buttons usable. That is a
bozo no-no. Is there any way short of using the retail full Access package
to make the runtime pay attention to security restrictions?

Alternately, are there any low-cost Access replacements that work well?

Thank you!

Gregg Hill

 

[Gregg Hill]

Another thing I just noticed. If using the Access 2000 runtime, the File,
Edit, etc, menu bar is visible when the database is opened. If using full
Access, the menu bar is not there unless one is logged onto the computer
using the "Admin" user name.

Gregg Hill

 

[Albert D. Kallal]

Hello!

If the computer has the Access 2000 runtime installed, it does not matter
what login name is used, it has the front-end GUI buttons usable. That is
a bozo no-no.

That means that security was incorrectly setup, or perhaps the shortcut on
the runtime is actually specify the user name. I would take a close look at
the shortcut generated when using the runtime (if your in fact using one)
.. It sounds like either security
was not setup correctly, or some startup options chooses to display certain
menu items was messed up.

Keep in mind, as a "general" rule, setting security options, or granting
higher
(or lower) security will NOT change the look of a menu, or screen, but
****ONLY**** refuse to allow you to actually use the option. In other words,
security does not "change" the display of options, but would ONLY allow (or
not allow) the use of the option when you ****TRY**** to use it.

If some options do NOT appear based on a particular logon, then that's how
the code is setup, not security. In other words, security does NOT change
if a menu or option will display (Unless your explain is wrong here).

Is there any way short of using the retail full Access package
to make the runtime pay attention to security restrictions?

It not a question of "making" it respect the restrictions, it question that
it was setup incorrectly. One way would be to ensure that you copy the
workgroup file from a working machine to the machine(s) using the runtime.
It would be a curl joke if security could be thwarted this way, and it in
fact it not how security suppose to work. So, something just setup wrong
here, and you have to open up the code and take a look at how the options
are being restricted. It is not security that will hide, or un-hide those
options...it is the programmers code and setup that does this (that code may
be looking at the user logon, but the security settings don't hide/unhide
things).

Alternately, are there any low-cost Access replacements that work well?

If you want to dump the application,and re-write the code, then sure, there
all kinds of alternatives. However, ms-access is quite affordable, and you
can deploy free to machines if you have the runtime.

However, there is no "alternative" that is going to allow you to "run" and
develop the application as is. If you choose FoxPro, dbase, vb.net..or
<insert favorite development tool here>, then that is what you have to use.

If you write your code in FoxPro, then you be using FoxPro to maintain and
modify the application. If you write your code in vb6, then you be using vb6
to maintain and modify the application. And, if you write your code and
application using ms-access, then you be using ms-access to maintain and
develop that application. You can choose any developer tools you want, but
the you not be using ms-access anymore.

You can most certainly pull out data from this application into just about
any other database system, but the code and forms developed using a
particular development language and set of tools will be lost in the
transfer.

 

[Gregg Hill]

Albert,

Thank you for your explanations. The look of the application does indeed
change depending upon whether or not the "Admin" user name is used when
logging into the computer. If one has logged into the workstation with the
"Admin" user name, then the menu bar shows, as do three extra buttons on the
front end. The shortcut points to an MDE file on the local workstation,
which then retrieves data from an MDB file on the server.

I know almost nothing about Access, but I may get curious and delve into it
to see if I can figure out what makes the buttons and menu show or not in
Access but not when using the runtime.

Thank you for your help!

Gregg Hill

 

[Gregg Hill]

Holy Zimbabwe! That is way over my head. I cannot figure out where to look
in the MDE or MDB file to find where it creates the buttons, nor do I find a
reference to "admin" anywhere I looked.

The database is used to calculate paint formulas. When the application is
opened, it shows a black background with grey buttons that have black text,
four white boxes that are the input fields, two columns of eight boxes that
are the formula amount fields, and eleven buttons. Three of those buttons
are not visible if using the full Access and logging in as anyone other than
the "admin" user name. If I enter a formula number, it shows the amount of
each color that needs to be added.

How can I find what creates the buttons and fields I see? Heck, I don't even
know if I am remotely close to where I should be looking.

If I open it and hold down the Shift key, I can see all the tables and
"stuff" that make up the MDB file.

Gregg Hill

 

[Guest]

Configuration of Access applications, like configuration of Word
or Excel or your desktop, depends on the logged in user. So it
ordinarily any Windows user can have Access setup differently
than other Windows users, and differently from the default.

However, an application built for users should specifically control
how the application is configured. It sounds like this has been
attempted, but perhaps not done the right way to work with the
runtime environment, which has slightly different rules.

Actually, it sounds like the ordinary users get a normal Access
environment, specially configured, and the 'admin' user gets a
special menu.

But that doesn't work in the Runtime environment, because the
runtime environment doesn't have the normal Access menus.

So perhaps in the runtime environment the menu configuration
fails, and it falls through to displaying the special admin menu.

(david)

 

[Gregg Hill]

It looks as though I may have to hand off this project to an actual Access
developer. Too far above my head. Or, they'll just have to pop for full
Access version on their factory computers.

Thank you for your time!

Gregg Hill