DBMS repository additional pwd needed in Linux?

[Alexander Beck]

I have the following setup. A DBMS repository on a Microsoft SQL Server. Linux clients that want to access the DBMS repository. Accessing from a Windows client works without a problem.

Under Linux, EA installed with wine, after pressing 'Open' in the Open Project dialog an additional EA dialog opens requesting a password ('Enter password' and the dialog has a EA logo at the left top). It does not say which one and I tried the database user password (that is used in the connection string) and my Windows network password. Nothing helps. Does anyone know which password EA is requesting?

[Paolo F Cantoni]

Hi Alexander,

In my experience, when EA asks for a password at this point, there's something wrong with the connection string or the access process.  

It's asking for a password because it's interpreted some access problem as a security issue (but it's really not).

HTH,
Paolo

[«Midnight»]

Paolo is making sense here, but...

With SQL Server and Oracle (probably others too) there are keywords in the connection string that determine if and how the DBMS will establish your credentials. [That is, if and how you will be prompted for the user ID and password to connect to the database versus the operating system.]

I do not have the SQL Server books open just now so you will have to look it up yourself. Look for a 4 letter keyword something like SSPI (I may be right for the first two letters, but not the rest). There are several values that determine whether you will be prompted always, only when the values are not supplied, or never (i.e. you must put them in the connection string). There is an analogous parameter for Oracle, but I do not remember its name.

Note that SQL Server prefers to use your Windows login credentials. This behavior has changed over the SQL Server versions since 2000. As you are running a Windows emulator, you may have to consult the documentation for any implications regarding single login. It is possible you will have to set your SQL Server instance to use explicit login credentials. Recent versions of SQL Server default to using (only) Windows login credentials, so you will have to change your SQL Server configuration.

HTH, David

[Paolo F Cantoni]

Paolo is making sense here, but...

Yeah,  that Paolo guy should have prefaced his experience by saying it was purely windows based.

David is on the right track, but just be aware that sometimes it may not be a true security problem...

Abashed,
Paolo

[Geert Bellekens]

I've noticed that is sometimes helps to edit the connection string manually to overcome these kind of issues.

The easiest way is to saveas in EA (on a client that is connected). This will produce a "shortcut" eap file that can be opened with notepad and contains the connectionstring for the database.
You can edit this one to add user/password and other thing that go into the connectionstring.

Worth a try.

Geert

[Alexander Beck]

Thanks for the input. I will try, David's input. But because I have no access to the SQL server (is controlled by our IT ), it will take a little time.
I will post as soon as I have new findings.

[«Midnight»]

The connection string is managed entirely on your end, so you should be able to play with the settings.

One thing to watch for though, is whether SQL Server is local to your immediate (Windows) domain. In corporate environments this might not be the case. In these cases SQL Server is very sensitive to how login credentials are provided. You must be sure that the SQL Server (versus Windows) login is set up to recognize your fully qualified Windows username. It may not be enough that you can 'see' the appropriate server over the network. Make sure that your Administrator has set up SQL Server with your domain as part of your username. Then try logging in. You might have to provide the fully qualified username in the connection string (or the dialog box if you have one pop up) but I am not sure about that.

HTH, David

PS: Please let us know what happens either way.

[Alexander Beck]

Okay, I had last week finally the support of our IT. With packet sniffer wie found out that between open and the password dialog no request to the SQL server is done. They also checked the connection to the Windows SQL database and it was okay.

So, there is no problem with the connection string but with EA. I use EA 8.0 build857.

This leaves me with an EA problem under wine and linux connecting to a Windows SQL DBMS...

Anybody any other ideas? I will try to get help from sparxsystems...

[Aaron B]

This might be a bit obvious, but just to make sure - can you please confirm that you have the SQL Server drivers installed under the same WINE bottle as EA?  Can any other programs within WINE communicate with your SQL Server database (E.g. SQL Query Analyzer)?

[Alexander Beck]

Yes, I have only the default wine bottle (.wine). Everything for wine is installed there.
During connection setup in EA when I test the connection, it will succeed. In addtion, in the ODBC Data Source Administrator I can make a ODBC user data source and the test connection is also successful.

[alesliehughes]

Trying following these instructions
http://www.sparxsystems.com/support/faq/enterprise-architect-WINE.html

[Alexander Beck]

Finally, we solved it. Thanks everbody for their inputs and their help.

Yes, we did it with the installation guide described in the last response. We only did the small mistake of having changed the order a little bit. We installed EA before adding the oleaut32 to the wine configuration. Then it was missing for the EA application in wine.

So, the solution was
either to do it in the EXACT order as the very good installation guide
or to make sure that for the EA.exe application in the Wine configuration the oleaut32 was added as library.

Sorry, for the troubles, I caused.