How to Migrate Access Users/Groups/Permissions to SQL Server

I need to take all the user/groups and permissions and migrate them to
SQL Server, how can this be done easily?

"JM" <j_mouland@hotmail.com> wrote in message
news:c8796b00.0401290544.3a00132b@posting.google.c om...[color=blue]
> I need to take all the user/groups and permissions and migrate them to
> SQL Server, how can this be done easily?[/color]

It can't. You would need to re-apply all of your security once the tables
are on the server.


--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

There has to be an API or something that can do this?

"Rick Brandt" <rickbrandt2@hotmail.com> wrote in message news:<bvb31c$qjq9b$1@ID-98015.news.uni-berlin.de>...[color=blue]
> "JM" <j_mouland@hotmail.com> wrote in message
> news:c8796b00.0401290544.3a00132b@posting.google.c om...[color=green]
> > I need to take all the user/groups and permissions and migrate them to
> > SQL Server, how can this be done easily?[/color]
>
> It can't. You would need to re-apply all of your security once the tables
> are on the server.[/color]

Fist of all, SQL Server doesn't care about the sanctity of the Access
objects...it only cares about data.

If you set your Access permissions up properly, then you're application should
"just work."

Rule #1) Access Security is an oxymoron.

You've made a nice step by upsizing to SQL Server.

If your object permissions are set properly, you should be able to use a
universal logon for your application. Where users log into the Access App,
they'll all be connected to SQL Server the "same way" ... that is, rights to
all tables.

HOWEVER! Again, if the application is "secure," certain users will only be able
to use certain forms, reports, queries, etc...so the data exposure should
already be controlled.

The access database is merely the backend for a VB app, so using it to
maintain the permisisons isnt acceptible. I was hoping to migrate the
users and permissions to logins in sql server while maintaining the
object permissions. Inturn eliminating the need for access completely

dcmfan@aol.comSPNOAM (DCM Fan) wrote in message news:<20040129161515.17180.00001062@mb-m03.aol.com>...[color=blue]
> Fist of all, SQL Server doesn't care about the sanctity of the Access
> objects...it only cares about data.
>
> If you set your Access permissions up properly, then you're application should
> "just work."
>
> Rule #1) Access Security is an oxymoron.
>
> You've made a nice step by upsizing to SQL Server.
>
> If your object permissions are set properly, you should be able to use a
> universal logon for your application. Where users log into the Access App,
> they'll all be connected to SQL Server the "same way" ... that is, rights to
> all tables.
>
> HOWEVER! Again, if the application is "secure," certain users will only be able
> to use certain forms, reports, queries, etc...so the data exposure should
> already be controlled.[/color]

I gotcha now...I didn't know about the VB part. But that should actually make
things simpler, since the VB part is a compiled EXE...with no objects visible
to the user.

That means that you only used TABLE-level permissions for certain users, right?

So, again, I'm confused as to what you need, because if your VB project is
built properly, it won't let users go into certain areas, based on login
alone....that has nothing to do with TABLE permissions, and everything to do
with how the VB app was built.

HOWEVER, if the VB is built improperly...and you were hoping that the
TABLE-level permissions would tell you everything about a user, then you're in
deep doo-doo.

I can imagine building a VBA module that would read every user and their
table-rights, and build T-SQL statements that would create the appropriate
logins/permissions on SQL Server, but before I even spend one second on that, I
still need to understand how your VB works.

Why do you ABSOLUTELY NEED the table permissions to work as they did before? (I
claim you don't, since the tables are on SQL Server, and the VB app should be
hiding sensetive areas in the APPLICATION)