OT, a bit: SQL Server DSN

I have an app that requires an ODBC source. The DSN cannot be accessed
unless the Windows login is an Administrator.

I know it's not a by-user problem, because the same user as Limited cannot
read the data, but promoted to Administrator, it works fine.

Any ideas why this might be happening?

swdev2
Sat Apr 01 20:51:24 CST 2006

Heya Paul ....

I would suspect that the Workstation is locked down properly, or locked down
as per that company's guidelines for Workstation Security.
I will assume a system DSN for the moment...
Here's a coupla things you can do:

1. The user does not have to be 'promoted' to an administrator level -
instead the admin can grant the 'proper' rights for that user. When the
administrator is logged in, he/she/it can grant rights to the user for that
named system dsn, all of the odbc drivers (for read,execute) . This solves
the problem in 90 percent of the cases. Many times an 'admin' will create
policies without taken into consideration any custom app needs at all - I'll
guess this to be the case.

2. If the admin does not want to do that for a system DSN, then have them
at least release the admin lock on the odbc driver files, and then create a
USER dsn.

3. You should be able to create a DSN on the fly, programmatically - see
http://fox.wikis.com/wc.dll?Wiki~ProgrammaticallyCreatingDSNs~VFP for more
info

4. Lots of folk love connection strings - see
http://fox.wikis.com/wc.dll?Wiki~VFPCommandSQLStringConnect~VFP and review
the concept of DSNLess Connections.

hth - regards [Bill]
--
===================
William Sanders / EFG VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net www.viasqlserver.net

"Paul Pedersen" <nospam@no.spam> wrote in message
news:#FJVMDbVGHA.2444@TK2MSFTNGP14.phx.gbl...
> I have an app that requires an ODBC source. The DSN cannot be accessed
> unless the Windows login is an Administrator.
>
> I know it's not a by-user problem, because the same user as Limited cannot
> read the data, but promoted to Administrator, it works fine.
>
> Any ideas why this might be happening?

Paul
Sun Apr 02 14:16:06 CDT 2006


"swdev2" <wsanders@dotnetconversions.bob.com> wrote in message
news:ukNmxAgVGHA.1344@TK2MSFTNGP15.phx.gbl...
> Heya Paul ....
>
> I would suspect that the Workstation is locked down properly, or locked
> down
> as per that company's guidelines for Workstation Security.
> I will assume a system DSN for the moment...
> Here's a coupla things you can do:
>
> 1. The user does not have to be 'promoted' to an administrator level -
> instead the admin can grant the 'proper' rights for that user. When the
> administrator is logged in, he/she/it can grant rights to the user for
> that
> named system dsn, all of the odbc drivers (for read,execute) . This
> solves
> the problem in 90 percent of the cases. Many times an 'admin' will create
> policies without taken into consideration any custom app needs at all -
> I'll
> guess this to be the case.

Thanks for your response.

1. How do I do that?

2. Yes, it's a System DSN. I thought a System DSN was always available to
all users. In fact, that's what it says on the ODBC control panel: "A System
data source is visible to all users on this machine, including NT services."

3. Why did it use to work, but doesn't now?



>
> 2. If the admin does not want to do that for a system DSN, then have them
> at least release the admin lock on the odbc driver files, and then create
> a
> USER dsn.

Yes, I could try that. Although I really do want it to be available to "all
users".



>
> 3. You should be able to create a DSN on the fly, programmatically - see
> http://fox.wikis.com/wc.dll?Wiki~ProgrammaticallyCreatingDSNs~VFP for more
> info
>
> 4. Lots of folk love connection strings - see
> http://fox.wikis.com/wc.dll?Wiki~VFPCommandSQLStringConnect~VFP and review
> the concept of DSNLess Connections.

Yes, perhaps that might work. I still can't figure out why the other one
stopped working, though.

Thanks again for your help.