Discussion :

[joebarthib]

Salut,

Je travaille sur une appli multiposte avec ADO/Access. Lorsque qu'une instance de mon appli modifie/insère/supprime un enregistrement d'une table, il faut que les autres instances en soient averties et mettent à jour cette table.
L'idéal aurait été de mettre le ADOTable.CursorType à ctDynamic, mais pas pour Access qui ne gère que le ctStatic !

Existe-t-il un moyen simple de le faire ? Je pensais utiliser Requery (infiniment + rapide que Refresh) pour chaque table à mettre à jour, mais comment est-ce que chaque instance peut savoir quelle table mettre à jour et quand ? Je pensais :

- soit côté "instance de l'appli qui fait la modif", je mets qq part (dans une table ou un .ini) des infos sur cette modif. Côté "autres instances", avec un Timer (de 30 sec ?) je check s'il y a des Requery à faire,
- soit j'arrive à intercepter un événement (lequel ? il existe ?) émanant de la base (un événement de ADOConnection ?) à chaque fois qu'une modif est faite, et dans sa callback je fais le Requery judicieux.

Qu'en pensez-vous ? Que faites-vous/que me conseillez-vous de faire ?

Merci beaucoup !

[bidou]

Utilises un curseur de type Keyset et gère des tailles de cache assez petite

[joebarthib]

salut,

merci mais :
- KeySet permet que les autres utilisateurs voient les modifications d'enregistrements, mais pas les insertions/suppressions d'enregistrements
- KeySet n'est pas supporté par Access, il ne supporte (en mode client) que ctStatic

