Showing posts with label exception. Show all posts
Showing posts with label exception. Show all posts

Tuesday, March 20, 2012

"Too many sessions open"

Hi. I have a program that performs a lot of queries (it's not exactly optimized yet) and I'm getting a "too many sessions" exception. I'm not clear on what a "session" is exactly because for one thing I only have one thread doing any real work, and I thought I only had one connection open for the entire application.

Am I forgetting to dispose of some resource or close a "session"?

I'm not using anything to do with transactions as all of my operations are atomic.

Could you please explain to me exactly what a session is, relative to connection and transaction. Thanks.P.S.
I'm doing most of my work through ExecuteResultSet() methods and iterating the result sets via Read() and Get...().|||

Did you find a solution for this? I'm running into the same problem. Any help is appreciated.

|||Use Data access block library, it is realy usefull

"Too many sessions open"

Hi. I have a program that performs a lot of queries (it's not exactly optimized yet) and I'm getting a "too many sessions" exception. I'm not clear on what a "session" is exactly because for one thing I only have one thread doing any real work, and I thought I only had one connection open for the entire application.

Am I forgetting to dispose of some resource or close a "session"?

I'm not using anything to do with transactions as all of my operations are atomic.

Could you please explain to me exactly what a session is, relative to connection and transaction. Thanks.
P.S.
I'm doing most of my work through ExecuteResultSet() methods and iterating the result sets via Read() and Get...().
|||

Did you find a solution for this? I'm running into the same problem. Any help is appreciated.

|||Use Data access block library, it is realy usefull

Sunday, March 11, 2012

"No Such Interface Supported" Exception 0x80004002 - HELP!

AAAAARRRRRRRRRRRGGGGGGGGG!

I finally figure out why I can't connect to the SQLEXPRESS on this computer (technically, I was a remote connection), get everything installed (Advanced edition), and then...

It keeps telling me that "No Such Interface is Supported" and "Unable to cast COM object of type "System._ComObject" to Interface type..."

I grabbed it in a screen capture and will try to get it to a server tonight when I get home.

Any ideas on this problem?

Jason

http://members.cox.net/pamela444/errorwindow.jpg

Well, it won't let me insert a link, but the photo's at that URL.

|||

This error comes from VS. Have you determined if SQL Express is functioning correctly by itself?

On the computer you are getting this error, try connecting to SQL Express using SQLCmd, open a command prompt and type:

SQLCmd -S <machinename>\sqlexpress -Q "select @.@.version"

If this returns the version of your server, then you know that SQL Express is functioning correctly and that you have it configured to accept the connection if you're trying to access it remotely. Info on configuring remote connections is at:

914277 How to configure SQL Server 2005 to allow remote connections
http://support.microsoft.com/default.aspx?scid=kb;EN-US;914277

Regards,

Mike Wachal
SQL Express team

-
Check out my tips for getting your answer faster and how to ask a good question: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=307712&SiteID=1

Thursday, March 8, 2012

"Incorrect syntax" exception when prefacing SP names with "dbo." and named p

We're currently trying to evaluate SQLJDBC 2005 1.1 June CTP's support for database mirroring automatic failover. Unfortunately we're getting unexpected exceptions for calls that work fine w/ jtds that our blocking our ability to perform these evaluations without us making substantial changes to our codebase.

The first issue is with the name used when calling a stored procedure -- SP names that start with "dbo." give us the following error:

com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near '.'. src:{call dbo.xyz(?,?,?,?,?,?,?,?)}

The call will work if we change the SQL statement to {call xyz(...)}. I don't understand why we would need to do this, especially given that the documentation for the driver shows call statements with the "dbo." prefix.

We're also having problems using named parameters with stored procedures (for both in and out parametes). Our code has parameter names of the form "@.param" as is standard with TSQL (and is required when using jtds). However, this won't work with SQLJDBC -- it only seems to accept parameter names w/o the leading "@.". Why is this so?

Finally, we were able to cause a NullPointerException within the driver due to an incorrectly built Properties object that contained an Integer for loginTimeout instead of a String:

java.lang.NullPointerException

at java.util.Hashtable.put(Hashtable.java:396)

at java.util.Properties.setProperty(Properties.java:128)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.fixupProperties(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.mergeURLAndSuppliedProperties(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source)

While this was due to a bug in our code I would think that such common errors would be better handled.

Hi,

I am not able to reproduce the error that you are seeing with executing a stored procedure with the dbo prefix. What you have provided there looks like it should work fine. Could you provide a code sample that demonstrates the error?

Thank you,

--David Olix

JDBC Development

|||

We're using the Spring JDBC template helper classes in this instance :

JdbcTemplate t = getJdbcTemplate();

Object result = t.execute("{call dbo.SP(?, ?, ?, ?, ?, ?, ?)}",
new CallableStatementCallback() {
public Object doInCallableStatement(CallableStatement cs) throws SQLException, DataAccessException {
cs.registerOutParameter( "@.pParam1", Types.INTEGER );
cs.registerOutParameter( "@.pParam2", Types.DATE );
cs.registerOutParameter( "@.pParam3", Types.DATE );
cs.registerOutParameter( "@.pParam4", Types.DATE );
cs.registerOutParameter( "@.pParam5", Types.INTEGER );
cs.setInt("@.pParam6", i)
cs.setString( "@.pParam7", s1);
cs.setString( "@.pParam8", s2);
cs.execute();

return result; // object created based on out params

}

The template is basically doing a "connection.prepareCall()" with the passed in SQL string, and then calling doInCallableStatement from within a try/catch block that translates

exceptions.

Were you able to reproduce the issue with "@." not being accepted for named params? That problem is effectively impossible for us to workaround, as we would need

to alter large sections of code when switching between jtds and sqljdbc.

|||

Ok, I was able to track down the cause of the Incorrect syntax exception by running a DB trace. The core problem appears to be the use of named parameters -- the call to registerOutParameter resulted in the following being executed on the server:

exec sp_sproc_columns dbo.SP, @.ODBCVer=3

This statement is incorrect -- it needs to be exec sp_sproc_columns [dbo.SP], @.ODBCVer=3

|||

Yes, that's it. If you'd like to submit a bug so that you can track progress on the fix, you may do so through the MSDN Product Feedback center at http://msdn.microsoft.com/feedback . You may have to jump through one small hoop (search for a resolution to your problem) before being taken to the "submit feedback" button that goes to the bug submission form.

I am still researching the "@." issue and will get back to you when I have an answer there.

Thank you,

--David Olix

JDBC Development

"Incorrect syntax" exception when prefacing SP names with "dbo." and nam

We're currently trying to evaluate SQLJDBC 2005 1.1 June CTP's support for database mirroring automatic failover. Unfortunately we're getting unexpected exceptions for calls that work fine w/ jtds that our blocking our ability to perform these evaluations without us making substantial changes to our codebase.

The first issue is with the name used when calling a stored procedure -- SP names that start with "dbo." give us the following error:

com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near '.'. src:{call dbo.xyz(?,?,?,?,?,?,?,?)}

The call will work if we change the SQL statement to {call xyz(...)}. I don't understand why we would need to do this, especially given that the documentation for the driver shows call statements with the "dbo." prefix.

We're also having problems using named parameters with stored procedures (for both in and out parametes). Our code has parameter names of the form "@.param" as is standard with TSQL (and is required when using jtds). However, this won't work with SQLJDBC -- it only seems to accept parameter names w/o the leading "@.". Why is this so?

Finally, we were able to cause a NullPointerException within the driver due to an incorrectly built Properties object that contained an Integer for loginTimeout instead of a String:

java.lang.NullPointerException

at java.util.Hashtable.put(Hashtable.java:396)

at java.util.Properties.setProperty(Properties.java:128)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.fixupProperties(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.mergeURLAndSuppliedProperties(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source)

While this was due to a bug in our code I would think that such common errors would be better handled.

Hi,

I am not able to reproduce the error that you are seeing with executing a stored procedure with the dbo prefix. What you have provided there looks like it should work fine. Could you provide a code sample that demonstrates the error?

Thank you,

--David Olix

JDBC Development

|||

We're using the Spring JDBC template helper classes in this instance :

JdbcTemplate t = getJdbcTemplate();

Object result = t.execute("{call dbo.SP(?, ?, ?, ?, ?, ?, ?)}",
new CallableStatementCallback() {
public Object doInCallableStatement(CallableStatement cs) throws SQLException, DataAccessException {
cs.registerOutParameter( "@.pParam1", Types.INTEGER );
cs.registerOutParameter( "@.pParam2", Types.DATE );
cs.registerOutParameter( "@.pParam3", Types.DATE );
cs.registerOutParameter( "@.pParam4", Types.DATE );
cs.registerOutParameter( "@.pParam5", Types.INTEGER );
cs.setInt("@.pParam6", i)
cs.setString( "@.pParam7", s1);
cs.setString( "@.pParam8", s2);
cs.execute();

return result; // object created based on out params

}

The template is basically doing a "connection.prepareCall()" with the passed in SQL string, and then calling doInCallableStatement from within a try/catch block that translates

exceptions.

Were you able to reproduce the issue with "@." not being accepted for named params? That problem is effectively impossible for us to workaround, as we would need

to alter large sections of code when switching between jtds and sqljdbc.

|||

Ok, I was able to track down the cause of the Incorrect syntax exception by running a DB trace. The core problem appears to be the use of named parameters -- the call to registerOutParameter resulted in the following being executed on the server:

exec sp_sproc_columns dbo.SP, @.ODBCVer=3

This statement is incorrect -- it needs to be exec sp_sproc_columns [dbo.SP], @.ODBCVer=3

|||

Yes, that's it. If you'd like to submit a bug so that you can track progress on the fix, you may do so through the MSDN Product Feedback center at http://msdn.microsoft.com/feedback . You may have to jump through one small hoop (search for a resolution to your problem) before being taken to the "submit feedback" button that goes to the bug submission form.

I am still researching the "@." issue and will get back to you when I have an answer there.

Thank you,

--David Olix

JDBC Development

Tuesday, March 6, 2012

"Duplicated parameter names are not allowed" exception in SQL Server Everywhere

I'm using SQL Server Everywhere CTP with ADO.NET and C# 2.0 and getting following exception:
"Duplicated parameter names are not allowed. [ Parameter name = @.NODE_ID ]"
for the query:

SELECT CHANGE_TYPE,CHANGED,VTRANS,LINK_PARTITION_ID,LINK_ID, SOURCE_PARTITION_ID,SOURCE_NODE_ID,TARGET_PARTITION_ID,TARGET_NODE_ID,TYPE,LOCAL_CHANGE_TIME,ATTR FROM VP8657b26964d4c595a7430761c222f3b3_REL WHERE (((TARGET_NODE_ID=@.NODE_ID AND REL_BASE_TYPE=2)) AND LOCAL_CHANGE_TIME > @.LOCAL_CHANGE_TIME ) OR ((SOURCE_NODE_ID=@.NODE_ID AND REL_BASE_TYPE=2)) ORDER BY LOCAL_CHANGE_TIME DESC

Without underlined frament, query runs fine

IDbCommand.Parameters shows that there are exactly 2 parameters with different names: @.LOCAL_CHANGE_TIME and @.NODE_ID

Exception stack trace is:
System.Data.SqlServerCe.dll!System.Data.SqlServerCe.SqlCeCommand.CompileQueryPlan() + 0xd5 bytes
System.Data.SqlServerCe.dll!System.Data.SqlServerCe.SqlCeCommand.ExecuteCommand(System.Data.CommandBehavior behavior = Default, string method = "ExecuteReader", System.Data.SqlServerCe.ResultSetOptions options = None) + 0x145 bytes
System.Data.SqlServerCe.dll!System.Data.SqlServerCe.SqlCeCommand.ExecuteReader(System.Data.CommandBehavior behavior = Default) + 0x2d bytes
System.Data.SqlServerCe.dll!System.Data.SqlServerCe.SqlCeCommand.ExecuteDbDataReader(System.Data.CommandBehavior behavior = Default) + 0x1e bytes
System.Data.dll!System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader() + 0xa bytes

So, what this exception might mean? does it mean that a parameter might not be used multiple times in a query?

alex777 wrote:

So, what this exception might mean? does it mean that a parameter might not be used multiple times in a query?

Unfortunately, that's precisely what it means. If you watch (with SQL Profiler, for example) how a query is run when you submit it with ADO, you'll see that it's fluffed and rumpled just a little bit -- in order to make parameters work. That fluff-and-rumple mechanism can't deal with the same parameter name being bound again.

You can rewrite your query to be a batch that assigns @.NODE_ID to a variable, then reference the variable in the query. Or, you can create @.NODE_ID1 and @.NODE_ID2, and spread those guys around in the query -- then bind the same variable in the client code to the two different values (that is, add two parameters, each with the same value as the other).

|||Thanks for your reply,

Is it an issue only with SQL Mobile (aka Everywhere) or this will also

be present in SQL Express and Full-Featured SQL Server or even in any

ADO.NET provider?

> You can rewrite your query to be a batch that assigns @.NODE_ID to a variable, then reference the variable in the query.

SQL Mobile seems not to support batch queries (maybe executing multiply commands within the same connection will work, but it's a pretty mess. )

Anyway, I'm going just to substitue this parameter manually:
com.CommandText = com.CommandText.Replace("@.NODE_ID", "'"+guid.ToString()+"'");