Newsgroup: it.comp.lang.delphi
Titolo: tipi di dati non corrispondenti nell'espressione criterio

Salve a tutti,
Mi sto imbattendo in questo errore e davvero mi sembra che non abbia
senso.
Uso un DB Access e Delphi 2010.
Devo fare un inserimento di record in una tabella di dettaglio ordini
ed ho problemi con il campo relativo al prezzo unitario che copio
dalla tabella articolo.
La definizione dei due campi nelle due tabelle � identico:
Numerico, Decimale, tipo Euro, con due decimali fissi
    DM.qOrderD.Insert;
    DM.qOrderDCodiceOrdine.Value   := OrderCode;
    DM.qOrderDCodiceArticolo.Value := DM.qDoOrderCodice.Value;
    DM.qOrderDItm.Value := Itm;
    DM.qOrderDUM.Value  := DM.qDoOrderUM.Value;
    DM.qOrderDQta.Value := Qta;
    DM.qOrderDPrezzoUnit.Value := DM.qDoOrderPrezzoUnit.Value;
    DM.qOrderDEvaso.Value := False;
 
DM.qOrderD.Post
;
Per alcuni articoli il codice funziona poi ne arriva uno (non so se �
l'unico e si pianta dando l'errore "tipi di dati non corrispondenti
nell'espressione criterio"
se commento il codice relativo al prezzo inserisco tutto e se poi
concludo la Procedure con
UPDATE tabOrdiniD INNER JOIN tabArticoli ON tabOrdiniD.CodiceArticolo
= tabArticoli.Codice SET tabOrdiniD.PrezzoUnit =
[tabArticoli].[PrezzoUnit]
mi trovo che la tabella risulta correttamente compilata.
La soluzione per� non mi piace e voglio capire dove sbaglio. Ma perch�
mi da quell'errore?
Nel caso specifico il prezzo � 0,04 �
In precedenza nel codice usavo
DM.qOrderD.InsertRecord( [ OrderCode, DM.qDoOrderCodice.Value, Itm,
    'NA', DM.qDoOrderUM.Value, Qta, nil, DM.qDoOrderPrezzoUnit.Value,
    False ] );
Con lo stesso errore.
Grazie
LUCA
MaHi

 nell'espressione criterio"
Sicuro che i 2 campi siano ESATTAMENTE UGUALI come definizione?
Se forzi il prezzo a 0.04 senza leggerlo dall'altra tabella cosa
succede?
A.

Di che tipo � il campo in questione?
Andrea 
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 4840 (20100205) __________
Il messaggio � stato controllato da ESET NOD32 Antivirus.
www.nod32.it

succede?
Se eseguo l'inserimento a mano da Access funziona, ma se modifico il
codice cos�:
    DM.qOrderDPrezzoUnit.Value := 0.04;
allora al momento della POST mi da errore subito al primo INSERT e non
inserisco un bel nulla.
Stavo proseguendo nel progetto ed ho lo stesso errore in un altro
campo : Decimale, Formato Euro, Precisione 18, Scala 2 (proprio come
quello del prezzo). 
Si tratta del campo dei costi di spedizione che dovrei imputare a mano
dopo aver generato in automatico mater e detail di cui sopra.
Ho una DBGrid che mostra tutte le testate degli ordini con la colonna
degli oneri di spedizione. Imputo a mano ad esempio 50 � e mi segnala
lo stesso errore del cavolo !??!?!?
Mmmm....
Luca
MaHi

 
ICQ# 156068277

 Nel caso specifico il prezzo � 0,04 ?


Io anche per i prezzi in access userei un campo stringa.


Io anche per i prezzi in access userei un campo stringa.
Interessante. Per quale motivo?

ciao giorgio
Grazie Giorgio.
Il problema si � risolto passando a VALUTA tutti i campi che
indicavano prezzi unitari, totali, etc


"Andrea Laforgia" <a...@andrealaforgia.it.invalid> ha scritto nel messaggio 
news:cmmqm59cvdum4q58o...@4ax.com...

Con access ho avuto parecchi problemi con campi valuta. Controllando a 
dovere l'imput utente su tali campi e memorizzando in campi stringa posso 
comunque gestire il tutto senza problemi anche con i vari CAST del caso.
E' solo per un discorso di "comodit�", il campo stringa � pi� flessibile. 
Idem per le date
Andrea 
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 4846 (20100208) __________


 Idem per le date
Non sono d'accordo. Va usato il tipo giusto. Per le date si usi il tipo
data e per le valute il tipo valuta. Personalmente non ho mai avuto
problemi.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


ok, idem per me sui db in genere. Tipo giusto per ogni dato.
Su Access per�, ora non ricordo con esattezza quali problemi avessi con i 
campi valuta (son passati diversi anni), ricordo che riuscii a risolvere 
convertendo il campo in stringa.
Ricordo per� che MDAC era la versione 2.7 credo, quindi non l'attuale 
distribuita da ms.
Per le date non saprei... molti miei colleghi usano stringa in formato 
yyyymmgg
Andrea 
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 4847 (20100208) __________


 yyyymmgg
Non ho mai capito perch� cos� tante persone reinventano la ruota. Io non
ho mai avuto problemi con i tipi giusti previsti col db. E se c'� un campo
data, perch� non usarlo? Bah.