:-(

[bidou]

Petite correction, access n'y est pour rien. ADO ne fournit que des curseurs statiques en mode client (et heureusement).

Faire une application multi-utilisateurs avec Requery en mode client va être une monstrueuse usine à gaz, caril y a antagonisme entre curseur client et visualisation TR.

[joebarthib]

Que des curseurs statiques en mode client ? Mince. Mais pourquoi tu dis heureusement ?
J'ai trouvé un document de Microsoft parlant des curseurs avec ADO, ils parlent notamment du CursorLocation client ou serveur, des curseurs statiques, dynamiques, ou en keyset : http://support.microsoft.com/directory/worldwide/fr/white/adocurs.doc

Et ils disent que pour une appli en multiposte, le curseur dynamique est préconisé, même s'il grève les perfs, j'ai vu ça ailleurs sur le net, et j'ai aussi vu qu'Access ne gère pas les curseurs dynamiques.
Tu penses que ça vient d'ado ?

Qu'est-ce que j'aurais dû faire d'après toi ? Utiliser des requêtes plutôt que des tables ? Utiliser autre chose qu'ADO (ou qu'Access) ?
Dernière question : comment faire maintenant ?!

Merci !

[bidou]

si tu regardes le tableau p 15/16 tu verras qu'un curseur client est toujours statique.

Only a setting of adOpenStatic is supported if the CursorLocation property is set to adUseClient. If an unsupported value is set, then no error will result; the closest supported CursorType will be used instead.

Ce que je ne comprends pas, c'est pourquoi tu veux utiliser un curseur client pour faire une application qui demande des fonctionnalités serveur.

[joebarthib]

Ah mince, j'avais pas vu ce passage !
Je voulais utiliser un curseur client car il est plus souple et permet plus de choses d'après ce que j'ai cru comprendre.
Par exemple, avec un curseur serveur, je ne peux plus avoir de relations maître/esclave avec mes tables (je crois qu'il y a aussi des pb avec les bookmarks ?), ni les trier.
Ou alors il aurait fallu que ne me servent pas des ADOTables pour ça, mais que j'utilise des ADOQuery avec requêtes correspondant à la relation maître/esclave désirée ?

[bidou]

En effet, il y aura une perte de fonctionnalités importante, et c'est vrai qu'il faut privilégier le travail SQL côté serveur.

Mais là tu va devoir faire un choix.
Probablement qu'une utilisation d'interbase serait un meilleur choix.

[joebarthib]

Mon appli doit être prête pour lundi dans 8 jours ! Tant pis je vais essayer d'arranger du mieux que je peux, et leur livrer ça en attendant.
Mon patron me demande une estimation du temps (1 mois, 6 mois ?) pour la migration de mon appli sur Interbase (ou un autre sgbd orienté serveur).
Aurais-tu une idée, sachant que :
- j'ai une quarantaine de tables, de 5 à 25 champs
- toutes ces tables sont utilisées dans mon appli avec des composants ADO, en particulier des TADOTables avec des relations maître/détail
- je programme en delphi depuis deux ans, et en sgbd, je ne connais que Access utilisé avec les composants ADO, je ne connais pas d'autres composants DB, et ne connais pas du tout Interbase.

Aurais-tu des liens intéressants à me donner ? Sinon je vais chercher

Confirmes-tu qu'Interbase est le meilleur choix, plutôt que Sql Server, Oracle etc. (que je ne connais pas plus) ?

Merci beaucoup !

[bidou]

Si tu peux utiliser SQL-Server le portage va être beaucoup plus court car il existe des outils de conversion access>>SQL-Server.
et cela ne change rien à tes composants ADO.
Sinon il faut poser la question sur le forum interbase car je n'ai jamais réalisé de telle conversion.

En attendant, si la visibilité multi-utilisateurs t'est indispensable, tu peux :
Soit travailler avec des requêtes coté serveur (mais gros remaniement du code)

Soit déclencher des requery sur un timer mais dans ce cas cherche à utiliser un temps assez long (de l'ordre de la minute) si tes tables sont volumineuses.

[joebarthib]

merci Bidou de prendre la peine de t'intéresser à mon cas ! :-)

Concernant SQL-Server, j'ai entendu dire qu'il était bien mais qu'il fallait payer des licences serveurs et postes chères ! Alors qu'il existe une version gratuite d'Interbase... Et est-ce que si je l'utilise, je n'aurai pas à me préocuper des mises à jours des données entre postes, et des verrous ? Même en gardant mes ADOTables actuelles ?

En attendant, concernant tes 2 propositions :

- d'accord pour travailler avec des requêtes, mais quel intérêt qu'elles soient côté serveur ? Je viens de faire un petit prog de test avec un TADOQuery client (et son ADOConnection côté client aussi) relié à une grille, je lance mon prog sur deux postes, je fais la requête sur un poste, je modifie une donnée de la grille, je refais la requête sur le 2e poste : bingo la donnée modifiée apparaît bien.

- requery/timer : j'y pensais. Le problème est que selon la table, ça peut prendre jusqu'à 2-3 secondes (mais moins en général), et c'est pas acceptable pour l'utilisateur, surtout s'il y a plusieurs tables à mettre à jour...

Merci pour ton aide !

[StarMusic]

Messieurs,

Je viens de lire avec grand intérêt votre débat ! Je développe une appli Multi Users autour de SQL server et je me demandais comment j'allais gérer ce problème...

J'ai appris pas mal de chose en vous lisant... Cependant, pouvez vous me confirmer qu'en utilisant des CursorType Dynamic les différentes modifs et autres ajouts seront visibles des autres postes ??

J'utilise moi aussi Des ADO avec des tables Maitre/détail, principalement des Dataset (En Table ou Query)

[bidou]

Evidemment ton exemple fonctionne puisque tu fais une deuxième requête après la modification. Si tu utilises un curseur serveur (dynamique ou à clé) tu n'as pas besoin de faire une deuxième requête. Même si tu fais ta requête avant, la modification sera prise en compte à chaque PageTimeOut (à l'exception des enregistrement du cache).

La méthode timer / requery est loin d'être top, c'est même un pis aller.
Mais de toutes façon dans la logique client/serveur tu ne peux pas concilier les avantages du travail coté serveur et coté client. Il y a donc une estimation à faire des sacrifices en fonctions des bénéfices.

InterBase sera une solution moins chere, mais tu devras reprendre ton code. Tu ne va pas utiliser ADO pour piloter interbase en delphi.

Pour répondre à starmusic, tu ne peux travailler avec des tables maitres/détails coté serveur avec tout les providers côté serveur. Si ton provider ne le supportes pas il te faudra choisir entre maitre/détail standard et curseur dynamique.

[joebarthib]

Et si, dans un premier temps, mon appli ne doit être utilisée que pour quelques postes, ça peut aller avec Access ? A partir de combien de postes est-ce que tu estimes que ça ramera trop avec Access ? (les avis diverges, j'ai vu 3, aussi 10 ou 15)

Si je garde dans un premier temps Access, et que je modifie mes ADOTables pour utiliser des ADOQuery à la place, est-ce que ça serait pas un bon truc à faire, car je gagnerai en perf, et quand ensuite il faudra que je migre, je pourrai conserver ces requêtes (en les modifiant légèrement pour les adapter au nouveau sgbd) ?

Dernière question : si j'ai bien compris, lorsqu'on utilise des requêtes côté serveur, leurs données sont mises à jour automatiquement (ex : une grille pointant sur le DataSource d'un ADOQuery) lorsqu'elles sont modifiées sur d'autres postes. Lors de ma conversion de mes ADOTables en requêtes, il vaudrait mieux que je fasse en même temps un changement de curseur, en prenant serveur et non plus client ? Quelles contraintes va-t-il y avoir par rapport à un curseur client ? Des problèmes de tris par exemple ?

Merci pour ton aide et ta patience !

[bidou]

Essayons de prendre les problèmes dans l'ordre.

• La migration vers SQL-Server ou Interbase est sommes toutes assez identique. Le code est assez proche car Delphi présente l'avantage de proposer une approche assez similaire pour tous ses composants de données. Le choix doit alors plus se faire sur le SGBD et je ne rentrerais pas dans ce débat ici.
• Il est toujours mieux de privilégier une approche par requête plutôt que l'appel de tables entières. Tu économises ainsi du temps et des ressources. De plus, c'est une bonne habitude de programmation de ne rapatrier que ce qui est effectivement nécessaire.
• Le choix client / serveur dans ADO est très souvent assez complexe. La seule façon de ne pas se tromper et de définir l'ordre des fonctionnalités souhaitées. Dans ton cas, il semble que la mise à jour soit indispensable. Dans ce cas le travail côté serveur est indispensable. C'est un mode de travail qu'Access n'apprécie pas beaucoup du fait qu'il n'est pas naturellement Client/Serveur. Définir le nombre de client qu'il peut effectivement servir est assez difficile car cela dépend de la taille et des fonctionnalités des curseurs qu'il aura à gérer. Pour des curseurs bidirectionnel gérant des milliers d'enregistrement, cinq utilisateurs me paraît être un grand maximum. Par contre si les jeux renvoyés sont petits il peut monter beaucoup plus haut sachant que Jet est plutôt un bon moteur de données.
• Il y a une perte de fonctionnalité en utilisant des curseurs serveur. Contrairement à une idée répandue, celle-ci est très faible car des requêtes SQL bien rédigées fournissent des jeux de résultats équivalents. Prenons un exemple, les tables maître/détails.
  Les objets Table (ADO ou non) et DataSource permettent de générer ce type de comportement sans écrire de code dans Delphi. En travaillant avec des requêtes côté serveur, tu dois écrire le code permettant d'obtenir une fonctionnalité similaire. Ce code est très simple à faire car un jeu de commandes paramétrées et/ou de procédures stockées fera 90% du travail.

J'espère avoir répondu à tes questions, et n'hésites pas si tu en as d'autres.

[joebarthib]

Salut,

merci encore pour tous tes conseils. Je pense qu'à moyen terme nous allons faire une migration vers FireBird. FireBird plutôt qu'IB ou Sql Server, pour un problème de coûts.
Mais cette migration sera longue, et demandera une refonte poussée de mon appli, de la gestion de mes tables, et il faudra que j'apprenne beaucoup de choses sur les appli de gestion en client/serveur, et que je me penche sur l'utilisation exclusive de requêtes.

Juste une question : j'ai par exemple une table polices, maître d'autres tables. Pour ces autres tables, je pourrai utiliser des requêtes (à chaque fois qu'on passe d'une police à un autre), ok. Mais pour la table polices, des données sont affichées dans des DBEdit, et pour l'instant on peut naviguer parmi les polices avec un DBNavigator.
Comment puis-je remplacer cette table par une requête, et conserver la souplesse actuelle de pouvoir naviguer parmi les polices ?

De toute manière, mes clients ne pourront pas attendre le temps que prendra la migration, donc il faudra dans l'immédiat que je fasse le maximum pour limiter les problèmes actuels avec Access (gérer la mise à jour, et remplacer le maximum de tables par des requêtes)