Rafraichissement des données sql serveur entre clients /serveur

[ROMILA]

bonjour

Je développe une application client serveur (langage de programmation Delphi le moteur de base de donné SQL serveur édition standard 2005 ) le serveur sur la pc et les client sur des machines virtuel ,la connexion est bonne mais mon problème est le suivant :
Les modifications des données des tables des postes client ne figure pas dans la machine serveur sauf si je rafraichie la base du coté serveur ( tous ce que je veux que les modifications soit rafraicher automatiquement entre les postes client et le serveur )
Merci d’avance

[SQLpro]

Tout dépend comment vous avez programmé et quels objets vous avez utilisé dans Delphi.
Par exemple avec des client dataset, ce serait normal.

A +

[ROMILA]

BONJOUR

J’ai programmée avec Delphi
Les composants utilisés :
Ttable,
DataSource
Database
Session
StoredProc

[SQLpro]

Il ne faut pas utiliser les TTable. Un SGBDR C/S travaille par requête SQL, pas table par table.

A +

[ROMILA]

Bonjour
Monsieur je demande votre conseil, d’ai développée un logiciel avec delphi avec ttable, et voila que je m’affronte au problème cité au dessous,
Dit moi Monsieur comment je peux transformer mon logiciel de ttable à sql sachant que j’ai travail le corps de programme a 90 % sous les événements de ttable .
D’une manier rapide
Merci a l’avance
(Désolée si j’ai pris le temps de répondre problème d’électricité avec toute cette neige)

[SQLpro]

Il faut les changer en TQuery.

Demandez de l'aide sur le forum DELPHI.

A +

[ShaiLeTroll]

En Paradox, un TTable ouvert n'appliquait pas les données tant que l'on a pas fait un Close() ou un FlushBuffers !
En Interbase, j'avais tout remplacer par des TQuery à coup de SELECT, INSERT, UPDATE... du SQL !

Sinon le BDE c'est obsolète depuis 10 ans !
Tous les ans Thierry Laborde fait son discours sur comment remplacer le BDE par DBExpress !

Comme cela utilise ODBC en interne, tu devrais migrer vers ADO et TADOQuery !
Vu que tu dois passer en SQL, autant changer le fournisseur d'accès au passage !
Attention, c'est vraiment une autre méthode de programmation !
C'est un gros chantier !

Ensuite pour le rafraichissement, si tu as une modification sur le Poste A, j'ignore les mécanismes SQL Server à ce sujet, mais le Poste B doit relancer le SQL, c'est d'ailleurs tout la problématique des accès concurrentiel, deux Poste ouvre la même fiche, la modifie, selon la configuration des transactions et des mise à jour, cela peut refuser la 2nde modification car les données sont obsolètes et nécessite une réconciliation !
Le Edit\Post du TADOQuery vont gérer la réconciliation plus ou moins facilement comme dans le sujet : insert DBGrid avec TADOQuery et requete avec jointure
Personnellement, je préfère un ClientDataSet qui permet les modifications purement locales et générer moi même le SQL (par une couche métier et une couche OR) pour une meilleure maîtrise des flux et optimisations !



en InterBase, il y a un système de Notification si je ne me trompe pas, il faudrait un équivalent SQL Server, si ça existe

[ROMILA]

Bonjour
Une question : est ce que je peux travail (client/ serveur) sans utiliser le langage SQL ?.
Pour ne pas refaire tous le travail je transforme BDE à ADO est ce que c’est une bonne décision
Merci a l’avance

[akli_agha]

En Client/Server, je ne pense pas que les tables soient les composants les plus adéquats ! Le langage SQL s'y prête nettement mieux et, donc, mérite le temps que ça prendra.

NB : On est tous passé par les TTables !

[ROMILA]

Merci
Je vais apprendre le SQL.
A bien tôt

[ROMILA]

J’ai fais un petit exemple,
Langage DELPHI 7, Moteur de base de données SQL Server 2005,
Les composants : ADOConnection1, ADOQuery1, DataSource1
J’ai créé 2 exécutables : un copy dans la machine virtuel et l’autre dans la machine principale,
Le code source est le suivant

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
With ADOConnection1 do
 begin
Connected:=FALSE;
ConnectionString:='Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=CHRONOEXEMPLE;Data Source=PC-DE-XXXX;
Connected:=true;
End;
with ADOQuery1 do begin
SQL.Add('SELECT * FROM ST_FART');
Connection:=ADOConnection1;
CursorLocation:= clUseServer;
LockType:= ltOptimistic;
CursorType:=ctKeyset;
Active:=true;
Edit1.Text:=fields[1].Value;
end;

