Delphi: "Parameter object is improperly defined. Inconsistent or incomplete information was provided."

13,061

Solution 1

I found this thread while searching the previously mentioned Exception message. In my case, the cause was an attempt to embed a SQL comment /* foo */ into my query.sql.text.

(I thought it would have been handy to see a comment go floating past in my profiler window.)

Anyhow - Delphi7 hated that one.

Solution 2

I just encountered this error myself. I'm using Delphi 7 to write to a 2003 MS Access database using a TAdoQuery component. (old code) My query worked fine directly in MS Access, but fails in Delphi through the TAdoQuery object. My error came from a colon (apologies to the original poster) from a date/time value.

As I understand it, Jet SQL date/time format is #mm/dd/yyyy hh:nn:ss# (0 left-padding is not required).

If the TAdoQuery.ParamCheck property is True then this format fails. (Thank you posters!) Two work-arounds are: a) set ParamCheck to False, or b) use a different date/time format, namely "mm/dd/yyyy hh:nn:ss" (WITH the double quotes).

I tested both of these options and they both worked.

Even though that double-quoted date/time format isn't the Jet date/time format, Access is pretty good at being flexible on these date/time formats. I also suspect it has something to do with the BDE/LocalSQL/Paradox (Delphi 7's native SQL and database engine) date/time format (uses double quotes, as above). The parser is probably designed to ignore quoted strings (double quotes are the string value delimiter in BDE LocalSQL), but may stumble somewhat on other non-native date/time formats.

SQL Server uses single quotes to delimit strings, so that might work instead of double quotes when writing to SQL Server tables (not tested). Or maybe the Delphi TAdoQuery object will still stumble. Turning off ParamCheck in that case may be the only option. If you plan to toggle the ParamCheck property value in code, you'll save some processing time by ensuring the SQL property is empty before enabling it, if you're not planning on parsing the current SQL.

Solution 3

I'm facing the same error described in your question. I've traced the error into ADODB.pas -> procedure TParameters.AppendParameters; ParameterCollection.Append(Items[I].ParameterObject).

By using breakpoints, the error was raised, in my case, by a parameter which should fill a DateTime field in the database and I've never filled up the parameter. Setting up the parameter().value:='' resolved the issue (I've tried also with varNull, but there is a problem - instead of sending Null in the database, query is sending 1 - the integer value of varNull).

PS: I know is a 'late late late' answer, but maybe somebody will reach at the same error.

Share:
13,061
Mason Wheeler
Author by

Mason Wheeler

A lifelong programmer who's been coding in Delphi since its initial release and currently makes a living at it.

Updated on June 20, 2022

Comments

  • Mason Wheeler
    Mason Wheeler almost 2 years

    I'm trying to insert a record into a table in a 3-tier database setup, and the middle-tier server generates the error message above as an OLE exception when it tries to add the first parameter to the query.

    I've Googled this error, and I find the same result consistently: it comes from having a colon in a string somewhere in your query, which b0rks ADO's SQL parser. This is not the case here. There are no spurious colons anywhere. I've checked and rechecked the object definition against the schema for the table I'm trying to insert into. Everything checks out, and this has my coworkers stumped. Does anyone know what else could be causing this? I'm at my wits' end here.

    I'm using Delphi 2007 and SQL Server 2005.

  • BennyBechDk
    BennyBechDk almost 13 years
    Had a problem like that, but got it sending NULL (se my answer)
  • Paolo M
    Paolo M over 10 years
    The same for me, in delphi 2010. I was adding a "-- foo" comment, though.
  • Bruno Santos
    Bruno Santos about 10 years
    I'm having the same problem right now, which sometimes happens, sometimes not, and I've also managed to trace it down to TParameters.AppendParameters. I noticed that the parameter that was causing the problem was being assigned the value NULL. Changing it to Unassigned seems to have fixed the problem. But what really bugs me is the fact that the error would only sometimes occur.
  • Remy Lebeau
    Remy Lebeau almost 3 years
    "I've tried also with varNull, but there is a problem - instead of sending Null in the database, query is sending 1 - the integer value of varNull" - you don't create a NULL Variant by literally assigning varNull itself to the Variant. You need to set the TVarData(Variant).VType field to varNull instead. You can do that manually, or you can simply assign the result of the Variants.Null() function to the Variant instead.