Discussion :

[giaco]

Bonjours,

J'ai trouvé ce post suite à une recherche...
Je me permet donc de le remonter

J'ai créé une application qui fonctionne avec Interbase 6.0 en monoposte.
L'utilisateur en est très contant.

En mode local pour fonctionner en réseau il faut que ta base soit visible via l'explorateur de fichier (donc tu crées ta base en locale et tu met en partage le répertoire). L'ordinateur 'distant' dois se connecter sur ce lecteur reseau et enfin tu peux créer un alias de base locale.

C'est effectivement comme ça que fontionne mon application.

Le problème est que si je veux faire du travail en réseau les enregistrements réalisés sur un ordinateur ne sont pas prises en charge par l'autre ordinateur.
Le problème est le même si je lance 2 fois mon application sur le même ordinateur.

La solution à mon problème est à mon avis celle ci :

Avec IBconsole tu vas faire Serveur/register et puis tu vas selectionner
Remote Serveur tu dois préciser le nom du serveur (le nom de la machine) le protocole que tu veux utiliser (le plus souvant TCP/IP)
un alias, description, le login et pass ( je pense du SYSDBA...)
Une fois cette étape faite, tu peux référencer tes bases de données sur le serveur distant (toujours sous IBConsole).

C'est ce que j'ai fait...
J'ai testé et le problème persiste...

Il faut donc que je modifie les propriétés de mon composant TIBdatabase.
Après avoir consulté l'aide de Borland C++ Builder, je n'est pas trouvé de solutions à mon problème...

Si je ne me tronmpe pas : il faut que je configure mon TIBDatabase pour qu'il se connecte à un serveur de base de donnée distant.

C'est la ou je solicite votre aide...
Si quelqu'un avait un conseil, un bout de code ou l'adresse d'un tut...
Cela m'aiderrait énormément.

D'avance merci.
Cordialement, Giaco.

[Barbibulle]

Bonjours,
J'ai créé une application qui fonctionne avec Interbase 6.0 en monoposte.
L'utilisateur en est très contant.

En mode local pour fonctionner en réseau il faut que ta base soit visible via l'explorateur de fichier (donc tu crées ta base en locale et tu met en partage le répertoire). L'ordinateur 'distant' dois se connecter sur ce lecteur reseau et enfin tu peux créer un alias de base locale.

C'est effectivement comme ça que fontionne mon application.

Le mode local est réservé à une utilisation monoposte. Même si pour des raisons pratique on met le fichier sur un disque réseau (par exemple parce que le serveur à une sauvegarde automatique de ce disque) la connexion locale n'est pas recommandée pour une utilisation partagée simultanée.

...
La solution à mon problème est à mon avis celle ci :

Avec IBconsole tu vas faire Serveur/register et puis tu vas selectionner
Remote Serveur tu dois préciser le nom du serveur (le nom de la machine) le protocole que tu veux utiliser (le plus souvant TCP/IP)
un alias, description, le login et pass ( je pense du SYSDBA...)
Une fois cette étape faite, tu peux référencer tes bases de données sur le serveur distant (toujours sous IBConsole).

C'est ce que j'ai fait...
J'ai testé et le problème persiste...

Mon explication n'est pas tres claire, on a l'impression qu'il suffit de configurer IBconsole pour que ca fonctionne en mode remote.

Le mode remote va permettre de connecter plusieurs PC simultanément sur la meme base (sans que celle ci ne soit sur un disque réseau).

Il faut donc que je modifie les propriétés de mon composant TIBdatabase.
Après avoir consulté l'aide de Borland C++ Builder, je n'est pas trouvé de solutions à mon problème...

Si je ne me tronmpe pas : il faut que je configure mon TIBDatabase pour qu'il se connecte à un serveur de base de donnée distant.

La configuration du TIBDatabase se fait en double cliquant dessus. puis il faut choisir Distante indiquer le nom du serveur, le protocole, etc..

Voilà pour la configuration.

Ceci dit si votre application est faite pour fonctionner en monoposte je suppose que vous avez laisser la configuration des transactions à snapshot. Cette configuration empèche de voir les modifications des autres PC même s'ils font des commit et tant que la transaction est ouverte. Ce qui expliquerai votre probleme.
Mettez vos transaction en mode read commited celà suffit dans la plupart des cas...

