alerte entre date de tables différentes [Résolu]

[nabou69]

Bonjour,

Je souhaite poser une alerte pour éviter à une date de décès d'être antérieure à une date de naissance.

En bref, mes tables d'utilité:
- Table patient avec pour champs: identifiant patient(idp=CP), date de naissance
- Table déces: identifiant patient (idp=CP), date de décès.
Je souhaiterai instaurer une alerte si la date de décès est antérieure à la date de naissance.
En utilisant le code comme suite:
if datedeces <dlookup ("datenaissance","Tpatient","idp=" & me.idp)then
cancel=true
end if

J'obtiens une erreur d'exécution ciblée sur idp donc j'ai essayé en supprimant ce champ:

Code :

1
2
3
if datedeces <dlookup ("datenaissance","Tpatient")then
cancel=true
end if

là, ça marche mais que pour le premier enregistrement (=1ier patient); dès que je passe au 2ième enregistrement, le contrôle ne fonctionne plus et idem pour les autres enregistrements?

Il faut également savoir que l'identifiant du patient n'est saisie que dans la table patient puisque à l'ouverture de la table deces, l'identifiant patient s'inscrit automatiquement.

Par ailleurs, chaque table contient beaucoup d'autres champs et il n'est pas envisagé de regrouper date de naissance et date de décès sur la même table.

Pouvez vous m'aider car je ne sais pas d'où peut provenir ce problème malgré mes nombreuses recherches net.
Merci beaucoup

[f-leb]

bonjour,

si l'identifiant est de type alphanumérique, il faut déjà mettre des guillemets:

Code :

1
2
if datedeces <dlookup ("datenaissance","Tpatient","idp='" & me.idp & "'")then
cancel=true

[alassanediakite]

Salut à tous et à toutes
J'ai pas bien compris ça:

Il faut également savoir que l'identifiant du patient n'est saisie que dans la table patient puisque à l'ouverture de la table décès, l'identifiant patient s'inscrit automatiquement.

1. nabou, dis nous ce que dit l'erreur. Le problème est peut-être dû au fait que "idp" est vide (null).
2. f-leb, n'est-il pas mieux qu'elle fasse une seule table. En ce cas le "dlookup" ne sera plus utile il suffit de mettre
   
   Code :

   1
   2
   3
   if datedeces <datenaissance then
   cancel=true
   end if

@+

[nabou69]

Merci à vous 2 pour vos réponses.
Merci ++++ à f-leb car ça marche capitaine!!!

[f-leb]

Je me permets de répondre quand même à l’ami Alassane.

Toi qui t’intéresses à Merise, tu dois avoir eu écho de ses extensions (Merise 2) avec la spécialisation/généralisation (ou structure à héritage).

Au niveau du MCD, Nabou69 doit avoir un truc du genre :

Patient <--------------PatientDecede

