Discussion :

[tarmo57]

Re Salut tous encore un problème qui me prend la tête.

j'ai une table Paradox un query pour faire une requête update

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 with DataModule2.Query9 do
begin
SQL.Clear;
SQL.Add('Update TABLE.db set Champs1 = '+ QuotedStr(Champs1.Text)
+' where Idtable ='+ QuotedStr(Idtable .text)+'');
 Prepare;
ExecSQL;
end;
end;
DataModule2.Query9.Active:=true;
DataModule2.Query9.Active:=false;

Mon query a l'origine est active sur false
j'ai comme message

erreur à la création du handle de curseur

merci a l'avance ,mais j'aimerais bien comprendre cette erreur

[SergioMaster]

l'erreur doit se situer au niveau du DataModule2.Query9.Active:=true;
un SQL UPDATE ne renvoie aucune valeur

PS . Il aurait mieux valu indiquer le code comme [ code ] non comme [ quote ] ce qui aurait permis d'indiquer le n° de ligne

[jaduta]

slt,

personnellement, je n'effectue jamais des MAJ dans une table paradox via une requête sql...

utilise plutôt un TTable connecté à la table paradox.
tu te positionnes via le FindKey
ensuite, tu passes en mode modification grâce à Edit
et tu commites la MAJ avec Post

Code :

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

1
2
3
4
5
if TTable.Findkey[(Strtoint(Idtable.text))] then begin
TTable.Edit;
TTable.fieldbyname('Champs1').asstring := QuotedStr(Champs1.Text);
TTable.Post;
end;

[SergioMaster]

personnellement, je n'effectue jamais des MAJ dans une table paradox via une requête sql...

Très mauvais choix
la raison :
dans ce cas tu es obligé d'ouvrir TOUTE la table (donc récupérer TOUTES les données ) pour pouvoir faire le Findkey sur UN enregistrement et ensuite le modifier.
Dans une Query seuls les enregistrement sélectionnés sont modifié directement

de plus tarmo57 veut mettre a jour un certain nombre d'enregistrements , pas un seul ta solution (via ttable) devrait en plus fournir une boucle while not EOF etc.... plus un test (ou un filtre ) ou passer via une Query (ou en en revient aux requêtes)
mais toujours avec une boucle

Toujours convaincu que le triplet Findkey,Edit,Post est le bon moyen ?
est-ce que cela changera tes habitudes ?