[giaco]

Bonjours,

Tout d'abord merci Barbibulle pour ton aide.

Je ni arrives pas...
Bouuuuuuuuuu

Je vais donc ré-essayé, bidouiller....
Il me parrait plus profitable de trouver la soluce tout seul.

Barbibulle je te tient au courrant du résultat.

Cordialement.
Giaco

[giaco]

Bonjours,


ça y est ça marche !
Merci Barbibulle pour ton aide.

Il me reste néenmoins un petit problème...

Quand je lance 2 fois mon application et que je fais des ajout de données dans la base, je n'arrives pas à les afficher dans ma 2 ème application.

Si quelqu'un pouvait de donner un conseil.... ça serrait super cool.
D'avance merci.

Cordialement,
Giaco.

[Barbibulle]

Ceci dit si votre application est faite pour fonctionner en monoposte je suppose que vous avez laisser la configuration des transactions à snapshot. Cette configuration empèche de voir les modifications des autres PC même s'ils font des commit et tant que la transaction est ouverte. Ce qui expliquerai votre probleme.
Mettez vos transaction en mode read commited celà suffit dans la plupart des cas...

[giaco]

Bonjours,

J'ai passé mon composant transaction à : lecture commited.
J'ai donc les paramètres suivants :

Code :

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

1
2
3
4
 
read_committed
rec_version
nowait

Mais ça ne marche pas....

Pour info :
J'ai plusieurs IBTables qui se connectent à la même table et pour mettre à jours un enregistrement je fais un refresh() par table ce qui est très long.
Ceci doit être lié à mon problème...

Si vous aviez une idée, un conseill... pour m'aider, ce serrait très gentil.
D'avance merci.

En tout cas un grand merci pour votre aide.

Cordialement,
Giaco

[giaco]

Bonjours,

J'ai trouvé un début de solution :

Code :

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

1
2
3
 
IBTable1->Close();
IBTable1->Open();

Et ça marche !!!!!!!!!!!!

C'est bourrin mais j'ai trouvé que ça....

En tout cas merci Barbibulle pour ton aide qui m'a été très précieuse.
Mais, (si je peux me le permettre), y a t'il une autre façon de procéder ?

D'avance merci.

Cordialement,
Giaco

[giaco]

Bonjours,

Suite à quelques tests, c'est supper long et c'est le bazard....

Si quelqu'un avait une idée de la solution, cela m'aiderrait énormément.

Au fait, j'ai plusieurs IBTables connectées à la même table et qui ont chacune un DBGrid dans lequel on affiche les données.

D'avance merci.
Cordialement,

[Barbibulle]

Donc j'en conclu que vous ne faites jamais de Commit....

