2009-04-02 9 views
7

Sto tentando di inserire un record in una tabella in un'installazione di database a 3 livelli e il server di livello intermedio genera il messaggio di errore sopra riportato come eccezione OLE quando tenta di aggiungere il primo parametro alla query.Delphi: "L'oggetto parametro è stato definito in modo errato. Sono state fornite informazioni incomplete o incomplete."

Ho cercato su Google questo errore, e trovo lo stesso risultato in modo coerente: proviene dall'avere i due punti in una stringa da qualche parte nella query, che esegue il parser SQL di ADO. Questo non è il caso qui. Non ci sono colon spuri da nessuna parte. Ho controllato e ricontrollato la definizione dell'oggetto rispetto allo schema per la tabella che sto cercando di inserire. Tutto si verifica, e questo ha bloccato i miei colleghi. Qualcuno sa che altro potrebbe causare questo? Sono alla fine dei miei spiriti qui.

sto usando Delphi 2007 e SQL Server 2005.

+0

@Mason - Stai utilizzando i parametri? In caso contrario, settare ParamCheck: = False help? –

+0

Sto usando i parametri. –

risposta

0

Se ricordo bene, è necessario esplicito valore NULL put al parametro. Se si utilizza un componente TAdoStoredProc, è necessario farlo in fase di progettazione.

0

Si sta utilizzando una filettatura? Mi sembra di ricordare di aver ricevuto questo errore quando un evento del timer ha avviato una query mentre la connessione ADO veniva utilizzata per un'altra query sincrona. (Il timer stava controllando un flag "sistema disponibile" ogni minuto).

0

Avete impostato il DataType del parametro o l'avete lasciato come ftUnknown?

+0

Il tipo di dati è stato impostato. –

4

È possibile ottenere questo errore utilizzando Delphi 2007 e MSSQL Server 2008 e ho trovato una soluzione alternativa. (. Che è piuttosto scadente IMHO, ma forse il suo utile a voi se il vostro è causata dalla stessa cosa)

codice per produrre l'errore:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode').Value := 1; 

    Open; // <<<<< I get the "parameter object is...etc. error here. 

finally 
    Free; 
end; 

ho trovato due modi per risolvere il problema:

1) rimuovere le staffe dallo SQL, ossia:

SQL.Text := ' SELECT * FROM Stock WHERE InvCode = :InvCode ' 
       +' SELECT * FROM Stock WHERE InvCode = :InvCode '; 

2) utilizzare due parametri invece di uno:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode1) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode2) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode1').Value := 1; 
    Parameters.ParamByName('InvCode2').Value := 1; 

    Open; // <<<<< no error now. 

finally 
    Free; 
end; 
2

Ecco una risposta tardiva. Nel mio caso era qualcosa di completamente diverso.

Ho provato ad aggiungere una procedura memorizzata al database.

Query.SQL.Text := 
'create procedure [dbo].[test]' + #13#10 + 
'@param int ' + #13#10 + 
'as' + #13#10 + 
'-- For the parameter you can pick two values:' + #13#10 + 
'-- 1: Value one' + #13#10 + 
'-- 2: Value two'; 

Quando ho rimosso i due punti (:) ha funzionato. Come ha visto il colon come parametro.

1

Sono di fronte allo stesso errore descritto nella domanda. Ho rintracciato l'errore in ADODB.pas ->procedure TParameters.AppendParameters; ParameterCollection.Append(Items[I].ParameterObject).
Utilizzando breakppoints, l'errore è stato generato nel mio caso da un parametro che dovrebbe riempire un campo DateTime nel database e non ho mai riempito il parametro. impostando il parametro(). value: = '' risolto il problema (ho provato anche con varnull, ma c'è un problema - invece di inviare Null nel database, la query sta inviando 1 - il valore intero di varnull).

PS: so che è una risposta 'late late late', ma forse qualcuno raggiungerà lo stesso errore.

+0

Ho avuto un problema simile, ma l'ho ricevuto inviando NULL (se la mia risposta) – BennyBechDk

+0

Sto avendo lo stesso problema in questo momento, che a volte capita, a volte no, e sono anche riuscito a rintracciarlo in TParameters.AppendParameters. Ho notato che il parametro che stava causando il problema è stato assegnato il valore NULL. Cambiarlo in Non assegnato sembra aver risolto il problema. Ma ciò che veramente mi infastidisce è il fatto che a volte l'errore si verifica solo. –

0

