Newbie Alert: Amending all client workstation ODBC's

Hi All,
Newbie question for you all, sorry. I'm currently migrating my DB's to a
new SQL 2000 server and am wondering if there's any way of centrally
changing the ODBC settings of all my workstations? I really don't want to
have the support guys visit each machine in turn and do this manually.
Any advice gratefully received.
Orb.
The ODBC aliases are stored within the registry. Assuming that you are just
changing a server name or IP address of the currently configured database
server you should be able to create a .reg file that your users can "run"
within the logon script.
There is one issue with this method: The users have to have the ability to
write to that part of the registry.
Keith Kratochvil
"Orbital" <sian.clarke@.newhamhealth.nhs.uk> wrote in message
news:eto7MV0TGHA.4952@.TK2MSFTNGP09.phx.gbl...
> Hi All,
> Newbie question for you all, sorry. I'm currently migrating my DB's to a
> new SQL 2000 server and am wondering if there's any way of centrally
> changing the ODBC settings of all my workstations? I really don't want to
> have the support guys visit each machine in turn and do this manually.
>
> Any advice gratefully received.
> Orb.
>
|||Hi Keith,
Thanks for replying. I thought this might be the case, I just wondered if I
was missing any fancy enterprise tools which would do this for me ;o)
Many Thanks,
Orb.
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%23tn$eu0TGHA.5332@.tk2msftngp13.phx.gbl...
> The ODBC aliases are stored within the registry. Assuming that you are
> just changing a server name or IP address of the currently configured
> database server you should be able to create a .reg file that your users
> can "run" within the logon script.
> There is one issue with this method: The users have to have the ability
> to write to that part of the registry.
> --
> Keith Kratochvil
>
> "Orbital" <sian.clarke@.newhamhealth.nhs.uk> wrote in message
> news:eto7MV0TGHA.4952@.TK2MSFTNGP09.phx.gbl...
>
|||We used .reg files in my last shop to update DSNs when needed. This method
worked great!
Keith Kratochvil
"Orbital" <sian.clarke@.newhamhealth.nhs.uk> wrote in message
news:esSsqa1TGHA.4900@.TK2MSFTNGP12.phx.gbl...
> Hi Keith,
> Thanks for replying. I thought this might be the case, I just wondered if
> I was missing any fancy enterprise tools which would do this for me ;o)
>
> Many Thanks,
> Orb.
>
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%23tn$eu0TGHA.5332@.tk2msftngp13.phx.gbl...
>

Newbie Alert !

Dear Folks,

First time here.

Have just installed a 120-day evaluation copy of MSSQL 2000.

In the 'blur' and confusion of installing this on my WinXP Laptop, I
forgot to record the password.

Finally, I got into the 'logins' tab on the Enterprise Manager, and
modified the 'sa' password to 'ivlem1', and I think it was recorded
properly.

I tried to test my installation with the following at the Command
Prompt:

osql /Usa /P ivlem1

It failed saying I wasn't 'Trusted'

I would appreciate any help offered !

TIA,

-Mel SmithDid you select "mixed" mode for authentication. I would test this
differently...fire up QA and use your SA account/passwd to account.
There are too many things that could go wrong with establishing a
connection using osql.

HTH

MJKulangara
http://sqladventures.blogspot.com|||Mel Smith (medsyntel@.aol.com) writes:
> Have just installed a 120-day evaluation copy of MSSQL 2000.
> In the 'blur' and confusion of installing this on my WinXP Laptop, I
> forgot to record the password.
> Finally, I got into the 'logins' tab on the Enterprise Manager, and
> modified the 'sa' password to 'ivlem1', and I think it was recorded
> properly.
> I tried to test my installation with the following at the Command
> Prompt:
> osql /Usa /P ivlem1
> It failed saying I wasn't 'Trusted'

SQL Server have to means of authentication: Windows authentication (a.k.a
Integrated Security or Trusted Connection) and SQL Server authentication.
Windows authentication is always there, SQL authentication is optional,
and usually referred to as "mixed mode".

Windows authentcation means that you log into SQL Server with your
Windows credentials. This is very simple, you just say "osql /E" and
you are on the air. No need for password, as you are already logged
into Windows.

By default, only Windows authentication is enabled. This is because
SQL Server authentication is less secure. However, many enable
SQL authentiation for various reasons. For instance, if you are a
developer you may work with Windows authentication as long as you
develop and have sysadmin rights. But when you need to test, you
want a low-priv user, and testing different users is much easier
with SQL authentication.

You can change authentication mode from Enterprise Manager. Right-
click the server, select Properties, and then use the Security tab.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland and MJK,

Thank you both for your advice !

Erland:

I tried "osql /E" and it worked ! (i.e., I got correct correct results
for the two queries: select @.@.servername and select @.@.version)

(now I'm going to go blind reading all there is on Books Online to get
myself up to speed )

btw, I'm fairly expert in xBase databases (my job is tech support for a
structural steel company that uses my software, but is now moving to MSSQL)
and I have to show that I'm up to the task to help them make that move. In
fact, they have purchased AccPac for Windows, and have installed MSSQL 2000.
But I'm at a remote location from the headquarters of this company and must
get used to MSSQL all by myself in the 'sunny south'.

Thanks again.

-Mel Smith
Mesa, Arizona, USA