>
> [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).

>
> 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!

>
> 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?

>
> [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....
>

>
>
> [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).
>

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

"Keith Kratochvil" <sqlguy.back2u@comcast.net> wrote in message
news:%23LQwfPGaGHA.3652@TK2MSFTNGP03.phx.gbl...
> 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.
>
>
>

"Keith Kratochvil" <sqlguy.back2u@comcast.net> wrote in message
news:%23LQwfPGaGHA.3652@TK2MSFTNGP03.phx.gbl...
> 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.
>
>
>

"Cary Shultz" <cwshultz@mvps.org> wrote in message
news:eq$k5oKbGHA.4612@TK2MSFTNGP03.phx.gbl...
> Keith,
>
> I was able to resolve this (for the moment). I did indeed know the
> password for the SA user account. I sat down on the SQL 7 Server and used
> the SQL Analyzer and what I thought it was did work. I then went to the
> client and tied and it failed. So, that made me wonder. I looked at the
> ipconfig /all and it struck me: the subnet mask on the Server is
> 255.255.252.0 while the subnet mask that the clients are getting via DHCP
> is 255.255.255.0. So, I changed the IP Address on that specific client to
> a manual IP Address outside of the scope that DHCP handles and gave it the
> 252 subnet mask and it connected in about 1.5 seconds.
>
> Thank you very much for the tip. I would probably have come to the SQL
> Analyzer - but who knows when.
>
> --
> Cary W. Shultz
> Roanoke, VA 24012

"Keith Kratochvil" <sqlguy.back2u@comcast.net> wrote in message
news:%23HbU5SVbGHA.4424@TK2MSFTNGP02.phx.gbl...
> Whew. What an ordeal. The important thing is that you resolved your
> issue. Congratulations!
>
> --
> Keith Kratochvil
>
>
> "Cary Shultz" <cwshultz@mvps.org> wrote in message
> news:eq$k5oKbGHA.4612@TK2MSFTNGP03.phx.gbl...
>> Keith,
>>
>> I was able to resolve this (for the moment). I did indeed know the
>> password for the SA user account. I sat down on the SQL 7 Server and
>> used the SQL Analyzer and what I thought it was did work. I then went to
>> the client and tied and it failed. So, that made me wonder. I looked at
>> the ipconfig /all and it struck me: the subnet mask on the Server is
>> 255.255.252.0 while the subnet mask that the clients are getting via DHCP
>> is 255.255.255.0. So, I changed the IP Address on that specific client
>> to a manual IP Address outside of the scope that DHCP handles and gave it
>> the 252 subnet mask and it connected in about 1.5 seconds.
>>
>> Thank you very much for the tip. I would probably have come to the SQL
>> Analyzer - but who knows when.
>>
>> --
>> Cary W. Shultz
>> Roanoke, VA 24012
>
>