Invalid character value for cast specification.

Invalid character value for cast specification.

• Carl Beck

  Looks like my guess about the value of Scale was right. Glad you got it all working.
  
  

• Brent Russell

  I would use SQL Profiler and get a trace when the command runs and this might give you a clue as to the source of the error message. It almost sounds like the OleDb classes are adding a CAST statement to the resulting SQL statement. Get the incoming SQL and error message from SQL Profiler and post this back and we'll take a look.
  
  

• r2d2

  Hmmmm ... coupla questions.

  Why are you using OleDbParameter with SQL Server Using the corresponding Sql objects would be better (SqlParameter, SqlDataAdapter, etc.)

  Why do you set the parameter's scale to 4 when you say that the data type is numeric(18,0) and your value has no decimal places

  I don't know if either of these obversations make any difference or not, but I thought I'd point it out.

  
  
  

• Joe Webb

  I finally found the source of the problem.

  "Info_List[iParam].bScale" is returning a value of 18 instead of 0, so I stopped assigning it, and everything works fine now.

  I appreciate all the suggestions I got from this forum.

  
  
  

• Armored77

  My question is why are you using OleDb and not SqlClient which is designed to access SQL Server
  
  

• madhur

  Frankly, yes. OLE DB is (IMHO) flawed. It's slow, prone to COM issues and not nearly as well supported in .NET as "native" managed providers. When choosing a provider for a .NET database, choose a managed provider written specifically for the target DBMS first, then choose the fastest, most flexible OSFA (one-size-fits-all) provider you can find (Odbc) and at last resort choose OleDB. The OleDb interface is far slower than the SqlClient native interface--event he Odbc OSFA provider is 20% faster than OleDb.

  In my experience it's a wasted of time trying to create a generic application. Since the meat of the application depends on factors that aren't the same from DBMS to DBMS you end up writing a lot of IF this THEN that code and bypassing critical features of one DBMS because they aren't supported on other targetted platforms.

  But that's just my opinion.

  
  
  

• Coconut1

  Thanks for the quick reply.

  Since you are asking why I am using OLE DB instead of SqlClient, are you suggesting that OLE DB is flawed I chose to use OLE DB because I might need to deal with other data sources, later on. Remember also, that the whole procedure works with every column, except for Numeric and Decimal columns. It also works flawlessly on all columns, with code written in native C++

  Here is the actual code I used.

  Info_List[iParam] is a set of parameter info obtained, using ICommandWithParameters::GetParameterInfo(), from native C++.

  for (int iParam = 0; iParam < nParamsSize; iParam++)
  {
  OleDbParameter param = new OleDbParameter();
  param.Direction = ParameterDirection.Input;
  param.Scale = Info_List[iParam].bScale;
  param.OleDbType = (OleDbType)Info_List[iParam].wType;
  param.Size = (int)Info_List[iParam].ulParamSize;
  param.Precision = Info_List[iParam].bPrecision;
  param.ParameterName = Info_List[iParam].strName;
  string strValue = parametersArray[iParam];
  DB_SetParameterValue(ref param, param.OleDbType, strValue);
  m_Command.Parameters.Add(param);
  }

  
  
  

• Diogo Traldi de Oliveira

  I agree with you there, Bill.

  If I had an application that had the possibility of using two different backends, I would *not* use a generic DataAccess layer either. But, I don't think the OP wanted to hear that.

  
  
  

• Gary Bouchard

  See, Bill asked the same question as I did.

  Perhaps the ICommandWithParameters::GetParameterInfo() isn't getting you what you want. Since I know nothing about C++ or how you would use that command from a C# program to populate your Info_List collection, all I can suggest is that you carefully look at that Info_List collection ... I'm betting it's not correctly giving you what you need.

  
  
  

• Arbu

  Thanks for the quick reply.

  Since you are asking why I am using OLE DB instead of SqlClient, are you suggesting that OLE DB is flawed I chose to use OLE DB because I might need to deal with other data sources, later on. Remember also, that the whole procedure works with every column, except for Numeric and Decimal columns. It also works flawlessly on all columns, with code written in native C++

  Here is the actual code I used.

  Info_List[iParam] is a set of parameter info obtained, using ICommandWithParameters::GetParameterInfo(), from native C++.

  for (int iParam = 0; iParam < nParamsSize; iParam++)
  {
  OleDbParameter param = new OleDbParameter();
  param.Direction = ParameterDirection.Input;
  param.Scale = Info_List[iParam].bScale;
  param.OleDbType = (OleDbType)Info_List[iParam].wType;
  param.Size = (int)Info_List[iParam].ulParamSize;
  param.Precision = Info_List[iParam].bPrecision;
  param.ParameterName = Info_List[iParam].strName;
  string strValue = parametersArray[iParam];
  DB_SetParameterValue(ref param, param.OleDbType, strValue);
  m_Command.Parameters.Add(param);
  }

  
  
  
• Invalid character value for cast specification.