Discussion :

[star]

.
Comment insérer un nouvel enregistrement dans une table MySQL contenant un UUID en tant que clé primaire ?

Pour ce faire à partir des indications trouvées sur cette page web https://dev.mysql.com/blog-archive/s...-mysql-tables/, j'essaye d'obtenir un UUID de la base de données MySQL au moyen d'un ordre SELECT dans une requête Query1, mais Access m'affiche cette boite de dialogue de Warning :



Par contre, lorsque j'exécute la même requête dans un Shell MySQL, j'obtiens bien la réponse correcte :



Sauriez-vous comment procéder sous Access ?
.

[loufab]

Bonjour,

Si tu veux utiliser une syntaxe SQL propre à un moteur de base de données, tu dois soit utiliser ADO soit une requête Passthrough.

Cordialement,

[star]

.
Merci loufab pour tes indications.

J'ai donc procédé de la manière suivante :

Dans le module de classe de mon formulaire, j'ai écrit ce code dans la procédure évènementielle Form_BeforeUpdate() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
Private Sub Form_BeforeUpdate(Cancel As Integer)
 
    Debug.Print "Form_BeforeUpdate ForFicheReleve"
 
    Dim res As Integer
 
    Dim dbs As DAO.Database
    Dim rst As DAO.Recordset
 
    Dim strSQL As String
 
    On Error GoTo Form_BeforeUpdate_Err
 
    If Me.NewRecord Then
        res = MsgBox("Confirmer l'insertion de l'enregistrement courant ?", vbYesNo + vbQuestion, "Confirmation")
    Else
        res = MsgBox("Confirmer la modification de l'enregistrement courant ?", vbYesNo + vbQuestion, "Confirmation")
    End If
    If res = vbNo Then
        Cancel = True
        Exit Sub
    End If
 
    Set dbs = CurrentDb
 
    If Me.NewRecord Then
 
        Debug.Print "Recuperer de la base de donnes le numero d'ordre de l'enregistrement a inserer"
 
        strSQL = "SELECT uuid() As RecId;"
 
        Debug.Print "strSQL : " & strSQL
 
        Set rst = dbs.OpenRecordset(strSQL, , dbSQLPassThrough) ' dbExecDirect
 
        Debug.Print "Pass OpenRecordset"
 
        If rst.EOF Then
 
            res = MsgBox("Impossible d'obtenir le numero d'ordre de la base de donnees", vbOKOnly + vbCritical, "Erreur")
 
            rst.Close
            Set rst = Nothing
 
            GoTo Form_BeforeUpdate_Exit
 
        Else
 
            Debug.Print "RecId : " & rst.Fields("RecId").Value ' rst!RecId.Value
            Me.fldId = rst.Fields("RecId").Value ' rst!RecId.Value
 
            rst.Close
            Set rst = Nothing
 
        End If
 
    End If
 
Form_BeforeUpdate_Exit:
 
    dbs.Close
    Set dbs = Nothing
 
    Exit Sub
 
Form_BeforeUpdate_Err:
 
    MsgBox "Error #: " & Err.Number & vbCrLf & vbCrLf & Err.Description
    Resume Form_BeforeUpdate_Exit
 
End Sub

A l'insertion d'un nouvel enregistrement, Access me retourne une boite de dialogue avec l'erreur 3085



J'ai de même essayé avec "dbExecDirect" en lieu et place de "dbSQLPassThrough" sans plus de succès.

Si tu veux utiliser une syntaxe SQL propre à un moteur de base de données, tu dois soit utiliser ADO soit une requête Passthrough.

Faut-il nécessairement mettre en œuvre ActiveX Data Objects (ADO) pour récupérer un numéro d'ordre UUID de la base ?

Code :

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

SELECT uuid() As RecId;

Peux-tu m'expliquer ce qu'est précisément une requête "Passthrough", ce qu'il faut mettre en œuvre ?

Merci d'avance
.

[loufab]

Bonjour,

C'est une requête qui à la propriété Passthrough activée et donc le lien direct (connect) vers la base de données défini.

https://support.microsoft.com/fr-fr/...2-6dac62532a42

