I've run this application a million times...
Today I'm testing my application on a new PC and get an exception error everytime the code runs the SAConnection.Close() command.
This is what I'm doing...
SAConnection dbConn = new SAConnection(m_cnBuilder.ConnectionString);
dbConn.Open();
if (dbConn.State == ConnectionState.Open)
{
MessageBox.Show(this, "Connection successful", "Note", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
}
dbConn.Close();
Not rocket science. The error comes on the last line. Can anyone help me with this?
The error I get is:
SQL Anywhere .NET data provider: Run time SQL
error -- ??? (-300)
Error code -300 suggests you executed some SQL and that there is an error in the SQL.
-300 Run time SQL error -- %1
An internal database error occurred. If it can be reproduced, it should be reported to iAnywhere. You may be able to work around this problem by modifying the associated query statement.
Related
This happened to me today.
My MVC.Net application was running fine since few months. Today it caught error when executing this part of code.(this is the simplified version)
var cmd = db.Database.Connection.CreateCommand();
cmd.CommandText = $"mySchema.myStoredProcedureName {param1};
db.Database.CommandTimeout = 0;
db.Database.Connection.Open();
var reader = cmd.ExecuteReader();
Where db is a DbContext EF6.
The timeOut occured on the last line
I tried the syntax "using" no success
I tried also the following, maybe the connection is not opened
while(db.Database.Connection.State != ConnectionState.Open) {
db.Database.Connection.Open(); }
No! success.
The stored procedure returns result in 2 seconds on SSMS.
Finally I created a similar stored procedure with another name
Then it worked.
My question:
- Did MSSQL blackList my stored procedure?
I don't think it was blacklisted. Is it possible that your indexes were in need of a rebuild? In other words the renaming really may not have fixed the problem, but some other sort of SQL Server maintenance behind the scenes did?
My educated guess is the server provider did something to affect you if you did not change any code.
I got this error message after running my SSIS package with job, sometimes running this task manually completes successfully.
Error : 2014-12-01 06:28:44.37
Code : 0x00000000
Source : SQL Server Analysis Services Processing Task
Message :
Fin de l'erreur
Warning : 2014-12-01 06:28:46.62
Code : 0x80019002
Source : Package
Message: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method
succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure.
This occurs when the number of errors reaches the number specified in MaximumErrorCount.
Change the MaximumErrorCount or fix the errors.
Fin de l'avertissement
DTExec : l'exécution du package a retourné DTSER_FAILURE (1).
Démarré : 05:00:01
Terminé : 06:28:57
Écoulé : 5334.95 secondes
This is an old entry here but for those who may have similar issue. I had exactly same problem. SSIS was completing successfully(all steps were green) although it was still popping up an error.
In my case, I had some disabled tasks(steps) which had some errors. I think that although they were disabled and will not be executed, SSIS still verifies them and returns error and under the "Progress" tab, it doesn't display extended error information. It only returns this message in the question.
But exact question can be observed using the "Log Events" window which can be found under "SSIS->Log Events" menu on top of Visual Studio 2015. There you can see "Name" with "OnError".
Check out http://msdn.microsoft.com/en-us/library/ms141212(v=sql.105).aspx
You can enable logging to a SQL table for your runtime SSIS packages, and see what is actually causing the error.
SqlException has the property Number.
Then there is this: http://msdn.microsoft.com/en-us/library/cc645603.aspx
and this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx
And it seems to be one or the other
QUESTION:
How is it decided which?
REASON FOR ASKING:
I need to catch certain SqlExceptions and decide how to deal with them based on the Number property but I don't know which list I should look at when it seems like the system is using messages from both, and I don't know what criteria is used for choosing.
For example:
Number 53 - from server error message list (exists on both)
Number 10054 - from system error message list (exists on both)
Number -1 - from server error message list (exists only on server list)
Number 121 - from system error message list (exists on both)
......
The theory goes that it's the SQL error number, eg. the server side ERROR_NUMBER(). In other words, the first list.
However there are a number of exceptions reported by SqlClient that occur on the client side, not on the server side. A typical example would be an error like failure to connect to the server, since you did not connect there is no server side error to speak of. For example a bad server name (does not resolve in DNS), in such cases the InnerException will point toward a Win32Exception with NativeErrorCode value of ERROR_BAD_NETPATH. In this case 53, the OS system error code, will be reported as SqlException error number.
Other cases the error reported by the SqlClient is a socket error, like an abrupt disconnect. Again, there is no 'server side' error to speak of, and the SqlException will wrap an InnerException of type SocketException (a subclass of Win32Error) with the NativeErrorCode of one of the well known WSA error numbers, like WSAECONNRESET. In this case the SqlException.ErrorNumber will be 10054, but it's the 10054 from the WSA range, not the 10054 from the SQL Server errors range. I know...
So what are you supposed to do? Make sure you check the InnerException, if it's a Win32Exception then the ErrorNumber is coming from a system error code (OS error). Otherwise it should be a SQL Server error number.
Oh, and then there is -1... I think that is reported by SqlClient itself (eg. some internal state errors) but I'm not sure.
I would look at the documentation for the SqlException.Number property.
This is what it says
This is a wrapper for the Number property of the first SqlError in the
Errors property. For more information on SQL Server engine errors, see
SQL Server Books Online.
I'm using Delphi-XE2 Enterprise, SQLServer 2008 R2 on Windows Server 2008 R2. When a SQL error is raised, the DataSnap server captures it and returns it to the client application. This all works, except the error message it truncated to 256 characters.
A stack track of the DataSnap server when the error is raised shows the SQL error message is truncated when the SQL DB Error is retrieved through the DBX Framework using the [file:Data.DBXDynalink]TDBXMethodTable.RaiseError() method. The following line of code from the RaiseError() method sets the MessageLength to 256, even when the error message is longer. Thus the error message returned to the client is never longer than 256 characters.
Status := FDBXBase_GetErrorMessageLength(DBXHandle, DBXResult, MessageLength);
FDBXBase_GetErrorMessageLength is of type TDBXCommon_GetErrorMessageLength, which is defined as:
TDBXCommon_GetErrorMessageLength = function(Handle: TDBXCommonHandle; LastErrorCode: TDBXErrorCode; out ErrorLen: TInt32): TDBXErrorCode; stdcall;
Is there a way to increase the buffer size to allow more of the database error to be sent to the client (e.g., 512 characters), or is this just a limitation of the DBX Framework?
#Sertac found a very similar problem that Carlos had with a driver truncating the error messages. Carlos found that changing the midas.dll to increase the error buffersize fixed his problem. I'm sure the solution is the same for my issue.
Thanks #Sertac for providing the link to Carlos' question:
Reconcile Error: Has anyone had problems with truncated error messages?
I seem to be experiencing a strange issue when using the SqlErrText from a DataWindow in our application.
The DataWindow executes a stored procedure, lets call it vp_ut_storedProc, and in my case it throws an error when the DataWindow is updated.
When I go into the function to build the error message for our application, the SqlErrText is passed in as follows (as parameter asErrText):
SQLSTATE = 42000
Microsoft SQL Server Native Client 10.0
TimestampNV|Someone Has Updated the Record. Please Refresh.
No changes made to the database
execute dbo.vp_ut_storedProc
I know that PowerBuilder receives the entire error text which is a good thing. But, when we try to save the error text into a local variable
isErrText = asErrText
The value of isErrText is: SQLSTATE = 42000
So, for some reason, it completely ignores everything after the second line. I figure it has something to do with the way the PowerBuilder is reading in the string, but I don't know why this happens.
I should also note that it's not just limited to this one DataWindow. It happens on quite a few of them.
put this in your dberror event of your datawindow
string s_temp
long l_start, l_end
l_start = 42 +Pos(sqlerrtext,'Microsoft SQL Server Native Client 10.0')
l_end = Pos(sqlerrtext,sqlsyntax) - l_start - 3
IF l_end <=0 THEN l_end = Len(sqlerrtext) - l_start
s_temp = Mid(sqlerrtext,l_start,l_end)
fw_msg(s_temp) //can write this at messagebox(this.title,s_temp) // instead
RETURN 1
if its insert or select error. it ignores the syntax and outputs the error. if its a different error. it shows the rest of the errcode