J'ai une table dans lequel j'ai une colonne de type "date".
Curieusement, quand j'écris cette ligne de code pour importation de la date sur tDateTime voilà le message d'erreur que je recois "Project Comptes.exe raised exception class EDateTime Error with message' You must be in ShowCheckbox mode to set to this date'. Process stopped. Use step or Run to continue".
Je comprends c'est juste parce qu'il rencontre quelques enregistrements vides. Mais pour certaines raisons; quelques enregistrements doivent forcement restés vides.
Et alors que faire pour eviter ce genre de message? Mais qu'il fasse quand même la lecture.
Je reponds à ma propre question.
Au lieu juste de "Date", j'ai mis "DateTime".
Curieusement, quand un champs est vide il mentionne une date étrange dans le TdateTime "30-12-1899". Que faire?
je viens de faire un test avec la table orders..
Après avoir viré une date, celle-ci n'est pas remplacée par "30-12-1899".
procedure TForm1.Button2Click(Sender: TObject);
begin
Query1.Locate('OrderNo', '1010', []);
if Query1SaleDate.text = '' then
ShowMessage('vide');
end;
et j'ai le message vide
En revanche, si tu vides les champs DateTime en mettant
leurs valeurs à 0, alors paradox les remplacent par
"30-12-1899" qui représente comme l'indique Mauricio, la valeur 0.
une bizarrerie de ce SGBD..
et le plus fort est que si tu testes la valeur 0 dans les champs "30-12-1899" ça marche !
c'est cohérent, mais pour l'esprit, pas facile à digérer..
en conclusion :
if (comptesAjour.FieldByName('date').AsString <> '') and
(comptesAjour.FieldByName('date').Value <> 0) then
laDate.Date:= comptesAjour.FieldByName('date').AsDate;
@Cantador: il y a pire! Dans les bases de données SQL, um champ de type STRING peut être vide ou Null!
C' est pareil pour un champ integer mais c' est plus cohérent: um champ avec la valeur 0 <> Null ...
Donc,
si tu fais
WHERE MonCHAMP = '' est diférent de MONCHAMP IS NULL
ou pour les champs integers:
WHERE MonCHAMP = 0 est diférent de MONCHAMP IS NULL
Effectivement, le fait qu'une date (type TDate) 0 soit différent de date null est tout à fait logique.
Il y a intérêt, puisque 0 est une date, de même que 1 ou -1 !
Attention, le type TDate n'est pas un entier (Integer).
C'est la partie entière (sans la partie décimale) d'un TDateTime qui est lui même un Double.
Enfin... sans partie décimale, c'est ce qui est dit dans l'aide.
Car en fait :
type TDate = type TDateTime;
et
type TDateTime = type Double;
Clairement, TDate est un Double, comme TDateTime, pas de confusion possible.
Pour enlever la partie décimale d'une TDate, il faudra passer par Trunc().
Petit test avec un Button et un Memo :
procedure TForm1.Button1Click(Sender: TObject);
var
aDate: TDate;
begin
Memo1.Clear;
aDate := Now;
Memo1.Lines.Add(FloatToStr(Trunc(aDate)));
Memo1.Lines.Add(FloatToStr(aDate));
Memo1.Lines.Add(DateToStr(aDate));
end;
On peut constater que la partie décimale n'est négligée qu'après passage par la fonction DateToStr.