C'est soit :
ADO sans requête pass.
Soit :
DAO avec requête pass.

A noter qu'essayer des options en espérant que ça marche n'est pas la bonne technique. Il faut étudier les solutions possibles et apprendre les techniques de mise en oeuvre.

Cordialement,

[star]

Bonjour loufab,

Merci beaucoup pour tes réponses.

J'ai pu, en effet grâce au lien que tu m'as indiqué, créer une requête Passthrough qui donne un UUID au moyen de l'ordre :

Code :

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

SELECT uuid() As RecId;

Maintenant, une mise en œuvre avec ADO n'est pas évidente et je ne vois pas trop comment mentionner, en VBA, que l'ordre SELECT doit être exécuté en mode Passthrough. Il faudrait que je puisse initialiser la chaine de connexion et le type d'accès, etc.

Mais j'ai beau cherché, je sèche lamentablement...
.

[tee_grandbois]

bonjour,

je ne vois pas trop comment mentionner, en VBA, que l'ordre SELECT doit être exécuté en mode Passthrough.

je n'ai jamais utilisé mais sans doute avec le SQL Direct (pass-trough en anglais)

Il faudrait que je puisse initialiser la chaine de connexion et le type d'accès, etc.

il te demandera la chaine de connexion lors de la création de la requête mais après elle sera (peut être) stockée dans la requête finale, je pense

[star]

.
Bonjour tee_grandbois,

il te demandera la chaine de connexion lors de la création de la requête mais après elle sera (peut être) stockée dans la requête finale

En fait, il me faut, sur l'évènement Form_BeforeUpdate, exécuter un code VBA qui récupère de la base MySQL une valeur unique UUID que j'affecte, en final, au champ Id du formulaire avant qu'Access lance l'ordre d'insertion du nouvel enregistrement.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	Dim cn As ADODB.Connection
	Dim rs As ADODB.Recordset
	Dim strSQL As String
 
	strSQL = "SELECT uuid() As RecId;"
 
	Set rs = New ADODB.Recordset
	rs.Open strSQL, cn, adOpenStatic, adLockUnspecified, adCmdText
 
	If Not rs.EOF Then
		Me.fldId = rs.Fields("RecId").Value
		...

Avec ce code ADO, j'ai toujours la même erreur :



Il faudrait, comme loufab le suggère, pouvoir initialiser la connexion ADO pour que l'ordre SELECT s'exécute sur l'Open du Recordset en mode Passthrough. Du moins, c'est ce que je déduis de ses explications dans son dernier post.

Aurais-tu des suggestions ?
Merci
.

[tee_grandbois]

j'ai bien compris ton souci, mais avant de passer par VBA, as-tu au moins essayé de créer ta requête par le bouton du menu ?

[tee_grandbois]

j'ai aussi trouvé ça sur le web qui montre comment appeler une procédure stockée MySQL avec ADO ...

[Robert1957]

Bonjour star, tee_grandbois, loufab,

star si le code du post #7 est votre code complet, il manque l'ouverture de la connexion à votre base de données.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
	Dim cn As ADODB.Connection
	Dim rs As ADODB.Recordset
	Dim strSQL As String
 
	strSQL = "SELECT uuid() As RecId;"
 
	Set rs = New ADODB.Recordset
'Ici on ouvre une connexion au serveur
        Set cn = New ADODB.Connection
        cn.Open (ConnexionString)
'La suite de votre code
	rs.Open strSQL, cn, adOpenStatic, adLockUnspecified, adCmdText

ConnexionString étant une fonction qui retourne la connexion à votre serveur, à adapter à vos besoin:

Voici la doc MySQL pour la connexion.

Bonne journée

[star]

.
Bonjour loufab, tee_grandbois, Robert1957,

Merci de vous êtes penchés sur le sujet, vous m'avez beaucoup aidé.

Pour en finir, je vais rester sur le code suivant en ADO :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
 
