Exception opening TAdoDataset: Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another

I've been trying to debug the following problem for several weeks now - this method is called from several places within the same datamodule, but this exception (from the subject line of this post) only occurs when integers for a certain purpose (pickup orders vs. orders that we ship through a carrier) are used - and don't ask me how the application can tell the difference between one integer's purpose and another! Furthermore, I cannot duplicate this issue on my machine - the error occurs on a warehouse machine but not my own development machine, even when working with the same production database. I have suspected an MDAC version conflict between the two machines, but have run a version checker and confirmed that both machines are running 2.8, and additionally have confirmed this by logging the TAdoDataset's .Version property at runtime.

function TdmESShip.SecondaryID(const PrimaryID : Integer ): String;
begin
    try
      with qESPackage2 do
        begin
          if Active then
              Close;
          LogMessage('-----------------------------------');
          LogMessage('Version: ' + FConnection.Version);
          LogMessage('DB Info: ' + FConnection.Properties['Initial Catalog'].Value + ' ' +      FConnection.Properties['Data Source'].Value);
          LogMessage('Setting the parameter.');
          Parameters.ParamByName('ParameterName').Value := PrimaryID;
          LogMessage('Done setting the parameter.');
        Open;

Ninety-nine times out of 100 this logging code logs a successful operation as follows:

Setting the parameter.

Done setting the parameter.

Opened the dataset.

DB Info: (database name and instance)

Setting the parameter.

Done setting the parameter.

GetESPackageID() threw an exception. Type: EOleException, Message: Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another Error: Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another for packageID 10813711

select ValueA from TableName where ValueB = @ParameterB

I'm about ready to do something extreme, such as writing a web service to look these values up - it feels right now as though I could destroy my machine, rebuild it, rewrite this entire application from scratch, and the application would still know to throw an exception whenever I try to look up a secondary value from a primary value, but only for pickup orders, and only from the one machine in the warehouse, but I'm probably missing something simple. So, any help anyone could provide would开发者_开发问答 be greatly appreciated.

Searching CodeGear/Embarcadero newsgroups I was only able to find that error related to setting/using the Filter property. I would search the project looking for anything setting the component's Filter property and check if the component is bound to any UI controls that could indirectly set the filter property (ex. DevExpress's TcxGrid, Infopower's Filter dialog, etc)

Another suggestion is to wrap opening of the dataset in a disable/enablecontrols. If the dataset is bound to a UI control, the control should not attempt to apply any actions (applying a filter) that could cause an exception.

function TdmESShip.GetESPackageID(const PackageID : Integer): String;
var
  ESPackageID :string; // for debugging
begin
  with qESPackage do
      begin
         ESPackageID := '';
         DisableControls();
         try
            try
               Parameters.ParamByName('PackageID').Value := PackageID;
               Open();
               if NOT(IsEmpty()) then
                 begin
                    ESPackageID := qESPackageESPackageID.AsString;
                 end;
               Close();  // No need to keep open
            except
               on E:Exception do
                  begin
                     ESPackageID := '9999999'; // ex. return a known bogus value
                     // log the error, re-raise a more meaningful error, etc
                  end;
               end;
         finally
            EnableControls();
            Result := ESPackageID;
         end;
     end;
end;

Good luck

You need to determine whether the error is coming from your application, or the underlying database. Write a small executable that does nothing but execute the literal SQL command (with the parameter value hard-coded into the SQL) and see if that will run on the work station that's giving you the problem.

I find that ADO returns a message about a parameter not having a default value when I send a command with a bad column name to MS Access. The error message is not especially helpful in that context. To debug this kind of error I log the actual SQL that's getting sent to the database and then cut and paste it into Access or some other console-type routine to see whether the SQL itself is at fault.

I had a similar issue with ADO + MySQL under Delphi 2009. The problem was with a TDateTime field which was required (NOT NULL) as per the table rules. MySQL accept the dummy date '0000-00-00 00:00:00' as a non-null value and ADO does not recognise this date/time value. The error returned was similar to yours (IIRC it was speaking about out of range value).

It's not the same thing as what's you are experiencing, but it might help you track the problem you have.

Good luck!

I have also faced the same problem when using MySql with ODBC driver in Delphi XE. The error pops up from InternalRefresh of the dataset. I have created a workaround, when ever we create a new connection object and apply to the query object, the error does not come. Try creating new connection object and check. I haven't checked much about this behavior, but it has solved the problem for me.

For reference, my query was

INSERT INTO USERS (UserId, Password, Created_at) Values (:UID, :PWD, :CAT)

When ever i assign this statement to the query object (TADOQuery), i get the same error, but with a new connection it works.

Hope this might help.

I had a similar problem and verify that the error was inside de data, there was #0 inside de data making a corrupted data.