none
SqlDbType enumeration value invalid

    Question

  • Has anyone seen this before?

    System.ArgumentOutOfRangeException: The SqlDbType enumeration value, 7, is invalid.
    Parameter name: SqlDbType

    The odd thing is, enumeration value 7 is NOT invalid, it represents the Image type.

    Any help gratefully received, thx.

    ~swg

     

    Server stack trace:
       at System.Data.SqlClient.MetaType.GetSqlDataType(Int32 tdsType, UInt32 userType, Int32 length)
       at System.Data.SqlClient.TdsParser.CommonProcessMetaData(TdsParserStateObject stateObj, _SqlMetaData col)
       at System.Data.SqlClient.TdsParser.ProcessMetaData(Int32 cColumns, TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
       at System.Data.SqlClient.SqlDataReader.get_MetaData()
       at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
       at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
       at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
       at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
       at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
       at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)

    Friday, August 18, 2006 9:00 AM

Answers

  • Hi folks,

    Thanks for the replies.

    This code has been working fine for months and stopped when I put a change in - a change NOT directly to do with the code in question. So that's the reason I haven't posted it here.

    If you're interested, this is what I was doing. The code I changed is to do with a static class used to make DB connections. I was experiencing connection pool starvation in our SQL2005 db. When I looked deeper, I noticed a bit of code that made a simple SELECT which returned a bunch of rows but then for each of those rows made another "get the details" SELECT. Because we're using a wrapper class for making stored proc calls, each of these calls was making a connection to the db. In such circumstances I would have expected SQL to reuse the same connection from its pool but apparently not. The fact that the SqlConnection was being left to the garbage collector and not disconnected and disposed properly is another story.

    So to cut a long story short, I added some code to allow a given thread to reuse the SqlConnection it already has used before. I'm choosing/reusing/removing DB connections from a list that is keyed on the ManagedThreadID of the current thread (System.Threading.Thread.CurrentThread.ManagedThreadID). After putting this code in, the problems started. The error in this forum thread is just one of the wierdos I've seen. Debugging things has generated a whole new set of random errors in code that would normally function perfectly.

    So, basically, from Bill's response above I think I just f'**d up somewhere and, although the code is thread-safe, multiple threads are corrupting something somewhere. Maybe I'm misunderstanding the role of the ManagedThreadID and that's causing the problems. Anyhow, it's my problem and I think I'd better go away now and get it fixed.

    Thanks again for the prompt replies.

    ~swg

     

    Tuesday, August 22, 2006 8:46 AM

All replies

  • Hi,

    Can you post the complete code on how you are constructing the parameter?

    Thought the below link would be useful to you. Just go through and see if you had missed anything in your code.

    http://www.codeproject.com/cs/database/ImageSaveInDataBase.asp

    Regards

    Arvind T N

     

    Friday, August 18, 2006 9:53 AM
  • The error msg is a little bit misleading. It actually refers to the TDS type, which is different from SqlDbType.

    It seems the data received got corrupted.

    It would be more helpful if you could give the detailed server/client configuration and source code.

    Saturday, August 19, 2006 4:41 AM
  • Hi folks,

    Thanks for the replies.

    This code has been working fine for months and stopped when I put a change in - a change NOT directly to do with the code in question. So that's the reason I haven't posted it here.

    If you're interested, this is what I was doing. The code I changed is to do with a static class used to make DB connections. I was experiencing connection pool starvation in our SQL2005 db. When I looked deeper, I noticed a bit of code that made a simple SELECT which returned a bunch of rows but then for each of those rows made another "get the details" SELECT. Because we're using a wrapper class for making stored proc calls, each of these calls was making a connection to the db. In such circumstances I would have expected SQL to reuse the same connection from its pool but apparently not. The fact that the SqlConnection was being left to the garbage collector and not disconnected and disposed properly is another story.

    So to cut a long story short, I added some code to allow a given thread to reuse the SqlConnection it already has used before. I'm choosing/reusing/removing DB connections from a list that is keyed on the ManagedThreadID of the current thread (System.Threading.Thread.CurrentThread.ManagedThreadID). After putting this code in, the problems started. The error in this forum thread is just one of the wierdos I've seen. Debugging things has generated a whole new set of random errors in code that would normally function perfectly.

    So, basically, from Bill's response above I think I just f'**d up somewhere and, although the code is thread-safe, multiple threads are corrupting something somewhere. Maybe I'm misunderstanding the role of the ManagedThreadID and that's causing the problems. Anyhow, it's my problem and I think I'd better go away now and get it fixed.

    Thanks again for the prompt replies.

    ~swg

     

    Tuesday, August 22, 2006 8:46 AM
  • Hi Can you tell me how you solved this issue
    Honne
    Wednesday, March 18, 2009 6:26 PM