Discussion :

[HASSIOMAR]

Bonjour à tous,

Je viens de quitter BDE pour aller vers INTERBASE plus stable et C/S. Mais malheureusement je rencontre quelques difficultés.

1) Comment lire directement un enregistrement avec une clé en INTERBASE ?

A) En paradox je fais : Table1.FindKey([DBEDIT1.TEXT,DBEDIT3.TEXT]).
Quel est son equivalent en INTERBASE ?

B) En paradox je fais : Table3.FindNearest([DBEDIT1.TEXT,DBEDIT3.TEXT]);
Quel est son equivalent en INTERBASE ?

C) En paradox je fais : Table3.IndexName:='XLIBE'; // INDEX SECONDAIRE
Quel est son equivalent en INTERBASE ?

D) En paradox je fais : Table3.IndexName:=''; // INDEX PRIMAIRE
Quel est son equivalent en INTERBASE ?

Merci à tous ceux qui nous aide .

[MonPc]

Bonjour,
Si tu utilise les composant IBX , tu a IBquery et faire des requettes.
bon courrage.

[HASSIOMAR]

Avec IBquery je dois filtrer pour une certaine clé puis tester si la recherche est true ou false, ça mache de cette maniére. Quand la table est de taille
réduite le temps de réponse est acceptable , mais si la table est volumuneuse
je crois que la recherche sera longue , n'est ce pas ?

Mais moi je veux accéder directement à une IBtable comme je l'ai toujours fait
avec BDE , DBASE IV ou COBOL. Possible ou non ?

Si j'ai bien compris en INTERBASE on doit toujours utiliser les requêtes via
IBquery pour accéder au données de IBtable. D'ailleurs c'est ce que je fais
pour le moment car je n'ai pas d'autre choix. "A DEFAUT DE GRIVES ON MANGES DES MERLES ".

Merci pour m'avoir diriger vers IBquery , c'est tjrs utile de faire des requêtes.

[MonPc]

bon soir ,
il ne faut pas oublier l'utilisation des Procedures stockés.
Lien utile :

http://levieux.developpez.com/tutops...s/tutopsib.pdf

bon courage.

[SergioMaster]

FAUTE DE MERLES MANGEONS PLUTÔT DES GRIVES

C'est plutôt ainsi qu'il faudrait voir les choses lorsque l'on parle de Query (je devrais plutôt dire SQL) et d'environnement C/S .

Je vais essayer de démontrer cela , en schématisant et grossissant un peu les traits

Que fais le BDE ou un IBTable (d'ailleurs) ils sélectionnent tous les enregistrement d'une table se trouvant sur le Disque Dur pour les envoyer en mémoire sur le Client (vous remarquerez donc une forte augmentation du trafic réseau non ? ) bref c'est l'équivalent d'une query
SELECT * FROM MATABLE ORDER BY UNINDEX (n'oublions pas l'index pour faire comme BDE, ce qui répond déjà a une question )

A contrario en utilisant un SQL , bien écrit cela s'entend , on ne demandera au serveur que les champs (ou colonnes si l'on parle d'une SGBD) et les enregistrements (ou lignes 'raws') nécessaires
SELECT A1,A2,A3 FROM MATABLE WHERE MESCONDITIONS ORDER BY MON INDEX

ce qui bien entendu , fera un trafic moindre sur le réseau et moins de travail pour le serveur

voici un test "simple" prenez un grosse table de 1000000.... enregistrements et recherchez à l'intérieur de celle-ci un enregistrement particulier (le fameux findkey que l'on remplace par un Locate )
Que se passe t-il sur le réseau ?
Avec IBTable
le serveur envoi toute la table sur le client et le client fait sa recherche
Pour moi ceci est un merle

Avec une Query
le serveur n'envoi que l'enregistrement demandé . Oui , mais me demanderez-vous : "et le choix de l'index" , et bien c'est le serveur qui s'en charge selon votre clause WHERE (ou selon le PLAN que vous avez indiqué mais là , je m'égare)
: "Et si l'enregistrement n'existe pas" , et bien les valeurs retournées seront égales à null , un simple test après le open suffira à savoir si l'enregistrement demandé existait ou non .
pour moi ceci est une grive

Pour vraiment vous en convaincre , faites l'essai avec un VPN et non en réseau local et comparez les temps de réponse


Cette petite démonstration répondant même aux questions posées

A : SELECT .... FROM ... WHERE
C,D: SELECT .... FROM ... WHERE .... ORDER BY .....

Reste B qui restera avec un Locate (je doit avouer que j'utilise très peu)

[seabs]

Bonjour,

Question complémentaire à @SergioMaster.

Je suis convaincu depuis longtemps par l'efficacité de SQL. Cependant, je me pose une question depuis quelque temps.

Sans faire une utilisation importante de Locate, il m'est parfois nécessaire pour me positionner sur un enregistrement dans un Grid.

Supposons que je fasse la requête suivante :

Code :

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

Select Col1, col2, Col3 From Table Where Condition Order By Col1

La condition représente 10 enregistrements présentés sur 1000 enregistrements présents dans la base. Ils sont numérotés de 1 à 10 dans la col1.

Si je fait

Code :

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

Query.Locate('Col1', 5, [])

quel va être le trafic sur le réseau ?

Les 10 premiers enregistrements étant en mémoire, le Locate ne va parcourir que les 10 présents en mémoire ou va-t-il charger toute les enregistrements de la base (1000 dans le cas présent) pour retrouver le n° 5.

Personnellement, je pense qu'il va se limiter au 10 présents en mémoire, mais je voudrais bien que tu me confirmes ou m'infirmes mon raisonnement.

D'autre part, existe-il une autre méthode pour se positionner sur l'enregistrement d'un Grid sans utiliser Locate ?

Merci de ta réponse.

[Rayek]

Personnellement, je pense qu'il va se limiter au 10 présents en mémoire, mais je voudrais bien que tu me confirmes ou m'infirmes mon raisonnement.

Je te confirmes ce que tu penses

D'autre part, existe-il une autre méthode pour se positionner sur l'enregistrement d'un Grid sans utiliser Locate ?

Pour ma part, je n'ai pas connaissances d'un autre moyen (First, Une boucle avec un next + comparaison sur le champ )

[seabs]

Bonjour,

@Rayek

Merci pour ta réponse, ainsi qu'à tous ceux qui sont intervenus sur ce sujet. J'ai acquis une confirmation qui m'évitera de me poser des questions lorsque j'utilise Locate

A plus