On 30 jun, 14:21, lyle fairfield <lyle.fairfi...@[EMAIL PROTECTED]
> wrote:
> On Jun 30, 1:02=A0am, "Larry Linson" <boun...@[EMAIL PROTECTED]
> wrote:
>
> The solution is application roles as per this thread. The application
> connection has permissions, not the user who has only login
> permissions for the server, but nothing else. When he creates a new
> ADP he can see or use nothing. His db window is blank and he can do
> nothing, not even with code. But it's "application connection" that is
> the killer here. It's the Connection that fills the role and has the
> permissions, not the application as we might think. Access in general
> and ADPs particularly are entirely undisciplined about connections.
=2E..
> them is a pain. Even that would be OK if these connections, and when
> and how they are created were do***ented. TTBOMK they are not
> do***ented (maybe because they are unknown) and their creation seems
> to be erratic.
Okay. I conclude you Access in a way I like to do as well. Although it
=B4s not a perfect product it may function allright in a number of
situations and is a wonderfull tool for development.
My conclusion is that sp_setapprole is THE mechanism for my problem,
but that it's not possible to use it in a good way from Access. For
that reason I think I will not use the "integrated security" way in
the project I do now, but go back to the wellknown "1 useraccount and
secure the mde" approach. I still have to do some research about the
performance effects when using local account names (instead of
loginnames on the server) but I think this will do the job as well.
And no... I won't get a price for the architecture of the solution but
that's not my goal now.
>
> Addendum: ADPs provide a very simple way of interacting with Internet
> Enabled SQL Servers. I could send you a less than one meg ADP, and you
> and I could both work on an SQL DB in South Africa, anywhere in the
> world, WITH all the protections of locking etc, and the beautiful
> Access re****ts available to us. All you need is Access and an Internet
> connection. This is amazingly powerful and universally ignored. Oh
> well, it's also lucrative, especially when I'm the only one doing it.
> Security? It requires a USERID and a Password. They can be encrypted.
> The server has super Security software and hardware surrounding it.
> Can it be broken? Probably. Will it be? I have a database on my
> (rented) server. The challenge for two years has been, break in, and
> in the table called Dog, create a new record and enter your name
> there. So far, the table is bare.
>
> And so, the poor dog has none.
Wow. That's new to me. Quite interesting for certain cir***stances.
And good luck with your nameless dog!
|