qui au niveau physique nous donnera sous Access :
TPatient-1-------1-TPatientDecede
TPatient(idp, Nom, Prenom, DateNaissance, …)
TPatientDecede(#idp, DateDeces, MotifDeces, …)

Envoyé par nabou69

Il faut également savoir que l'identifiant du patient n'est saisie que dans la table patient puisque à l'ouverture de la table décès, l'identifiant patient s'inscrit automatiquement.

TPatient.idP est par exemple un numéroAuto.
TPatientDecede.idp est à la fois clé primaire et clé étrangère référençant T.Patient.idP.

Peut-être que nabou69 en cas de décès active un sous-formulaire sur la table TPatientDecede avec liaison au formulaire principal sur le champ idP. Dans ce cas, la clé étrangère se remplirait toute seule.

Envoyé par alassanediakite

f-leb, n'est-il pas mieux qu'elle fasse une seule table.

Certains traitements au niveau de l’IHM en seraient facilités mais d’un autre côté…

Envoyé par nabou69

Par ailleurs, chaque table contient beaucoup d'autres champs…

TPatientDecede(#idp, DateDeces, MotifDeces, …etc avec beaucoup d’autres champs)

Si tout ce petit monde figure dans la même table, DateDeces, MotifDeces et apparemment beaucoup d’autres champs resteraient vides (à Null) pour les patients qui ne sont pas décédés et cela peut poser des problèmes au niveau physique si la table devient volumineuse.

L’emplacement mémoire est réservé dans le fichier Access même si le champ est vide (sauf pour les champs Texte et Memo je crois).
Si Nabou69 gère les patients d’un hôpital ou d’une clinique, j’ose espérer que ses patients décédés sont minoritaires. Par exemple avec 10000 patients dont 500 sont décédés, tu auras 9500 fois le champ DateDeces à Null, soit un surpoids de 9500x8octets=74Ko. Rien qu’avec le champ DateDeces.

Imaginons pour se faire une idée que les champs concernant les patients décédés occupent 30 octets par patient (8 octets par champ Date, 4 octets par champ entier long, etc…).
Avec 9500 patients encore en vie, ce seront 9500x30octets=278Ko théoriques de surpoids. La table des patients devient un gruyère obèse en plus de ressembler à une feuille Excel (j’ai rien contre les feuilles Excel mais pas dans les bases Access).

Il y a peut-être un mécanisme spécial mais je me demande si en Frontale/dorsale ces 278Ko supplémentaires et inutiles ne devront quand même pas transiter dans les tuyaux du réseau.
Auquel cas, il est toujours mieux au niveau des performances de fragmenter une table en tables plus petites.

On trouve d’autres avantages à la séparation des patients dans deux tables, par exemples :

- Comment s’assurer qu’un patient décédé ait bien sa DateDeces obligatoirement renseignée ?
Avec une 2ème table TPatientDecede, facile. Je mets la propriété du champ "Null autorisé" à "Non".
Je ne peux mettre cette contrainte si la DateDeces figure dans la table ou sont présents également les patients encore en vie ( à moins de mettre une date de décès bidon pour les vivants mais là encore ce genre de bricolage n’est pas toujours sans conséquence).


- Comment compter le nombre de patients décédés ?
Avec la 2ème table TPatientDecede, facile.

Code sql :

SELECT Count(*) FROM TPatientDecede;

En frontal/dorsal, la requête ne portera que sur la table TPatientDecede soient 500 lignes envoyés dans les tuyaux.

Avec une seule table TPatient, pas plus compliqué, un truc du genre :

Code sql :

SELECT count(*) FROM TPatient WHERE EstDecede=true

Par contre en frontal/dorsal, ce sont les 10000 patients qui vont partir dans les tuyaux (dont 278Ko de valeurs bêtement à Null).


- On sait aussi que certaines requêtes avec des tables pourtant bien indexées verront leurs performances plombées du fait que la présence de Null est autorisée (il y a un article sur le support Microsoft qui en parle, si j’arrive à le retrouver…)



A noter que j’écris tout ça au conditionnel, basé aussi sur ce qu’on peut lire à gauche et à droite dans d’autres forums de Dvp mais que je n’ai jamais réalisé d’étude comparative des performances avec les deux possibilités avec 1 ou 2 tables sur Access. Cela pourrait être une étude intéressante à faire.
De toute façon les avantages de séparer en 2 tables sur les performances ne se font sentir qu’à partir d’une certaine volumétrie de données donc à chacun de voir selon …

Bonne continuation…

[nabou69]

En effet, il n'était pas envisageable de réunir les 2 tables pour les raisons que vous expliquez: le nombre de patient à saisir sera effectivement conséquent ce qui aurait engendré un certain nombre de contraintes.
Même si c'était pour répondre à Alassane (que je remercie également), merci pour vos remarques pertinentes et pour votre implication!

[alassanediakite]

Salut
Merci f-leb. J'ai été confronté à ce problème avec une table "client" d'une caisse d'épargne. J'ai divisé (verticalement) la table en trois tables.
En fait j'ai lu de travers, mais je ne mérite pas d'excuses

Par contre, d'après ce code...

Envoyé par f-leb

bonjour,
si l'identifiant est de type alphanumérique, il faut déjà mettre des guillemets:

Code :

...je pense que le type de idp dans Tpatient n'est pas NumeroAuto!
Par ailleurs, puisqu'on a un formulaire avec sous-formulaire (avec TPatient-1-------1-TPatientDecede), je pense que...

Code :

1
2
if datedeces <Me.parent!datenaissance then
cancel=true

[/QUOTE]
... est plus optimisé.