Private Sub Form_BeforeUpdate(Cancel As Integer)
 
    Dim res As Integer
    Dim cn As ADODB.Connection
    Dim rs As ADODB.Recordset
    Dim strSQL As String
 
    On Error GoTo Form_BeforeUpdate_Err
 
    If Me.NewRecord Then
        res = MsgBox("Confirmer l'insertion de l'enregistrement courant ?", vbYesNo + vbQuestion, "Confirmation")
    Else
        res = MsgBox("Confirmer la modification de l'enregistrement courant ?", vbYesNo + vbQuestion, "Confirmation")
    End If
    If res = vbNo Then
        Cancel = True
        Exit Sub
    End If
 
    Set cn = New ADODB.Connection
    cn.Open "DSN=JcvPort"
 
    If Me.NewRecord Then
 
        strSQL = "SELECT uuid() As RecId;"
 
        Set rs = New ADODB.Recordset
        rs.Open strSQL, cn, adOpenStatic, adLockUnspecified, adCmdText
 
        If rs.EOF Then
 
            res = MsgBox("Impossible d'obtenir le numero d'ordre de la base de donnees", vbOKOnly + vbCritical, "Erreur")
 
            rs.Close
            Set rs = Nothing
 
            GoTo Form_BeforeUpdate_Exit
 
        Else
 
            Me.fldId = rs.Fields("RecId").Value
 
            rs.Close
            Set rs = Nothing
 
        End If
 
    End If
 
Form_BeforeUpdate_Exit:
 
    cn.Close
    Set cn = Nothing
 
    Exit Sub
 
Form_BeforeUpdate_Err:
 
    MsgBox "Error #: " & Err.Number & vbCrLf & vbCrLf & Err.Description
    Resume Form_BeforeUpdate_Exit
 
End Sub

@tee_grandbois

avant de passer par VBA, as-tu au moins essayé de créer ta requête par le bouton du menu ?

C'est ce que je répondais à loufab dans mon précédent post.
Ton lien m'a permis de réduire la chaine de connexion à la plus simple expression du nom du DSN, Merci beaucoup ;7

@Robert1957

il manque l'ouverture de la connexion à votre base de données

Copier/coller malencontreusement trop rapide. Désolé ;7
Merci pour le lien sur la connexion MySQL

J'en profite pour vous faire part de mes découvertes suite à cette étude portant sur les requêtes directes dans le cadre du développement d'une application client-serveur situant Access en tant que Front-End.

A prime abord, la mise en œuvre de tables liées avec Access n'est pas un contexte idéal pour réaliser des interrogations complexes optimisées, ni même d'ailleurs sur une simple table. A savoir, qu'Access rapatrie l'ensemble des enregistrements des tables impliquées avant même de procéder aux opérations ensemblistes sur les données (jointure, filtrage, tri, fonctions d'agrégat, etc.). Je peux comprendre dans la configuration d'une application distribuée, ce pourrait être un moyen de pallier à ce que même les micro-services ne sont pas capables de faire.

Dans ces conditions, faire du client-serveur est pénalisant à mon sens, et donc, j'en conclue qu'il vaudrait mieux, avec Access, recourir aux accès directs quitte à by passer totalement les fonctionnalités inhérentes du produit. J'en conviens que cette stratégie enlève tout l'attrait d'Access du coup

J'aurais juste une préconisation à faire. J'aime bien Access pour toutes les facilités qu'il apporte (SGBDR, Forms, Reports, Graphics et j'en passe), et je compte bien continuer à l'utiliser à titre perso. Au ingénieur de Microsoft, je leur suggère d'intégrer une IA à Access de sorte à ce que ce dernier décide du plan d'exécution de la requête soumise, côté serveur ou côté client ou un mixte des deux, à l'instar le l'optimiseur d'Oracle qui n'en finit pas d'évoluer, je présume :7

A bon entendeur salut !

Au plaisir
Cordialement
.

[loufab]

Bonjour,

J'aime bien les discussions sur le fond.