Ho anche avuto lo stesso problema, ma con un comando dinamico (ad esempio una dichiarazione di aggiornamento).
Alcuni dei parametri potrebbero essere NULL.
L'unico modo per farlo funzionare era impostare il parametro.DataType: = ftString e parameter.Size: = 1 e senza impostare il valore.

cmdUpdate := TADOCommand.Create(Self); 
try 
    cmdUpdate.Connection := '**Conections String**'; 
    cmdUpdate.CommandText := 'UPDATE xx SET yy = :Param1 WHERE zz = :Param2'; 
    cmdUpdate.Parameters.ParamByName('Param2').Value := WhereClause; 
    if VarIsNull(SetValue) then 
    begin 
    cmdUpdate.Parameters.ParamByName('Param1').DataType := ftString; 
    cmdUpdate.Parameters.ParamByName('Param1').Size := 1; 
    end else cmdUpdate.Parameters.ParamByName('Param1').Value := SetValue; 
    cmdUpdate.Execute; 
finally 
    cmdUpdate.Free; 
end; 
3

Ho trovato questo thread durante la ricerca del messaggio di eccezione precedentemente menzionato. Nel mio caso, la causa era un tentativo di incorporare un commento SQL/* foo */nel mio query.sql.text.

(ho pensato che sarebbe stato utile per vedere un commento oltrepassare galleggia nella mia finestra profiler.)

Comunque - Delphi7 odiato quello.

+0

Lo stesso per me, in Delphi 2010. Stavo aggiungendo un commento "- foo", però. –

0

Ho appena eseguito questo errore oggi su una TADOQuery che ha ParamCheck := False e non ha due punti nell'SQL.

In qualche modo passando il parametro OLECMDEXECOPT_DODEFAULT a TWebBrowser.ExecWB() stava causando questo per me:

Questo mostra il problema:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DODEFAULT, pvaIn, pvaOut); 

Questo non mostra il problema:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DONTPROMPTUSER, pvaIn, pvaOut); 
0

Una singola virgoletta nella query può anche sollevare questo errore da quello che ho appena vissuto e io non sono canta tutti i parametri ...

1

Ho appena riscontrato questo errore. Sto usando Delphi 7 per scrivere su un database MS Access 2003 usando un componente TAdoQuery. (vecchio codice) La mia query ha funzionato bene direttamente in MS Access, ma fallisce in Delphi attraverso l'oggetto TAdoQuery. Il mio errore proviene da due punti (scuse per il poster originale) da un valore di data/ora.

A quanto ho capito, il formato data/ora Jet SQL è # mm/gg/aaaa hh: nn: ss # (non è richiesto il riempimento a sinistra 0).

Se la proprietà TAdoQuery.ParamCheck è True, questo formato ha esito negativo. (Grazie poster!) Due soluzioni sono: a) impostare ParamCheck su False, oppure b) utilizzare un formato di data/ora diverso, vale a dire "mm/gg/aaaa hh: nn: ss" (con le virgolette doppie).

Ho testato entrambe le opzioni e hanno funzionato entrambe.

Anche se il formato data/ora a doppia virgola non è il formato data/ora Jet, Access è abbastanza buono per essere flessibile su questi formati di data/ora. Sospetto anche che abbia qualcosa a che fare con il formato data/ora di BDE/LocalSQL/Paradox (Delphi 7 SQL nativo e motore di database) (usa le virgolette doppie, come sopra). Il parser è probabilmente progettato per ignorare le stringhe tra virgolette (le virgolette doppie sono il delimitatore del valore stringa in BDE LocalSQL), ma potrebbe incappare in qualche modo su altri formati data/ora non nativi.

SQL Server utilizza le virgolette singole per delimitare le stringhe, in modo che funzioni invece di virgolette doppie quando si scrive su tabelle di SQL Server (non testato). O forse l'oggetto Delphi TAdoQuery continuerà a inciampare. Disattivare ParamCheck in quel caso potrebbe essere l'unica opzione. Se si prevede di attivare il valore della proprietà ParamCheck nel codice, si risparmia tempo di elaborazione assicurando che la proprietà SQL sia vuota prima di abilitarlo, se non si sta pianificando l'analisi dell'SQL corrente.

0

È possibile ottenere questo errore quando si tenta di utilizzare un valore temporale nell'SQL e si dimentica di inserirlo con QuotedStr().

0

Ho ricevuto lo stesso errore. È venuto fuori che è perché un parametro della stored procedure è stato dichiarato come varchar (max). Lo ha reso varchar (4000) e l'errore è scomparso.

Problemi correlati