Re: Problems connecting to SQL Server

Keith,

Thanks!

I will try tomorrow (or Tuesday) and let you know what happens.
Unfortunately, Maximo is specifically stating that you must use the SA user
account and its password to create the ODBC connection. I have tried in the
production environment with the normal user accounts/passwords with no luck.

I will try the query analyzer.

MDAC looks hopeful. Maybe this is the way around the ODBC problem. In my
test lab - Windows NT 4.0/SP6 - SQL2000/SP3a - Maximo 4.0.3 - I had to use
the SA User / Password to create the ODBC connection. Again, as in the
production environment, I tried with the normal user accounts/passwords (SQL
Users). No love. Please notice that it was SQL2000. I found what I hope
to be the SQL 7 Product ID while scrounging around in some boxes. There was
some other CD in this white sleeve. Let's hope. Then, I should be able to
truly replicate the production environment.

I will also try MDAC. However, I am pretty sure that in order to connect to
the MAXIMO database you have to follow the instructions set forth by MRO
Software. And they specify the SA account.

Thank you,

--
Cary W. Shultz
Roanoke, VA 24012
"Keith Kratochvil" <sqlguy.back2u@xxxxxxxxxxx> wrote in message
news:%23LQwfPGaGHA.3652@xxxxxxxxxxxxxxxxxxxxxxx
inline. old comments removed.

--
Keith Kratochvil



[CWS] Keith, MRO Software suggests that you use SQL authentication. I
looked in the Enterprise Manager and noticed that there are the three SQL
user accounts for the three guys that use this application. I have
indeed tried with each of the SQL user accounts (read: user name and
corresponding password) when creating the ODBC driver. It gives the
18465 error (going on memory here so that might not be the exact error
message...pretty sure that this is the error though).

Do you know what the passwords are for each of the accounts? Hopefully
you do.
If you do: Sit down at a machine that has Query Analyzer installed
Open Query Analyzer
Connect to the server with its name or IP (however they recommend)
Specify the login name and pwd.
Can you log in?



I guess that I need to play with this in the lab. I did create a test
environment at home but the problem is that we did not have the ProductID
for SQL 7 (well, I did not look hard enough. I got it today from looking
in the registry. I will not know until tomorrow if it actually is
correct or not) so I installed SQL2000, created two workstations (WIN2000
and WINXP) and then configured the ODBC driver (to connect to NORTHWIND -
one of the 'test' data bases in SQL - but you knew that already!). I did
this with the SA user account / password combination. The manual for
Maximo specifically states that you must use this SQL user account /
password combination when setting up the ODBC driver. I asked Maximo
about using another user name / password combo and the answer was
effectively that if the manual says 'use this user name/password' then I
should use this user name/password combo. As mentioned, I am a complete
newbie when it comes to SQL and this specific application so I am at a
strong disadvantage here - thus, my post!

I don't think that it matters which user/pwd combination that you use to
set up the DSN because the application that uses the DSN must supply a
user name and pwd while connecting (in SQL Authentication mode).


So, now to MDAC. Are you suggesting that I could simply install MDAC 2.8
SP1 (that is the latest version) on the system in question and, all
things being equal, access the Maximo database (aptly named MAXIMO)? So,
using either ODBC -OR- MDAC should work?

MDAC is Microsoft Data Access Controls. "ODBC" has been replaced by MDAC.
Search Microsoft's download site for MDAC and Component Checker. The MDAC
binaries will give you the latest ODBC drivers. The Component Checker
allows you to check what versions of MDAC exist on a specific system. You
might want to make your test systems have the same version that exist on
your production client boxes.


[CWS] Keith, I asked about this because in the Maximo manual it
specifically states to do this. I do not have the Installation Media for
Maximo 4.0.3 (please do not ask....it is a bit of a sore spot with me
right now...but, I should have it tomorrow!..Thank you, Alda and Denise).
Then I will be able to install it in my test lab and see what happens.
But, 'common sense' would be that I should not have to install the SQL
Server Client on each client. I would think that the native WIN2000 or
WINXP ODBC driver would do the job. But, this might be a Maximo-specific
situation (but, again, I do not see it on the other two functioning
workstations). For the moment I am not going to worry about this....


You don't need to install the SQL Server client on each machine. MDAC
should give you everything that you need!




[CWS] Keith, I will not change any security within the SQL Server.
Honestly, I am not sure that I could do that (unless by accident...).
Well, that is not true. I can read the Help files ;-)






[CWS] Keith, good thought. I have indeed done this. I looked at both
functioning systems. All - as prescribed by Maximo - are SQL
authentication. However, this brings me to a question.

Alert - newbie question about to happen: Do I need all three (user, file
and system) DSNs? Remember, in my test lab I do not have Maximo
installed (that will change tomorrow). I have only the system DSN
configured (again, for accessing the NORTHWIND database...it works!). In
the production environment there are several entries for each (user,
file, system).


A system DSN can be used by any individual (read: user/login) who can log
on to the client machine. This is great because you can set one "global"
DSN that can be used across the system. A user DSN is just what it sounds
like -- only available to the specific user account. I don't know about
file DSNs. I have never used them.



[CWS] Keith, Thank you very much. This is helping a lot.





.

Relevant Pages

  • Re: Access connection to SQL shows as system account in SQL Monito
    ... I wonder if the issue could be the version of MDAC? ... SQL is still ... >>As of the date of the last OS server patch, ... >>their own domain account. ...
    (microsoft.public.sqlserver.odbc)
  • Re: sql problem
    ... Account # is the link field on ... The requirement is I have to come up with a report comparing the two ... customer tables to see if they are in sync. ... what I wanted to do was to get the SQL to return the "like" names ...
    (comp.databases.oracle.server)
  • Re: sql problem
    ... Account # is the link field on ... table1, table2@dblink where ....) ... customer tables to see if they are in sync. ... what I wanted to do was to get the SQL to return the "like" names ...
    (comp.databases.oracle.server)
  • Re: sql problem
    ... Account # is the link field on ... table1, table2@dblink where ....) ... customer tables to see if they are in sync. ... what I wanted to do was to get the SQL to return the "like" ...
    (comp.databases.oracle.server)
  • Re: W2K/WMI service (WinMgmt.exe) accessing an ODBC connection
    ... If a SQL account is used then the only thing needed on the ... machine running SQL is SQL login and database grants. ... If integrated, then in addition, I have seen the account need ... then changing this to use trusted connection ...
    (microsoft.public.windows.server.security)
Loading