David Sparkman wrote:
>
> If you are connecting to a SQL Server 7.0. The best method is to go into
> Client Network Utility and define your "alias" to the server. Here is where
> you would specify the IP of the server, and give it a user friendly name.
Hi Tac -
FWIW, this is the method I use (and was going to suggest, but
David beat me to it!). It seems to work well, and you can even
use it to allow (trusted) clients or remote employees to have
remote access to the SQL DB using their local Enterprise
Manager installation.
I've only used it with SQL7, so if you're using 6.5, this may
be completely useless (don't know), but to elaborate on David's
suggestion, here's the steps I take to set it up:
- Since it's best to use SQL Auth instead of NT Auth, you'll
probably want to create an SQL Login first. To do so, start
Enterprise Manager, then go to the pertinent SQL Server Group
and Server (most likely the one with your machine name).
Expand the directory tree for that server, then expand the
"Security" folder tree. Right-click on the "Login" icon and
select "New Login...". In the "Name" field, enter the login
you'd like to create (this is the one you'll enter of the ODBC
source username later). Then select "SQL Server Auth" and
enter a password. For the "Database" field, select your iMS
database; if you haven't created it yet, leave it set to
"master" for now, then come back and change it after you've
created the DB. Now go to the "Server Roles" tab. Select
a desired role for the login if necessary; each role allows
a certain set of permissions. I believe you may not need to
select any of them, depending on what your login needs to do
with the DB (of course see SQL help for more on server roles).
Now go to the Database Access tab. Check the box for your iMS
database to allow the login to have access to it. Any that you
don't want this login to have access to (probably all other DBs)
should remain unchecked. When you click OK to save/create the
login, you'll be asked to re-enter the password.
- If the iMS database doesn't already exist, it's probably a good
idea to create it now, then go back to the login and change the
two appropriate database settings as described above.
- Now that the database and a login with access to it exist, you
can create an SQL Server alias: Go to the SQL Server 7.0 Program
Group and select "Client Network Utility". Click the "Add..."
button. First select the "TCP/IP" radio button under "Network
Libraries". Then in the "Server Alias" field, enter a sensible
name, like "iMS" (I would avoid spaces, whatever you enter).
Unless what you enter also happens to be the computer name,
delete what was just echoed in the "Computer Name" field and
enter your server host name (like ServerA), or just the IP
address like I do. Now click "OK". You should see it appear
in the list of Server Aliases. Click OK again to close the
Client Network Utility. Now in Enterprise Manager, right-click
on "SQL Server Group" and select "New SQL Server Registration".
When the wizard starts, click Next, then select the Server Alias
you just created from the "Available Servers" list and click
the "Add >" button. Once it's added, click Next. In the next
screen, select the "SQL Server Login" option and click Next.
If you want automatic login, enter the login and password info
you created earlier, otherwise select the "Prompt" option, and
click Next. Then choose to create the alias in an existing
server group, or create a new one and click Next. On the final
screen, click Finish.
To change the Server Alias properties in the future, right-click
on it and select "Edit SQL Server Registration Properties"; for
example, you can set it to always prompt for login info, or to
"hide" the system dbs and objects.
Now when you setup the "iMS" (or whatever) database as an SQL
ODBC source, you should now be able to specify the login and
password you created above (using SQL Auth, not NT), and it
should work fine.
One irritating side note if you use this method to give remote
users access to SQL Server through their local Enterprise
Manager: While you can restrict the given login to a specific
database (and even specific actions on that db, like read and
write), their Enterprise Manager will display almost all the
objects in your SQL Server, ie all the databases, all the
logins you've created, etc. The user will not be able to do
anything with them if you haven't given them permission to,
but it still seems ridiculous to me that they're even allowed
to see them all. I wish MS had used the method they did in
Exchange Server, where you can explicitly set what users are
even allowed to see, let alone access/modify.
Sorry if this has gotten a little off topic, but perhaps the
info will be useful to Tac and/or someone else.
BTW Tac, I'm eager to see how your List app comes out too -
I'm also looking to move off NTList but haven't had time to
develop anything solid. Sounds like you're well on your way...
Regards,
Mike
PS - Howie and all the iMS crew: keep up the GREAT work!
--
---------------------------------------------------------------------
Michael Gardiner $^> V: (650) 938-4688
SQUISH Internet Services FAX: (650) 938-4013
P.O. Box 391503 Internet Service
Mountain View, CA 94039-1503 Provider & Consulting
mailto:[EMAIL PROTECTED] http://www.squish.com
---------------------------------------------------------------------
"Making the world a smaller place"
---------------------------------------------------------------------
========================================================================
This list server is Powered by iMS
'The Swiss Army Knife of Mail Servers'
--------------------------------------
To leave this list please complete the form at
http://www.CoolFusion.com/iMS.htm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
========================================================================