Et pour le bouton modifier

Code :

1
2
3
4
5
6
7
procedure TForm1.Button2Click(Sender: TObject);
begin
with ADOQuery1 do begin
Edit;
fields[1].Value:=Edit1.Text;
Post;
end;

NB : quand je modifier dans l’application client, les modifications ne se voie pas sur la partie serveur

[akli_agha]

Je ne travaille pas avec SQL Server mais, à mon avis, il te manque un Commit et un refresh sur la machine distante !

[SergioMaster]

Bonjour,
Moi je dirais que c'est plus complexe que ça , mais je ne suis pas un fan D'ADO .

Tout d'abord merci d'encapsuler le code (balises CODE, /CODE faite par le bouton #)

Remarques

1. Pourquoi ne pas utiliser un DBText a la place d'un Edit1
2. As tu fais un essai avec un UPDATE ?
3. Un 'SELECT * FROM ST_FART' renvoi tous les enregistrements donc autant utilisé un ADOTable
4. avec un SELECT il est préférable d'indiquer les champs que l'on veut récupéré plutôt que d'utiliser le *
5. La table a t'elle une Clé

Je suis sur qu'il y a un tutoriel avec ADO

[Klemsy78]

Selon la méthode que tu utilise, je pense qu'il te faut faire un Post, puis un refresh sur le composant AdoQuery après chaque mise à jour.

[BuzzLeclaire]

Envoyé par SergioMaster

Bonjour,
Moi je dirais que c'est plus complexe que ça , mais je ne suis pas un fan D'ADO .

Moi j'en suis fan.. lol, salut Serge.

@ROMILA
Pour ton problème réseau, essai un open close (plutot qu'un active true/false), pour voir.

Sinon utilise plutot clUserClient pour ton cursorLocation.

@+

[ROMILA]

Merci pour toutes les réponses
Pour activer désactive la base à chaque foi c pas intéressant, sur tous dans la programmation client/ serveur.
Mais pour l’utilisation de clUserClient je vais voire

[archonte]

Je pense qu'il faudrait séparer l'initialisation des composants ADOConnection et ADOQuery d'une part et les méthodes de sauvegarde / récupération des données de l'autre.

Dans l'exemple proposé ('J’ai créé 2 exécutables') par ROMILA je dirais que l'initialisation à lieu dans une méthode de récupération de données (cf. 'SELECT * FROM ST_Fart'), mais la méthode de sauvegarde n'en connait rien.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// { 1 } dans le Form.Create ou dans un DataModule, par exemple :
With ADOConnection1 do
begin
  Connected := FALSE;
  ConnectionString := 'Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=CHRONOEXEMPLE;Data Source=PC-DE-XXXX;';
  // chaine de connexion non vérifiée !
  Connected := TRUE;
End;
 
with ADOQuery1 do 
begin
  Close; // toujours travailler sur une Query fermée !
  Connection := ADOConnection1;
  CursorLocation := clUseServer;
  LockType:= ltOptimistic;
  CursorType:=ctKeyset;
end;

Code :

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
// { 2 } la méthode de récupération
procedure TForm1.GetData;
begin
  with ADOQuery1 do
  begin
    Close;
    SQL.Text := 'SELECT MonChampUn FROM ST_FART'; // avec SQL.Add() il faut faire un Clear avant usage !
    Active := TRUE;

    // tester si au moins un enregistrement récupéré (penser à formuler une requête SELECT plus restrictive : avec une clause WHERE par exemple !
    if RecordCount > 0 then
    begin
      // traitement si présence d'au moins un enregistrement
      // aller au premier enregistrement
      Fields.DataSet.FindFirst;
      // récupérer la donnée
      (* ? penser à traiter le cas avec plusieurs enregistrements retournés par la requête ? *)
      Edit1.Text := FieldByName('MonChampUn').AsString;
    end else
    begin
      // traitement si pas d'enregistrement
      Edit1.Text := ''; // vider le champ texte de Edit1 ?
    end;
  Close; // fermer ADOQuery1
  end;
end;

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
// { 3 } la méthode de sauvegarde
procedure TForm1.SaveData;
begin
  with ADOQuery1 do
  begin
    Close;
    SQL.Text := 'INSERT INTO ST_Fart ('MonChampUn') VALUES (':PUn');' // utilise INSERT INTO ... avec du SQL, et pourquoi pas les parametres !
    ParamCheck := true;
    Parameters.ParamByName('PUn').Value :=  Edit1.Text;
    ExecSQL; // et non Active := True pour un INSERT !
  end;
end;