I want to access Unix Database from my SAP system.
I was using cl_sql_connection class to open the connection.
This class was working fine before the upgrade to EHP7.
But, now, I am unable to Access table DBCONN in any Stabdard SAP transaction (SE16, SE11...)
Following is my code, returning exception since EPH7 upgrade.
* Fetch data from the ACMM application, using db-links.
TRY.
CALL METHOD cl_sql_connection=>get_connection
EXPORTING
con_name = lw_dbcon_name
RECEIVING
con_ref = lo_sql_connection.
CATCH cx_sql_exception .
=>An exception occurred while opening SQL Connection
ENDTRY.
Is their any other way through which i can connect to other Server?
Yes, there is. You can use the (older) variant of EXEC SQL.
But before you do, check the connection using ADBC_TEST_CONNECTION in SE38.
You could also get some more details by exploring the exception object you have. Here is how I usually do it:
TRY.
EXEC SQL.
CONNECT TO 'ZUNIXDB_DBCON'
ENDEXEC.
EXEC SQL.
OPEN dbcur FOR
SELECT id FROM table
ENDEXEC.
CATCH cx_sy_native_sql_error INTO lr_cx_native_sql_error.
Now you have info like:
lr_cx_native_sql_error->get_text( )
lr_cx_native_sql_error->get_longtext( )
lr_cx_native_sql_error->sqlmsg
Related
When debugging in SQL, I get the following exception :-
System.Data.SqlClient.SqlException: 'A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)'
When I then set next statement and run the statement again, it works. It also works when I'm running the application standalone as a compiled application. Anyone know why this causes an error only when in debug.
The connection is to a remote database sited off-site, not to the local database.
Data Source=xx.xx.xx.xx;Initial Catalog=TheDatabase;User ID=MasterUser;Password=AsIfIMGoingToPostThat
Your help, appreciated.
This is my function to connect...
Public Sub New(ByVal strConnect As String)
Try
dbConnect = New System.Data.SqlClient.SqlConnection(strConnect)
dbConnect.Open()
objParams = New List(Of SqlClient.SqlParameter)
m_bIsConnected = True
Catch exc As Exception
m_bIsConnected = False
Finally
End Try
It looks like your local connection doesn't default to named pipes but your compiled version will try (or is allowed to use TCP/IP). The error shows that it may be expecting named pipes.
Try putting this "np:" in the Data Source in your connection string:
Data Source=np:xx.xx.xx.xx; ...
To get it to connect first time, it looks like I need to add "Network Library=DBMSSOCN;" to connect in debug. t.b.h., Have no idea why...
I have two service programs: mySrvPgm and myErr
mySrvPgm has a procedure which contains:
/free
...
exec sql INSERT INTO TABLE VALUES(:RECORD_FMT);
if sqlError() = *ON;
//handle error
endif;
...
/end-free
myErr has a procedure sqlError:
/free
exec sql GET DIAGNOSTICS CONDITION 1
:state = RETURNED_SQLSTATE;
...
/end-free
Background info: I am using XMLSERVICE to call the given procedure in mySrvPgm from PHP. I am not using a persistent connection. myErr is bound-by-reference via a binding directory used by mySrvPgm. Its activation is set to *IMMED, its activation group is set to *CALLER.
The problem: Assume there is an error on the INSERT statement in mySvrPgm. The first time sqlError() is called it will return SQLSTATE 00000 despite the error. All subsequent calls to sqlError() return the expected SQLSTATE.
A workaround: I added a procedure to myErr called initSQL:
/free
exec sql SET SCHEMA MYLIB;
/end-free
If I call initSQL() before the INSERT statement in mySrvPgm, sqlError() functions correctly. It doesn't have to be SET SCHEMA, it can be another GET DIAGNOSTICS statement. However, if it does not contain an executable SQL statement it does not help.
The question: I believe the myErr service program is activating properly and has the correct scope, but I am wondering if there is something more I need to do to activate the SQL part of it. Is there some way to set it up so SQL auto-initializes when the service program is activated, or do I have to execute an unneeded SQL statement in order to get it started?
There is some more background information available here.
Thank you for reading.
What version an release of the OS? Are you upto date on PTFs?
Honestly, seems to me that it's possibly a bug. Or the manual(s) need clarification.. I'd open a PMR.
I'm making a bulk copy onto a file of a select in my database.
DECLARE #cmd varchar(1000)
DECLARE #sql varchar(8000)
SET #cmd='"select * from [MyDB].[dbo].MyTable"'
SELECT #sql = 'bcp '+#cmd+' queryout C:\myfile.txt -c -t -T -S MyServer -U user -P password';
exec xp_cmdshell #sql;
If I change the parameters and I execute the same command on the database test on my machine it works, but on the database server I get this error:
Msg 121, Level 20, State 0, Line 0
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
I check server name, user, password, table name and they are correct, so I cannot understand what I'm doing wrong.
Can someone help me with this issue?
thanks
Increase timeout seconds in connection string.
private static void OpenSqlConnection() {
string connectionString = GetConnectionString();
using(SqlConnection connection = new SqlConnection(connectionString)) {
connection.Open();
Console.WriteLine("State: {0}", connection.State);
Console.WriteLine("ConnectionTimeout: {0}",
connection.ConnectionTimeout);
}
}
static private string GetConnectionString() {
// To avoid storing the connection string in your code,
// you can retrieve it from a configuration file, using the
// System.Configuration.ConfigurationSettings.AppSettings property
return "Data Source=(local);Initial Catalog=AdventureWorks;" + "Integrated Security=SSPI;Connection Timeout=30";
}
I had the same error. A third-party tool was connecting to the database to extract data for import into a business intelligence system. Each extract/import would run for about 1 hour and there would be something like 10 to 15 separate queries in the process. Fortunately we had logging in place - so we knew at what time each of those queries was starting and ending. The extract/import process was saying that it was completing successfully after 30 minutes - rather than taking about 1 hour. I was able to isolate the query during which the process was failing. When I ran that query in SSMS I got the same error you've given in the question.
However, when I ran that query in another environment, I got an error that a subquery cannot return more than one row.
Sure enough, when I commented out my subqueries in the prod environment, the query ran without any error.
So ultimately, the root cause for me was a subquery returning more than one row - and the issue only appeared because for some reason, "bad data" got into the database - ie. that particular subquery should never have found a scenario where there is more than one row, and hence too, the error just began to appear one day. (For other people who are experiencing this error intermittently - it could be because it is only some of your queries - or one of your queries - that is failing).
Did any one see this error ??
I'm using Firebird 2.1 and database create statement is getting failed on v.first stored procedure execution.
Error Message:
[869] : There was a problem creating a DBProvider with the following parameters: StoredProcedureName:sel_NextObjectID
2. operating system directive CreateFile failed
3. operating system directive CreateFile failed
Stack Trace
2.at FirebirdSql.Data.FirebirdClient.FbConnectionInternal.Connect()
at FirebirdSql.Data.FirebirdClient.FbConnectionPool.Create()
at FirebirdSql.Data.FirebirdClient.FbConnectionPool.CheckOut()
at FirebirdSql.Data.FirebirdClient.FbConnection.Open()
at FirebirdDBProvider.NewProvider_Internal(String commandText, String connectionString, CommandType commandType)
3 at FirebirdSql.Data.FirebirdClient.FbConnectionInternal.Connect()
at FirebirdSql.Data.FirebirdClient.FbConnectionPool.Create()
at FirebirdSql.Data.FirebirdClient.FbConnectionPool.CheckOut()
at FirebirdSql.Data.FirebirdClient.FbConnection.Open()
at FirebirdDBProvider.NewProvider_Internal(String commandText, String connectionString, CommandType commandType)
You can get this error when you are attempting to connect to a database which does not yet exist.
It is not entirely clear from your post what you mean with 'database create statement is getting failed on v.first stored procedure execution', but I assume you are attempting to create a database and then execute DDL.
To connect to a database, you first need to create it. To create a database you need to use createDatabase first.
Well, deleting all temp file fixed this thing. Found the same issue on firebird too.
1) Make sure your application (on which you're facing this issue) is not running.
2) One Run dialog (Window + R) and type in “%temp%” and click “ok”
3) In the opened folder delete all the files (which can be deleted).
4) Start the application.
Just had same issue, the reason was no free space available on the system drive.
I'm getting a return code of -991 upon running a db2 batch cobol program.
The program is attempting to fetch 65 rows within a cursor structure.
I cannot find anything on this particular error, does anyone know what it means ?
You probably want to look at the db2 documentation.
Error code -991 is here.
It says:
-991
CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO DB2. RC1= rc1 RC2= rc2
Explanation
Call attach attempted to perform an implicit connect and open as the result of an SQL statement. The connect or open failed with the returned values.
rc1
The value returned in FRBRC1 for the failed CONNECT or OPEN request.
rc2
The value returned in FRBRC2 for the failed CONNECT or OPEN request.
System action
The statement cannot be processed.
Programmer response
Verify that the application intended to use the call attachment facility (CAF) as the mechanism to connect to DB2®. For functions or stored procedures running in the WLM-established stored procedure address space the application must be link-edited with or dynamically allocate the RRS attachment language interface module (DSNRLI), not CAF.
SQLSTATE
57015
Hopefully that means something to you :)
In case you're still stuck, my google-fu is strong.
SQLCODE -991, Error: CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO DB2. RC1= RC2=
From http://theamericanprogrammer.com/programming/sqlcodes.shtml