I have installed Sybase ASE 15.0.3 on Read Hat Linux. ASE server is up and running. However, i am not able to connect to the server via iSql.
[sybase#ip-********* install]$ isql -SCLGETCLD -Usa -Pnull
Unable to retrieve localized message for ID 4
CT-LIBRARY error:
ct__string_extended_encryption: user api layer: internal common library error: Client password encryption fails.
I am using the default password null for sa. I have not set any password for Sa during the installation process.
I have tried looking into the interfaces file and it'looks good. Looked out for the libraries sybase/15/OCS-15_0/lib3p/sybcsi and they are good with right permissions in place.
Not really sure if i am missing something. Any inputs regarding the issue would be greatly appreciated.
Related
I've tried to connect an SQL database from a server with Microstrategy located in another server through an ODBC connector for SQL.
First I've checked that there is a connection between the two servers executing a ping sentence with the IP Address the other server and it went through.
After making sure the connection is stablished without issues, I've tried to connect through Microstrategy without success. The error I get is the following message:
"Connection test error: Connect failed. Error type Odbc error. Odbc operation attempted: SQLDriverConnect (08001:0: on SQLHANDLE)"
Using SQL Server 2017 for the databases and Microstrategy 10.4.
Please, anybody has any clue about what might be happening?
Thanks,
look at the type of connector to the db you have. It gave me the same error until I used: "with Native Client Driver".
Could you please share the complete error message, SQL Handle error are associated with multiple error scenarios like invalid username * password, connecting 64 bit server with 32 bit ODBC driver etc. Complete error message would help me to debug it.
In general follow the steps to debug the error, (any order)
Check the version of ODBC Connection (64bit / 32 bit), it should be the same as server version.
Try testing the ODBC connection that you have created using ODBC Administrator tools to see whether there is an problem with username & password/server name or database connection issue.
Check the Database Instance/Database Connection/User Login created under the Administration option to ensure everything is working and give the correct value.
if nothing works try using the native driver given by MicroStrategy, you can access this using Connectivity Wizard.
Hope it helps..
I have SQL Server that uses Kerberos authentication on my company's network. I am trying to setup a Linux system to be able to access that SQL Server using pyodbc. I am new to Kerberos, but have been able to get my Linux (Ubuntu 16.04) box working with Kerberos... Atleast thats what I think. I can do kinit <username> and it recognizes my username and password.
What do I do next?
If I do this:
sqlcmd -S MyDatabase.corp.com
I get this:
sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server : Cannot generate SSPI context.
Sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server : SSPI Provider: Cannot find KDC for realm "COMPANYNET.CORP.COM".
I am pretty sure I am just not doing the next step but I haven't found a good source to tell me what to do next. Any help is much appreciated... Thanks!
After much headache and annoying a lot of people at my company I got this to finally work.
Had to get a Service Account setup on the Domain
Had to get a krb5.keytab file made by an AD Admin
Had to setup Kerberos with the correct Domain in my /etc/krb5.conf file
Had to have SPNs set for the target SQL Server (This seems to be the actual cause of the above error message)
Ensure proper permissions set Service Account on SQL Server.
Once above was set I can do:
kinit -k <SERVICE ACCOUNT NAME>
sqlcmd -E -S MyDatabase.corp.com
I have a Firebird Database (v2.5) which lives on a server with hostname "FBDEVDB". I am working on a separate server on which I have installed SQL Server to begin the process of migrating the tables and data into a SQL Server database.
I saw several posts discussing that this can be done using the Import Data feature of SSMS with an ODBC connection to the Firebird DB. So, I have downloaded and installed the Firebird ODBC Driver 64-Bit. When I went to configure my DSN I first got an error regarding a missing gds32.dll. Looking into it further, I realized I needed the fbclient.dll from the Firebird files. I've copied it over to my SQL Server machine, and now the gds32.dll error is gone, and I can tell it is TRYING to connect to the Firebird instance because if I provide an incorrect username/password it tells me my login is incorrect.
However, when I use a valid login/password, I get the following error message
I have defined the following fields in the ODBC setup
Database: FBDEVDB::C:\Firebird\MYDATABASE.FDB
Client: C:\Temp\fbclient.dll
Database Account: SYSDBA with VALID PASSWORD
What am I missing? I can not seem to find any information on what this error means.
Thank you!!!!!
I installed Oracle database 12c for the first time. I followed correctly all the steps and installed it on Windows 7 64 bits, but when I click on SQL Developer and try to create a new connection, I put in the informations like Username and password, and finnaly click on TEST button, I get this error message: "The Network Adapter could not establish the connection".
I dont know what to do anymore, I read tutorials and cant solve that error. Also, when I open SQL Developer, i get a message saying Im using a java version that is not supported by Oracle Database, Im using java 1.8 and it says I should use from 1.6 to 1.7 only. im not sure if that is causing something bad but it seems fine because I can go further using the SQL Dev. So, what should i do? Thank you very much!
Here are some things to check:
Ensure that the TNSNAMES.ORA file is properly configured to reference the database. Check for the SID, host name, and port number (typically 1521).
Check whether you can connect directly from the server, such as with SQL PLus. This should isolate whether it's a server or client problem.
Ensure that the Listener service on the server is running. Check that LISTENER.ORA is properly configured.
I encountered a situation in the past where client PCs could not connect. I found that by deleting (or renaming) the SQLNET.ORA file, the connection could be made.
Good luck.
Execute
tnsping <db_name>
from command prompt.
You will see, if listener is running and tnsnames.ora is configured properly.
Run with Windows PowerShell or Command Prompt (Admin) :
lsnrctl start
I am working on SQL Server 2008 R2 Express, when I am using SQL Server debugging feature from client pc, this error occurs:
The EXECUTE permission was denied on the object 'sp_enable_sql_debug', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
My user name is 'HALI' and permission is assigned to me is 'public' and 'db_Owner',
now after this error I have assigned all permissions available. And all server roles.
Now at this time I got new error message,
Error HRESULT E_FAIL has been returned from a call to a COM component. (mscorlib)
Now what the solution would be for this error.
I am not sure if disabling firewall is enough. if the user has sysadmin permissions and still getting this error means client is not able to connect to server in debugging mode. check this TCP and UDP ports are correctly open.
SQL remote debugging configuration
EDIT:1
I am sure you must have also googled a lot and tried to find out about the error messages.
What I have found so far is the Error in the OP you mentioned is misleading and from that error, we cannot tell what exactly is wrong or what to look next. But as you replied in the comments, after making changes to enable Remote Debugger; the mentioned error is more clear and I feel that proper permission is still an issue. Plenty of other suggestion you also might have tried so far, but if you haven’t done this, let's try one more time:
In one of the comments I mentioned you to try login using the windows user.
Now Keep the settings you already did for TCP ports, Firewall Exception, etc… explained in the above link.
you have windows 2012 server where you installed DB server. and windows 8 Prof where you have DB client and you connecting through SSMS. Now I believe both machines are in the same domain. Let’s say domain XYZ. You must have windows login on server, let’s say it is “XYZ\HALI” using which you can login to the Windows Server. log in and make sure that login also exists in SQL SERVER with sysadmin permission. Because client machine is also in same domain make sure you have logged in into the client machine using same user “XYZ\HALI”. Now start SSMS and choose windows authentication instead of SQL SERVER authentication. Try to start Debugging T-SQL code now.
if client and server machines are not in the same domain then we have to register server name on client machine as Linked Server, impersonate the login/user as local and then try the debugging.
Edit:2
I encountered this problem after generating a SQL 2012 script and running it in a SQL 2008 R2 database.
After some research, I found out that my target SQL 2008 R2 was running on a 32-bit OS which supports a file of up to 2GB in size. So I saved the script as C:\myScript.sql and successfully executed it in a command prompt with these steps:
Open a command prompt window.
In the command prompt window, type:
sqlcmd -S myServer\instanceName –U yourUserName –P yourPassword -i C:\myScript.sql
where myServer\instanceName is the instance name. Supply the user name and password for SQL server login, and finally the path of the file as indicated.
Press Enter.
References:
sqlcmd Utility | Microsoft Docs
Use the sqlcmd Utility | Microsoft Docs
The few times I've run across that error, it's always been firewall related. Are you working on a remote server, or your local machine? (Parenthetically, be careful assigning all possible roles. Some of them are ones you absolutely don't want. The one you need for SQL debugging is sysadmin - try disabling the rest of the roles you checked off and just assigning that one.)
Debugging procs is always a pain. This ASP.NET post helped me out substantially awhile ago.