Discussion :

[lucas-18]

Bonjour,

J'ai un problème de relation avec 2 tables.

J'ai une table "tbl_customer" et une autre table "tbl_detail" reliées par le champ customer (clé primaire).

J'ai mon formulaire principal basé sur ma table "tbl_customer"et j'aimerais inséré un sous-formulaire basé sur la table "tbl_detail".

Le problème c'est que je ne veux qu''il n'y ait qu'un enregistrement de ma table "tbl_detail" qui contienne le champ customer.

J'ai donc crée une relation de 1 à 1 entre ses 2 tables mais comment faire pour que le sous-formulaire basé sur la table "tbl_detail" ne puisse contenir qu'un enregistrement par customer et ainsi ne pas avoir le message access qui signale un duplicat ???

PS : j'ai évidemment pensé à regrouper tous les champs dans une même table (ca m'aurait simplifié la vie) mais je dois importer ma table "tbl_customer" quotidiennement de Business Objects et seulement les champs contenus dans ma table "tbl_customer". Bref ca sera beaucoup plus simple pour l'import et j'ai aussi pensé à créé une requête mais j'aimerais pas pour ne pas devoir modifier une bonne partie de ma base.

Merci de votre aide

[Pierre Fauconnier]

Bonsoir

Je ne vois qu'une possibilité via VBA. Il s'agit de gérer l'erreur générée sur le formulaire lors de l'ajout d'une ligne de détails, par exemple avec ce code, à placer dans le module du formulaire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Private Sub Form_Error(DataErr As Integer, Response As Integer)
    Select Case DataErr
        Case 3022
            Response = acDataErrContinue
            Undo
    End Select
End Sub

[lucas-18]

Merci Pierre Fauconnier ; en effet cela bloque bien l'erreur mais j'aimerais aller plus loin et pouvoir bloquer l'ajout d'en second enregistrement et son affichage biensûr.

[Pierre Fauconnier]

Tu peux interdire l'ajout d'enregistrement dans le formulaire-source du sous-formulaire...

Quitte à prévoir de basculer la propriété lorsque tu dois vraiment introduire des détails...

Par code, on peut aussi tester si des détails sont présents. Si oui, on interdit l'ajout, si non, on autorise l'ajout...

A toi de voir ce qui peut te convenir.

[lucas-18]

Tu peux interdire l'ajout d'enregistrement dans le formulaire-source du sous-formulaire...

Quitte à prévoir de basculer la propriété lorsque tu dois vraiment introduire des détails...

Par code, on peut aussi tester si des détails sont présents. Si oui, on interdit l'ajout, si non, on autorise l'ajout...

A toi de voir ce qui peut te convenir.

Ok, pourrais-tu stp me donner un code en exemple ?

[Pierre Fauconnier]

Dans un module standard, tu places la fonction suivante, qui renvoie le nombre d'enregistrements de la table des détails qui concernent le customer passé en référence. J'ai considéré que tes clés primaires étaient textuelles. Tu devras adapter le code si ce n'est pas le cas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Function DetailsExistent(Customer As String) As Long
    Dim sql As String
 
    sql = "select count(customer) as Nombre from tbl_details where customer='" & Customer & "'"
    DetailsExistent = CurrentProject.Connection.Execute(sql)!nombre
End Function

Dans le module du formulaire parent, tu testes si des détails existent lorsque tu passes d'un customer à l'autre, et lorsque tu enregistre un nouveau customer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Private Sub Form_AfterUpdate()
        If Not IsNull(Customer.Value) Then
            Form_fDetails.AllowAdditions = (DetailsExistent(Customer.Value) = 0)
            Me.Refresh
        End If
End Sub
 
Private Sub Form_Current()
        If Not IsNull(Customer.Value) Then
            Form_fDetails.AllowAdditions = (DetailsExistent(Customer.Value) = 0)
            Me.Refresh
        End If
End Sub

Dans le formulaire qui sert de sous-formulaire, tu bascules la propriété "AllowAdditions" lorsque tu souhaites parcourir les éléments.
Private Sub Form_Current()
Me.AllowAdditions = (DetailsExistent(Customer.Value) = 0)
End Sub

Il y a peut-être plus simple, mais j'ai fait vite.

[lucas-18]

merci

pourrais-tu me dire à quoi correspond "DetailsExistent" ?

[Pierre Fauconnier]

C'est la fonction qui dénombrent les enregistrements de la table Détails en fonction du customer passé en référence. Je t'ai donné le code dans mon précédent message. Cette fonction doit être placée dans un module standard

[lucas-18]

ok ; donc si ma table se nomme tbl_details, je mets tbl_detailsExistent ?

[Pierre Fauconnier]