NB. Au fait , le prepare de la ligne 6 est de trop (merci a ANDNOTOR pour la modif de balise

[ALWEBER]

Pour répondre à la question initiale :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
procedure TForm1.Button1Click(Sender: TObject);
var
  st1, st2 : string ;
begin
  St1 := '2' ;
  St2 := 'ABCD' ;
  Query1.DatabaseName := IncludeTrailingBackslash(ExtractFilePath(Application.ExeName)) ;
  Query1.SQL.Text := 'Update maTABLE.db set Champs1 = '+ QuotedStr(st2)
   +' where Idtable = ' +st1+'';
  Query1.execSQL ;
end;

voir exemple avec table ci-joint

[jaduta]

Pour le principe théorique, je suis d'accord avec toi.
Par contre pour la pratique, ce n'est pas totalement ca.

Nous utilisons les tables paradox, comme table locale, juste des petites tables, maximum 100 lignes par table...

Pour les tables plus conséquentes, il faut utiliser un SGBD...
Et un query sur plus de 100 000 données est plus lent qu'un positionnement sur une table indexée, malgré une boucle
donc merci Findkey ou findnearest + edit + post

[ALWEBER]

Pour le principe théorique, je suis d'accord avec toi.
Par contre pour la pratique, ce n'est pas totalement ca.

Nous utilisons les tables paradox, comme table locale, juste des petites tables, maximum 100 lignes par table...

Pour les tables plus conséquentes, il faut utiliser un SGBD...
Et un query sur plus de 100 000 données est plus lent qu'un positionnement sur une table indexée, malgré une boucle
donc merci Findkey ou findnearest + edit + post

Ceci était effectivement une réponse à la demande initiale. Etant très spécialisé Paradox je suis d'accord avec ce que tu dis

[ALWEBER]

Très mauvais choix
la raison :
dans ce cas tu es obligé d'ouvrir TOUTE la table (donc récupérer TOUTES les données ) pour pouvoir faire le Findkey sur UN enregistrement et ensuite le modifier.

Tu as besoin d'un bon cours sur Paradox ! Le FindKey se fait sur le fichier "PX" clef primaire et non sur la table "DB". D'autre part seules des portions de fichier sont utilisés. Les fichiers .lck et pdoxusr.net gèrent en mode collaboratif l'accès partagé aux fichiers composant une base de données Paradox. J'ai pas mal de docs sur le sujet dont une partie des brevets déposés par Borland

[SergioMaster]

Bien , je vais donc faire un méaculpa au vu de ces assertions

A ma décharge , je n'utilise plus Paradox depuis .... pff quasiment le siècle dernier , et puis je me permettre de vous rappeler que BDE n'est plus maintenu depuis presque aussi longtemps ?
Peut être en une dizaine d'année ai-je pris de mauvaises habitudes ( boutade) à développer des applications gérant + de 100 enregistrements

Accessoirement , l'erreur sur le handle (le but de la discussion) reste du à la ligne 10 et pas sur le SQL à proprement parlé

[ALWEBER]

Bien , je vais donc faire un méaculpa au vu de ces assertions

A ma décharge , je n'utilise plus Paradox depuis .... pff quasiment le siècle dernier , et puis je me permettre de vous rappeler que BDE n'est plus maintenu depuis presque aussi longtemps ?
Peut être en une dizaine d'année ai-je pris de mauvaises habitudes ( boutade) à développer des applications gérant + de 100 enregistrements

BDE non maintenu depuis le siècle dernier. On est d'accord ! Ceci dit tu utilises la roue ou le levier aujourd'hui sans que ces outils soient maintenus par leurs inventeurs. Si l'outil remplit sa fonction, pourquoi ne pas l'utiliser. Je considère, bien que l'on soit dans le monde souvent virtuel de l'informatique nous devons avoir des gestes eco-citoyens. Et le principe collaboratif de cet outil, si il n'est pas adapté à certaines applications, va dans ce sens en minimisant les serveurs consommateurs d'énergie. Pourquoi développer des usines à gaz lorsque l'on peut faire simple.
Volumétries gérées avec Paradox constatées chez des clients > 2 000 000 d'enregistrements, 300 utilisateurs connectés à la même base en même temps...

[ShaiLeTroll]

Vous partez sur un débat de volumétrie et d'accès réseau, mais on ignore la situation de tarmo57 à ce sujet !
On ne sait même pas si il a mis dans Index et donc conditionne l'utilisation de Findkey
On ne sait pas d'ailleurs, si il utilise des TTable ou TQuery dans son programme pour lire les données, cela conditionne forcément la méthode de mise à jour !

Il y a eu de gros débats sur Paradox\BDE en multi-utilisateurs, comme lenteur du BDE ou Table Paradox et saturation avec les excellentes remarques de ALWEBER sur le déploiement en réseau qu'avec BDE bien configuré en NetDir\WorkDir et serveur de fichier SAMBA, je n'ai d'ailleurs toujours pas eu ma réponse à la question "100 Utilisateurs en simultané sur une table de 2 Millions d'enregistrements, les temps de lecture et écriture sont de combien ?"
Comme tu sembles toujours baigné dedans, ça m'intéresse de savoir combien il faut pour trouver une ligne sur un champ chaine indexé unique avec une telle configuration Paradox !
Moi qui trouvait cela trop lent en Local !

[ALWEBER]

... Comme tu sembles toujours baigné dedans, ça m'intéresse de savoir combien il faut pour trouver une ligne sur un champ chaine indexé unique avec une telle configuration Paradox ! ....

Je vais travailler prochainement sur une base INSEE avec des volumétries similaires disponible dans deux formats ORACLE et PARADOX. Je ferai un BenchMark et mettrai à disposition le résultat.

[tarmo57]

ok merci tous ,merci ALWEBER ok pour les mises a jour