Faire un close de tous les objets attaché à une même transaction, ferme la transaction. Lorsque la transaction se ferme sans qu'on ne lui demande par un commit ou rollback, celle ci lance l'action définie dans la propriété DefaultAction (qui est si on n'y a pas touché un commit).

Pour rappel :
Commit : C'est pour valider les modifications faites dans la transaction.
RollBack : Pour annuler les modifications faites dans la transaction.

Donc il ne suffit pas de mettre la transaction en mode readcommited, il faut "commiter" de temps en temps !

Autre remarque : il faut éviter d'utiliser le composant TIBtable qui n'est pas du tout optimisé pour une utilisation en environnement multi-utilisateur client/serveur. Pourquoi les TIBTable existe t'il alors ?? . Et bien il existe pour faciliter la migration des applications qui utilisaient BDE.

Il est donc préférable de travailler avec le TIBDataSet et ainsi cibler au plus juste les données à sélectionner.
Il est rare qu'un utilisateur ait besoin d'avoir une table entière à l'écran et donc il vaut mieux ne rapporter que les informations utiles.(Colonnes et lignes)

Ensuite il vaut mieux n'ouvrir que les DataSet (ou objets de données) necessaire lors de l'utilisation. (On n'ouvre pas tous les objets de données au lancement de l'application pour les laisser ouvert jusqu'a la fin...)

[giaco]

Bonjours,

J'ai crée une petite aplication pour réaliser les test dessus.
Elle contient :
* 1 TIBDatabase
* 1 TIBTransaction
* 1 TDataSource
* 1 TIBTable
* 1 TdxDBGrid (Analogue à TDBGrid)

Je suis obligé de garder la grille et celle ci doit se remetre à jours automatiquement.

Je vais poster mon code car il y a quelque chose que je n'arrives pas à comprendre :

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
 
//---------------------------------------------------------------------------
 
void __fastcall TForm1::Button1Click(TObject *Sender)
{
 
IBTable1->Insert();
 
IBTable1->FieldByName("client")->AsString=Edit1->Text;
 
IBTable1->Post();
 
IBTable1->ApplyUpdates();
 
IBTransaction1->Commit();
 
}
//---------------------------------------------------------------------------

Quand j'exécute ce code, le contenu de m'a grille s'efface...
Si j'utilise CommitRetaining() alors le contenu de ma grille ne s'efface pas mais l'autre aplication ne se mets pas à jours.

Aurrais tu une astuce, un conseil, un bout de code... S'il te plait.

En tous cas un grand merci Barbibulle pour ton aide qui m'est très précieuse.

Encore merci.
Cordialement,
Giaco

[Barbibulle]

Pour que l'autre application déjà lancée et placé sur cette meme grille voit la modification il faut rafraichir les données.
Le probleme c'est que le refresh est de niveau TDataSet et n'est pas implanté sur tous ses descendants. Donc je ne suis pas sur qu'un TIBTable.Refresh rafraichisse toutes les données (il est possible soit que ça ne fasse rien soit que ça rafraichisse uniquement l'enregistrement courant.) La méthode qui marche le mieux est de faire un close suivi d'un open.

[giaco]

Boujours,

La solution marche mais c'est pas le "top" ....

Puisse que c'est le IBTable qui pose problème,
je me posait la question suivante :
Comment faire pour avoir une grille de type DBGrid sans utiliser de IBTable.

Exemple d'utilisation de mon DBGrid : Sélection d'un client dans l'écran facturation.
L'utilisateur doit pouvoir sélectionner le nom du client dans la grille.

Si quelqu'un à une idée, ça serrait super cool.

D'avance merci.

Cordialement,
Giaco

[giaco]

Bonjours,

J'ai vu sur ce forum que IBEvent servait à "écouter" le serveur.
Grace à l'évennement OnEventAlert, je penses que l'on peut savoir quelle table est à re-charger et laquelle ne l'est pas.

J'ai donc procédé ainsi :

Code :

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

1
2
3
4
5
6
7
8
 
void __fastcall TForm1::IBEvents1EventAlert(TObject *Sender,
      AnsiString EventName, int EventCount, bool &CancelAlerts)
{
 
ShowMessage(EventName);
 
}

Aucun message ne s'affiche car je n'est pas configuré la liste d'évennement (la propriété Events).
J'ai fait quelques test mais ça entraine des exceptions.

Le concepte serrait donc de placer dans le OnEventAlert un code qui mette à jours les IBTables.

C'est la ou on arrive au 2ème problème :
Comment mètre à jours des IBTables ?
Et ceci sans utiliser Refresh() car il ne marche quand plusieurs clients fonctionnent simultanément.
Et sans faire de Close() Open() car ça enlève la sélection en cours dans la grille.

Si quelqu'un à une idée, une astuce....

D'avance merci.

Cordialement,
Giaco

[Barbibulle]

Bonjour,

La solution marche mais c'est pas le "top" ....

Puisse que c'est le IBTable qui pose problème,
je me posait la question suivante :
Comment faire pour avoir une grille de type DBGrid sans utiliser de IBTable.

J'ai déjà répondu à cette question précédemment :

Autre remarque : il faut éviter d'utiliser le composant TIBtable qui n'est pas du tout optimisé pour une utilisation en environnement multi-utilisateur client/serveur. Pourquoi les TIBTable existe t'il alors ?? . Et bien il existe pour faciliter la migration des applications qui utilisaient BDE.

Il est donc préférable de travailler avec le TIBDataSet et ainsi cibler au plus juste les données à sélectionner.
Il est rare qu'un utilisateur ait besoin d'avoir une table entière à l'écran et donc il vaut mieux ne rapporter que les informations utiles.(Colonnes et lignes)

Ensuite il vaut mieux n'ouvrir que les DataSet (ou objets de données) necessaire lors de l'utilisation. (On n'ouvre pas tous les objets de données au lancement de l'application pour les laisser ouvert jusqu'a la fin...)

Comme je le disais, présenter une table entière est tres lourd et en plus est totalement inutile pour l'utilisateur.
L'utilisateur ce qu'il veux c'est trouver le bon client et donc il n'a que faire de la liste complète de ses clients.
Présenter une liste compléte revient à demander à l'utilisateur de faire lui même le travail de recherche...
Cette méthode est peut etre valable sur les petits volumes mais est à proscrire lorsqu'on a beaucoup de ligne. Le plus judicieux (et moins couteux en ressource) est de faire la recherche à la place de l'utilisateur. Pour celà il faut mettre à disposition de l'utilisateur des critères de recherche. Ceux ci permettent de cibler une liste plus restrainte de ligne, (et c'est moins gourmand en resource) et facilite la recherche pour l'utilisateur qui à moins de chose à analyser pour trouver ce qu'il cherche.
Les critères peuvent être la ville, le code postal, le nom, l'identifiant. Voir même des parties de ceux-ci.
Voilà, mais si vous avez de petit volumes (et vous n'en aurez pas plus) votre méthode est acceptable.

Autre chose que je redis : Il ne faut ouvrir que les objets de données que vous utilisez ou présentez à l'écran. J'ai l'impression que vous avez plusieurs TIBTable d'ouvertes en meme temps... Est-ce indispensable ? Il faut ouvrir les objets de données lors qu'on en a l'utilité (le plus souvant lors de l'affichage d'un écran) et le fermer lorsqu'on ne l'utilise plus.

Essayez les TIBDataSet en utilisant des ordres SQL qui ciblent mieux les lignes, vous verez que vos performances s'amélioreront.

[giaco]

Bonjours,

Je suis en train de regarder dans l'aide de Builder comment se servir de TIBDataset.

Le problème est que je ne vois pas comment le connecter à une DBGrid.
C'est pour ça Barbibulle que je m'acharnait un peut sur le TIBTable.

Je suis, d'autre part en train de regarder du coté de TIBEvent qui me parrait très interressant.

Barbibulle, je tiens à te remercier grandement pour ton aide et surtout pour ta patience.

Encore un grand merci.

Cordialement,
Giaco.

[Barbibulle]

Le problème est que je ne vois pas comment le connecter à une DBGrid.

On le connecte de la même manière que le TIBTable.

TIBDataSet connecté au TIBDatabase et éventuellement à une transaction qui lui serait propre TIBTransaction.

Le TDataSource connecté au TIBDataSet par la propriété DataSet.

Et le TDataSource attaché à la grille.

Bien entendu il faut mettre un ordre select dans le TIBDataSource et autre chose qu'un SELECT * FROM MATABLE; sinon celà ne sert à rien et du point de vue performance ça ne sera guère mieux.

Je suis, d'autre part en train de regarder du coté de TIBEvent qui me parrait très interressant.

Les évènements c'est en général une fausse bonne idée. Si on ne les utilises pas bien celà risque de générer un trafique de données enorme pour rien.... Dans la grande majorité des cas ils sont innutiles (et je dirais meme que plus la base est grande et plus il y a d'utilisateurs plus il faut faire attention à son utilisation).
Je déconseille notamment de les utiliser dans le but de rafraichir automatiquement des écrans...

[giaco]

Bonjours Barbibulle,

Je tiens à te remercier pour ton aide qui m'a été d'un grand secours.

Voici la façon dont j'orriente mon développement :

* IBTable pour les petites aplications et le local

* IBDataset pour les bases distantes (en réseau).

* Utilisation des IBEvents pour et uniquement pour les petit réseaux ( 2 à 5 postes).

Et tout ceci grace à toit Barbibulle.

Je tennais donc à te remercier énormément.

Cordialement,
Giaco

[giaco]

Oups .......

Petit problème....
Je ne peux pas mêtre le tag résolut car ce n'est pas moi qui est crée ce post...

Je suis désolé...

Barbibulle, pourrais tu le metre à ma place s'il te plait ?
D'avance merci.

Cordialement,
Giaco