Non, tu l'utilises telle quelle. C'est dans le code de la fonction que tu dois éventuellement adapter, bien qu'il me semble que j'ai utilisé les noms de tables que tu donnais dans ton premier exemple...

[lucas-18]

Merci cela a l'air de marcher, j'dois encore vérifier mais ca a l'air bon ; merci beaucoup

[lucas-18]

Et bien non il y a un problème ; lorsque j'utilise les boutons de déplacement de mon formulaire principal, j'ai un message d'erreur :

Run-Time error '94':

Invalid use of Null

C'est sur ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Private Sub Form_Current()
Me.AllowAdditions = (DetailsExistent(Customer.Value) = 0)
End Sub

[Pierre Fauconnier]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not isnull(customer.value) then Me.AllowAdditions = (DetailsExistent(Customer.Value) = 0)

Cela étant, je reviens sur la conception en elle-même.

Avoir deux tables liées avec une relation 1:1 n'est que rarement une bonne solution.

Il me semblerait plus judicieux de prévoir une seule table, et de réfléchir aux possibilités de mise à jour des données de Business Object, via éventuellement une table temporaire ou n'importe quel système. Cela ferait beaucoup moins "bricolage"

[lucas-18]

Ca a l'air de marcher merci

si ca marche je prends cette solution, l'import BO sera plus facile et on m'a tjs dit une table doit contenir le moins de champ possible ...

merci beaucoup en tout cas de ta disponibilité ; je remercie par ailleurs les autres modérateurs et membres ; grâce à vous ma databse est quasi finie !

[Pierre Fauconnier]

...on m'a tjs dit une table doit contenir le moins de champ possible ...

Une table doit contenir les champs nécessaires à la définition des données stockées dans la table...

[f-leb]

bonsoir,

je souhaiterais rebondir sur:

...Avoir deux tables liées avec une relation 1:1 n'est que rarement une bonne solution.
....

Au niveau sécurité, est-ce que:

tbl_Customer-1---------1-tbl_DetailCustomer

est pertinent si tbl_DetailCustomer comprend des données sensibles à cacher à l'utilisateur Lambda comme MotDePasse, N°CompteBancaire,... ?

[Pierre Fauconnier]

Salut f-leb,



Pour moi, non, tout du moins dans une table Access non sécurisée, car l'accès aux données ne pose pas de problèmes majeurs. De plus, Access impose la lecture/écriture sur le dossier qui contient la base, ce qui permet évidemment d'accéder aux données, via le frontal ou via une autre technique (msquery, attaque directe, ...).

Avec une base < 2007 munie d'une sécurité via mdw, on peut mettre en place une sécurité, mais c'est déjà un peu complexe de mettre une sécurité bien pensée en place.

Sur du SQL Server, cela devient possible, mais je crois savoir qu'il n'est pas trivial de mettre en place une sécurité sur la base, et qu'il faut évidemment en tenir compte dans la mise en place de l'IHM.

Je précise de suite que je ne suis pas un as de la sécurité, loin de là.

[f-leb]

bonsoir Pierre,

je me disais intuitivement qu'il serait justement plus facile de "cacher" une table entière tbl_DetailCustomer plutôt que d'essayer de "cacher" certaines colonnes sensibles de la table tbl_Customer (d'où l'idée de déporter des données sensibles dans une autre table en asso. 1-1).

Néanmoins, je suis plutôt "charrette" concernant les pb de sécurité donc je dis peut-être n'importe quoi. J'irais faire un tour dans le s/forum Sécurité.

merci de ta réponse.

[Pierre Fauconnier]

Si c'est pour cacher les données dans l'IHM (formulaires, états), je ne vois pas trop en quoi il est plus aisé de cacher une table entière.

On peut très bien mettre en place un formulaire père basé sur une table X et un sous-formulaire basé sur la même table pour afficher certains champs au sein du sous-formulaire (qui serait affichable ou non par VBA selon les droits de l'utilisateur), et on n'est donc pas obligé de passer par une deuxième table, au niveau de l'IHM.

Mais comme je l'ai dit, cela n'empêche nullement d'attaquer la base par un autre outil, et donc d'accéder aux données, sauf si celles-ci sont sécurisées (en Access via un MDW, ou en MSSQL en gérant la sécurité et les accès par utilisateur). Dans le cas d'un accès sécurisé, comme je pense qu'il n'est pas possible de restreindre l'accès à certains champs d'une même table, ta remarque prend tout son sens car il sera alors judicieux d'isoler les données sensibles dans une table à part, liée en 1:1 avec la table "publique". Il faut alors aussi prévoir que les requêtes/vues suivent le même schéma sécuritaire.

J'espère n'avoir pas dit trop de c*** sur ce sujet que je maîtrise relativement peu...