Discussion :

[Etxezarreta]

Bonjour,
Plusieurs utilisateurs travaillent sur un FE local avec un BE SqlAzure. Les données étant confidentielles, chaque utilisateur ne doit voir que ses données. Pour les clauses where des requêtes tiennent compte de l'ID de l'utilisateur: la solution la plus simple, sans avoir à s'identifier etc.. est d'après moi de placer le paramètre dans une table du front end (j'en ai 5 à distribuer, c'est gérable).
D'autre part, j'ai une autre interrogation:
nous utilisons une table intermédiaire, qui sert simplement à afficher aux utilisateurs un premier choix de lignes de données qu'ils valident en cliquant sur un champ type case à cocher (champ oui/non dans la table). Je pense qu'il y aura des problèmes d'accès concurrents, donc j'envisage de mettre cette table en local.
J'ai fait les premiers essais, et je n'y arrive pas: j'ai migré ttes les tables puis essayé de transformer les deux tables évoquées ci dessus en tables locales: je ne trouve pas la solution. J'ai aussi essayé de migrer ttes les tables sauf les deux, puis de recréer ces derniètes en locales: problème: impossible de recréer les liens nécessaires avec d'autres tables. Les touffes de cheveux s'accumulent sous le bureau.
Merci de vos suggestions.
Etxe.

[nico84]

Bonjour,

Je ne suis pas sûr d'avoir tout bien compris mais si chaque utilisateur a sa frontale sur son PC et que cette frontale intègre des tables, celles-ci seront spécifiques à sa session donc cela devrait répondre à la problématique de tables temporaires.

J'ai aussi essayé de migrer ttes les tables sauf les deux, puis de recréer ces derniètes en locales: problème: impossible de recréer les liens nécessaires avec d'autres tables.

Il n'est jamais nécessaire de créer des liens entre les tables. C'est une habitude de programmation qui permet de sécuriser en partie la cohérence des données mais seul le code peut garantir tous les cas de figure. C'est même une pratique qui semble disparaitre car peu compatible avec le "big data". Effectivement si les tables sont dans des bases différentes ce n'est de toute façon pas possible...

[Etxezarreta]

Bonjour,

Je ne suis pas sûr d'avoir tout bien compris mais si chaque utilisateur a sa frontale sur son PC et que cette frontale intègre des tables, celles-ci seront spécifiques à sa session donc cela devrait répondre à la problématique de tables temporaires.


Il n'est jamais nécessaire de créer des liens entre les tables. C'est une habitude de programmation qui permet de sécuriser en partie la cohérence des données mais seul le code peut garantir tous les cas de figure. C'est même une pratique qui semble disparaitre car peu compatible avec le "big data". Effectivement si les tables sont dans des bases différentes ce n'est de toute façon pas possible...

Bonjour Nico,
Merc ide ta réponse. Quand tu dis qu'il n'est pas nécessaire de lier les tables entre cles primaires et clé étrangères, tu veux dire que cela ne vas pas créer de problèmes si on en le fait pas et que l'on crée ttes les requetes sous vba?

[nico84]

Quand tu dis qu'il n'est pas nécessaire de lier les tables entre cles primaires et clé étrangères, tu veux dire que cela ne vas pas créer de problèmes si on en le fait pas et que l'on crée ttes les requetes sous vba?

Effectivement le SQL n'a besoin d'aucune relation pour exécuter une jointure et je ne suis même pas sûr que cela gagne du temps d'exécution (ce sont les index qui gagnent du temps). Les liaisons entre tables sont des contraintes en écriture mais neutres en lecture.

Par contre une jointure sur des tables qui ne sont pas dans la même base de données peut être extrêmement lente !
Il ne faut envisager des tables locales que comme alternative à une variable tableau à mon avis.

[Etxezarreta]

Effectivement le SQL n'a besoin d'aucune relation pour exécuter une jointure et je ne suis même pas sûr que cela gagne du temps d'exécution (ce sont les index qui gagnent du temps). Les liaisons entre tables sont des contraintes en écriture mais neutres en lecture.

Par contre une jointure sur des tables qui ne sont pas dans la même base de données peut être extrêmement lente !
Il ne faut envisager des tables locales que comme alternative à une variable tableau à mon avis.

Ok, merci beaucoup. Tu parles de variable tableau, un array donc, je ne vois pas comment utiliser cet outil ici, peux-tu m'en dire plus?

[Etxezarreta]

Bonjour,

Je ne suis pas sûr d'avoir tout bien compris mais si chaque utilisateur a sa frontale sur son PC et que cette frontale intègre des tables, celles-ci seront spécifiques à sa session donc cela devrait répondre à la problématique de tables temporaires.


Il n'est jamais nécessaire de créer des liens entre les tables. C'est une habitude de programmation qui permet de sécuriser en partie la cohérence des données mais seul le code peut garantir tous les cas de figure. C'est même une pratique qui semble disparaitre car peu compatible avec le "big data". Effectivement si les tables sont dans des bases différentes ce n'est de toute façon pas possible...

Pour revenir à la base, j'ai songé à créer la table en locale plutot que dans SqlAzure, car nous avions identifié un risque de conflit d'accès important: 5 utilisateurs sont susceptibles de faire tourner des requetes DELETE et INSERTINTO sur la même table: que penses-tu de ce risque: peut-être que la configuration choisie permet de le gérer?
Merci d'avance.
Etxe.

[nico84]

Ok, merci beaucoup. Tu parles de variable tableau, un array donc, je ne vois pas comment utiliser cet outil ici, peux-tu m'en dire plus?

C'est une image, une table locale est bien plus facile à utiliser mais c'est pour dire qu'elle fonctionne "comme une mémoire programme"

Pour revenir à la base, j'ai songé à créer la table en locale plutot que dans SqlAzure, car nous avions identifié un risque de conflit d'accès important: 5 utilisateurs sont susceptibles de faire tourner des requetes DELETE et INSERTINTO sur la même table: que penses-tu de ce risque: peut-être que la configuration choisie permet de le gérer?

J'ai peu d'expérience sur ce point. J'ai une application avec une centaine de tables et jusqu'à 50 utilisateurs et quand j'ai tenté de mettre les données sur sqlazure les temps de réponse étaient délirants j'ai donc tout arrêté. Access et son moteur JET/DAO ne font pas travailler le serveur et chargent énormément le réseau c'est donc par principe difficilement compatible avec une base sur le net. Au minimum il faudrait tout écrire en ADO et probablement aussi alléger considérablement les fenêtres qui de base chargent toutes les données.