Comments by ronschuster (Top 7 by date)

This seems highly unlikely. The customer has been running our application for years with no problem. They say this problem just showed up after upgrading to a new version. But nothing in the code we use to create this statement, or populate the parameter values has changed. The TADOQuery class has certainly not changed; we're still using the same version of the compiler and class library.

We absolutely ARE using parameters. You're missing a key point of the post. As I said in the post, twice: This is what the trace in SQL Server Profiler is showing. This is NOT the SQL we send. I also showed the actual SQL statement we're using. Parameters are represented by placeholders prefixed with a colon. We do not include the values in the SQL. They are passed as values in the parameter objects of the ADO component. I was trying to avoid posting actual Delphi code so that readers who do not know Delphi, but do understand SQL Server at a deep level, would be more likely to comment, but since you don't believe we're using parameters properly, I'll post it here.

...
    ADOQuery: TADOQuery;
...
procedure TForm26.FormShow(Sender: TObject);
begin
  // Set up the insert command
  ADOQuery.SQL.Text :=
    'INSERT INTO equip ' +
    '(ac_main_mccb_no,ac_sub_mccb_no,design_pressure,design_temp) ' +
    'VALUES (:ac_main_mccb_no,:ac_sub_mccb_no,:design_pressure,:design_temp)';
  ADOQuery.Parameters.ParamByName('ac_main_mccb_no').DataType := ftString;
  ADOQuery.Parameters.ParamByName('ac_sub_mccb_no').DataType := ftString;
  ADOQuery.Parameters.ParamByName('design_pressure').DataType := ftFloat;
  ADOQuery.Parameters.ParamByName('design_temp').DataType := ftFloat;
end;

procedure TForm26.Button1Click(Sender: TObject);
var
  DesignPres: Double;
begin
  // Compute a value to show that we don't format the value as a string
  DesignPres := 7 / 2;
  // Set the parameter values
  ADOQuery.Parameters.ParamByName('ac_main_mccb_no').Value := Null;
  ADOQuery.Parameters.ParamByName('ac_sub_mccb_no').Value := Null;
  ADOQuery.Parameters.ParamByName('design_pressure').Value := DesignPres;
  ADOQuery.Parameters.ParamByName('design_temp').Value := 380;
  // Execute insert command
  ADOQuery.ExecSQL
end;

and this is the trace of the execution of the command as I see it in SQL Server Profiler

exec sp_executesql N'INSERT INTO equip (ac_main_mccb_no,ac_sub_mccb_no,design_pressure,design_temp) VALUES (@P1,@P2,@P3,@P4)',N'@P1 varchar(50),@P2 varchar(50),@P3 float,@P4 float',NULL,NULL,3.5,380

Here we get the correct value for the parameter in the trace.

The parameter supply (I assume you mean the list of the actual values of the parameters) DOES look odd. That's kinda the whole problem. We just assign the numeric values to the parameter objects using their numeric values. We don't build that string. That is a function of SQL Server under the hood that I have no control over.