A prime abord, la mise en œuvre de tables liées avec Access n'est pas un contexte idéal pour réaliser des interrogations complexes optimisées, ni même d'ailleurs sur une simple table. A savoir, qu'Access rapatrie l'ensemble des enregistrements des tables impliquées avant même de procéder aux opérations ensemblistes sur les données (jointure, filtrage, tri, fonctions d'agrégat, etc.). Je peux comprendre dans la configuration d'une application distribuée, ce pourrait être un moyen de pallier à ce que même les micro-services ne sont pas capables de faire.

Entièrement d'accord. Les tables liées sont un concept Access qui ne s'applique pas forcément aux moteurs plus évolués. Comme la richesse SQL est liée au moteur utilisé si tu prends access/sqllite tu auras plus de latitude en utilisant le côté client, au contraire d'un access/postgresql par exemple.

Dans ces conditions, faire du client-serveur est pénalisant à mon sens, et donc, j'en conclue qu'il vaudrait mieux, avec Access, recourir aux accès directs quitte à by passer totalement les fonctionnalités inhérentes du produit. J'en conviens que cette stratégie enlève tout l'attrait d'Access du coup

Je dirais qu'avec une utilisation client/serveur, l'attrait restera toujours l'IHM. Pour l'instant il n'existe pas de produit qui arrive à ce résultat. Quand on regarde d'un point de vue strictement moteur SGBD, by-passer les fonctions internes ne sont pas problématiques. Le moteur ACE est largement moins riche qu'un autre (à part certain pseudo moteur comme SqlLite par exemple).

Au ingénieur de Microsoft, je leur suggère d'intégrer une IA à Access de sorte à ce que ce dernier décide du plan d'exécution de la requête soumise, côté serveur ou côté client ou un mixte des deux, à l'instar le l'optimiseur d'Oracle qui n'en finit pas d'évoluer, je présume

Access n'est pas un véritable client/serveur, si on veut faire du C/S on utilise ADO et requêtes passT, l'attachement des tables peut permettre une souplesse dans les petites tâches non consommatrices.

L'IA :
L'IA Copilot sur Access est annoncée pour les prochaines versions (365).

Jetshowplan te donne déjà le déroulé complet d'une requête. 0.0001% connaisse cette fonctionnalité, 1% l'utilise lorsqu'ils sont confrontés à un problème de lenteur.
La trace ODBC permet de voir ce qu'il se passe entre client et serveur.

A mon avis remplacer le développeur par l'IA est un excellent moyen pour appauvrir la capacité/connaissance/imagination des développeurs et dans 10 ou 15 ans on ne saura même plus écrire une application performante, on reproduira inlassablement les modèles préétablis (par l'IA suivant sa banque mémoire -ce post par exemple) même s'ils sont mauvais.

Cordialement,

[star]

A mon avis remplacer le développeur par l'IA est un excellent moyen pour appauvrir la capacité/connaissance/imagination des développeurs

Mon propos ne se situait pas à ce niveau, mais plutôt sur la capacité d'un optimiseur comme celui d'Oracle à déduire le meilleur plan d'exécution d'une requête au moyen de statistiques et autres techniques basées sur les règles et les coûts, l'environnement réseau distribué ou non..., épargnant par la même au développeur de devoir instruire le système sur comment procéder.

Si Access venait à être doté d'un optimiseur assez intelligent, on peut imaginer qu'il puisse être capable de déduire qu'une jointure sur des tables liées soit exécutée par le moteur de base de données externe contenant les tables, ce dernier ne serait chargé que de retourner les lignes de résultat de la requête, et non l'ensemble des enregistrements des tables concernées. Cela épargnerait au développeur de devoir coder des requêtes Passthrough avec VBA et ADO pour pallier au manque de discernement, si ce n'est, d'efficacité d'Access.

On pourrait échafauder d'autres stratégies plus complexes :7 Je reste curieux d'observer Copilot à œuvre

Merci
.

[loufab]

Pour t'éviter des noeuds au cerveau :
Si tu n'utilises pas ACE et que ton moteur SGBD permet le C/S alors utilise ADO et/ou PassT si tu veux obtenir une vrai application professionnelle performante. Tu pourras ainsi utiliser Oracle à loisir avec tous les outils qu'il embarque.
ACE fonctionne toujours avec le client, contrairement à Mysql, Oracle, Post... c'est techniquement comme ça. Ce n'est pas une carence, juste un choix technique historique.

A noter qu'ADO et PassT sont 2 choses différentes et totalement indépendantes mais qui peuvent se compléter dans une IHM. Ce qui est inexorablement lié c'est ADO et VBA.