Ces deux instructions me semblent identiques , la première implique en plus qu'il faut que la ZConnection soit établie . De fait , pour Interbase/Firebird PingServer ne renvoie une valeur positive que si la connexion est active donc …

Attention il ne s'agit pas d'un ping « classique » sur une adresse IP (comme pingserver le suggèrerai) mais d'une opération permettant de savoir le moteur de base de données est actif . J'utilise le mot moteur a escient pour bien insister sur le fait qu'il s'agit du SGBD et non du poste hébergeant la base de données. On a souvent tendance à parler du poste en tant que serveur d'où les confusions possibles. Il est bien sur évident que sur un réseau local , si vous perdez la connexion IP vous perdrez également la connexion avec le SGBD, mais il se peut également que le SGBD soit arrêté (shutdown) ou tout simplement pas démarré !

Les deux méthodes permettent d'exécuter directement une instruction SQL , la version surchargée permet , en plus , d'obtenir le nombre de lignes affectées .

permettent d'obtenir la séquence d'échappement ?

GetURL: String;

GetNamePath : String;

Dans ce paragraphe , je ne parle pas de la création de la base de données , mais bien d'une création du composant à l'exécution (run-time) ou de modification de propriétés , par exemple la saisie ou l'utilisation d'un fichier ini pour changer les informations de connexion . Nous avons déjà vu de manière détaillée , les informations nécessaires à la connexion dans la section En pratique . Faisons maintenant au plus simple, en passant par l'intermédiaire d'un fichier .ini les données nécessaires .

[Connexion] Hote=localhost Port= Protocole=firebird-2.5 Utilisateur=SYSDBA mdp=masterkey base=c:\test.fdb

Pour cette démonstration, j'ai placé la connexion dans un module de données afin de pouvoir la partager . Le DataModule ne contient qu'un seul composant : un TZConnection et j'utilise l'événement OnCreate du DataModule pour l'initialiser .

unit Datamodule;

interface

uses
  SysUtils, Classes, ZAbstractConnection, ZConnection, inifiles;

type
  TDataModule1 = class(TDataModule)
    ZConnection1: TZConnection;
    procedure DataModuleCreate(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

var
  DataModule1: TDataModule1;

implementation

{$R *.dfm}

procedure TDataModule1.DataModuleCreate(Sender: TObject);
var F : TIniFile;
begin
F:=TInifile.Create(ChangeFileExt(paramstr(0),'.INI'));
try
  ZConnection1.Host:=F.ReadString('Connexion','Hote','localhost');
  ZConnection1.Port:=F.ReadInteger('Connexion','Port',0);
  ZConnection1.Protocol:=F.ReadString('Connexion','protocole','firebird-2.5');
  ZConnection1.Database:=F.ReadString('Connexion','base','c:\test.fdb');
  ZConnection1.User:=F.ReadString('Connexion','Utilisateur','SYSDBA');
  ZConnection1.Password:=F.ReadString('Connexion','mdp','masterkey');
finally
  F.Free;
end;
end;

end.

Que manque t-il pour créer la connexion à l'exécution ? Pas grand-chose en fait , on devra juste s'assurer de quelques points : le mode autocommit à true et du niveau d'isolation de la transaction (propriété TransactIsolationLevel mise à tiNone par défaut) . Ce dernier point nécessite l'inclusion dans les uses de ZDBcintfs

ZC:=TZConnection.Create(nil);
try
  ZC.Autocommit:=True;
  ZC.TransactIsolationLevel:=tiRepeatableRead;
… //suite des propriétés comme au-dessus

Ce dernier point me permet d'introduire le chapitre suivant

Un peu de théorie n'a jamais fait de mal et certains concepts sur les transactions doivent être connus afin de comprendre comment TZConnection fonctionne de l'intérieur et comment travailler avec. En général, vous n'avez accès à la base de données qu'à l'intérieur d'une transaction valide (« ouverte ») . Une transaction doit remplir 4 caractéristiques connues sous le nom de A.C.I.D.

Atomicité : La propriété d'atomicité assure qu'une transaction se fait au complet ou pas du tout . Si une partie d'une transaction ne peut être faite, toute trace de la transaction doit être effacée et les données remises dans l'état où elles étaient avant cette transaction. Le principe du « tout ou rien »

Cohérence : La propriété de cohérence assure que chaque transaction amènera le système d'un état valide à un autre état valide.

Isolation : La propriété d'isolation assure que l'exécution simultanée de transactions produit le même état que celui qui serait obtenu par l'exécution en série des transactions.

Durabilité : La propriété de durabilité assure que lorsqu'une transaction a été confirmée, elle demeure enregistrée.

Concrètement, une transaction encapsule un ensemble (consécutif) d'accès à la base . Par accès à la base on entend aussi bien une lecture (SELECT) qu'une écriture (INSERT, UPDATE, DELETE) ou un changement à la structure de la base (CREATE,ALTER). Une transaction est terminée par un COMMIT ou un ROLLBACK . Un COMMIT confirme tous les changements dans la base de données depuis le début de la transaction. Un ROLLBACK remettra la base de données à son état d'avant la transaction.

En résumé , des transactions s'exécutant sur un serveur doivent être isolées les unes des autres, de façon a être indépendantes.

En utilisant divers niveaux d'isolation (TIL pour Transaction Isolation Level) un développeur peut protéger les données d'un ensemble de données, résultat d'une requête, de l'accès par d'autres transactions. Ce comportement, le plus standard, est connu sous le nom de SERIALISABLE (l'état d'isolation le plus proche avec Firebird est connu sous le nom de SNAPSHOT) .

Comme je l'ai écrit lors de la présentation du composant TZConnection , dès la création de la connexion une transaction est incluse . Du point de vue des auteurs c'est tout à fait logique car tout accès à une base de données doit se faire via une transaction . Dès que la connexion à la base de données est ouverte (méthode Connect) la transaction est démarrée. Chaque accès à la base est fait à l'intérieur de cette transaction et ce automatiquement . Ce comportement est nommée l'autocommit (propriété autocommit vrai par défaut) , ce qui correspond au comportement standard du composant BDE correspondant. Donc , si autocommit est activé, chaque changement à la base de données sera confirmé (COMMIT) après une exécution réussie.

Cependant , ce comportement peut être désactivé en démarrant de manière explicite une transaction via la méthode StartTransaction . A l'intérieur de cette transaction il est alors possible d'exécuter un ensemble d'instructions SQL qui seront ensuite confirmés par la méthode Commit. Appeler la méthode Rollback annulera toutes les opérations.

Retaining

Généralement, après la confirmation d'une transaction via un Commit ou l'annulation via un Rollback la transaction est, normalement, terminée et l'ensemble de données résultats d'une requête ou d'une procédure est jeté. Cela s'appelle le « hard commit » ou « hard rollback ».

Avec la bibliothèque ZEOS ce comportement est légèrement différent , ZEOS garde l'ensemble de données « en vie » . Ceci est fait en terminant la transaction non pas en « hard » mais en « soft » COMMIT ou ROLLBACK , ce mode est le mode « Retaining ».De fait, les commits ou rollbacks d'une transaction Zeos sont faits avec ce mode par défaut, cela s'effectue , de manière transparente, en ré-ouvrant ,tout de suite après la fermeture de la transaction, une nouvelle transaction avec toutes les données et ressources (en particulier les ensemble de données résultants) de la « vieille » transaction.

Cependant le mode retaining peut devenir un problème sur de grosses tables .

Par exemple , ce mode empêche le mécanisme de nettoyage interne de Firebird (garbage collection) ce qui amène a un surcroît d'anciennes données gardées mais inutilement . De part là même cela pénalisera les performances du serveur, qu'un nettoyage (sweep) aurait géré. Mais ce « sweep » n'est fait que en « hard » commit ou rollback , ce que ZEOS ne fait qu'à la fermeture de la connexion . Un contournement possible serait donc de fermer puis rouvrir la connexion régulièrement !

Niveaux d'isolation de la transaction d'une TZConnection (T.I.L.)

Le composant TZConnection fourni des TILs prédéfinis :

tiRepeatableRead

Correspond au « SNAPSHOT » (standard des serveurs Firebird) . C'est une combinaison des paramètres de transaction « concurrency » et « nowait » . Un cliché de la base de données est fait . Les autres utilisateurs sont seulement contraints si deux transactions travaillent en concurrence sur un même enregistrement . Si un conflit est détecté , un message d'erreur sra renvoyé , les changements à l'intérieur des autres transactions dûment notifiés . Ce mode couvre largement le standard SQL nommé « SERIALIZABLE ».

tiReadCommitted

Correspond au mode « READ COMMITTED ». C'est une combinaison des paramètres « read committed » , « rec_version » et « nowait » . Ce niveau prend en compte tout changement validé par d'autres transactions (COMMIT). Le paramètre « rec_version » indique l'on doit prendre compte les valeurs les plus récentes validées par d'autres utilisateurs , « no_wait » qu'il n'y a pas de délai avant de libérer un enregistrement verrouillé.

Ce mode sollicitera d'avantage le serveur car il aura besoin de rafraîchir très souvent les données.

tiSerializable

Correspond au mode « SNAPSHOT TABLE STABILITY » , utilisé pour obtenir un accès exclusif à l'ensemble de données. Obtenu par le biais du paramètre de transaction « consistency » il pare à l'accès aux données de tout autre transaction. Seule la transaction qui a écrit les données peut y accéder, ce qui empêche également tout autre utilisateur d'accéder aux données écrites.

Ce niveau , très restrictif, doit être utilisé avec précaution.

tiNone

Aucun niveau d'isolation pour la transaction

tiReadUncommitted

bien qu'existant , ce dernier n'est pas reconnu par Firebird, l'utiliser lèvera uneerreur et la transaction ne sera pas isolée (comme avec tiNone).

Il est enfin possible de faire ses propres niveaux ou en modifier un existant. On peut le faire en utilisant les paramètres de la TZConnection . Pour ce faire , il vous faudra consulter les documents de référence des API de votre SGBD . Ci-dessous , un exemple de personnalisation à partir de tiNone pour Interbase/Firebird

ZConnection1.TransactIsolationLevel := tiNone;
ZConnection1.Properties.Add('isc_tpb_concurrency'); 
ZConnection1.Properties.Add('isc_tpb_wait'); 
ZConnection1.Connect;

La théorie c'est bien , mais souvent indigeste , passons donc a un peu de pratique

Je vous engage fortement à lire le fichier (pdf ou html) fourni dans le sous répertoire doc de l'installation de la ZEOSLIB. En effet chaque SGBD a ses propres paramétrages.

Le remplissage de ces dernières (il s'agit d'une TStrings) se fait soit au moment du design soit par programme, on ne mettra qu'une propriété par ligne.

Un seul est commun le paramètre defaults=[yes,no] permettant d'indiquer si les valeurs pas défauts doivent être calculés pour les champs NULL . Cependant ce dernier pourra être invalidé par le paramètre au niveau de TZQuery .

Zconnection1.Properties.Add('defaults=yes') ;
// ou encore
Zconnection1.Properties.Values['defaults'] :='yes' ;

Pour Interbase/Firebird on trouvera ces propriétés :

• RoleName=<nom du role> . Permet d'indiquer le role à utiliser pour travailler avec la base de données et ainsi d'avoir les privilèges de ce dernier.

• hard_commit=[yes,no] - Use hard commits instead of soft commits.

  Plus annecdotiques de mon point de vue , mais peut être utiles :

• codepage=<nom de la langue> - Si cette langue est installée pour le SGBD alors les messages d'erreurs seront revoyés dans cette langue.

• Dialect=<1,2,3> c'est le paramètre du dialect SQL d'Interbase/Firebird.

• CreateNewDatabase=<commande sql de création de la base de données> - Crée la nouvelle base de données décrite dans le TZConnexion, avant d'ouvrir celle-ci.

 ZConnection1.Properties.Add ('CreateNewDatabase=CREATE DATABASE ' +
 QuotedStr ('c:\test.fdb') + ' USER ' + 
 QuotedStr ('sysdba') + ' PASSWORD ' + QuotedStr ('masterkey') +
 ' PAGE_SIZE 4096 DEFAULT CHARACTER SET ISO8859_1');}
try
 Zconnection1.Connect;
 Zconnection1.Disconnect ;
 Zconnection1.Properties.Clear;
 IntroMemo.Lines.Add('Création réussie') ;
 Zconnection1.Connect;
 IntroMemo.Lines.Add('Connexion à la base créée') ;

except
   Intromemo.Lines.Add('la création à échoué') ;
end ;
end;

D'aucun se pose la question de l'utilité de ces instructions , qui ne font que changer la propriété Active à True ou False respectivement, je dirais que ce n'est qu'une question de style. Dans les deux cas , c'est une action à effectuer sur un ensemble de données (SELECT) , à contrario de l'instruction suivante.

On l'utilisera chaque fois que l'instruction SQL ne renverra aucun résultat (DELETE,UPDATE).

Pour quoi faire ? En fait c'est en relation avec la valeur de FetchRows pour plus d'informations allez dans Le coin du mécano

Prepare

Prepared

UnPrepare

ParamByName()

First, FindFirst

Next, FindNext

Prior, FindPrior

Last, FindLast

Locate

Lookup

Insert

InsertRecord

Append

AppendRecord

Edit

Post

Cancel

RevertRecord

RefreshCurrentRow

Les relations maître détail

Encore une fois , je vous invite à vous référer à la documentation du package (<répertoire de ZEOSDBO>\doc\html\parameters.html ou …\doc\pdf\parameters.pdf)

Deux de ces propriétés sont applicables quelque soit le SGBD :

defaults=[yes,no] - Calcule ou non les valeurs par défaut indiquées pour les champs NULL. Nous avons déjà vu ce dernier pour la TZConnection , la propriété indiquée dans le TZQuery sursoit alors celle qui aurait pu être indiquée pour le TZConnection mais ce , uniquement pour ce composant.

ValidateUpdateCount=[true,false] - Vérifie que la Clause UpdateSQL générée par le composant ZUpdateSQL (ou plus exactement son wizard) affecte une seule ligne. Je vous convie à lire le chapitre TZUpdateSQL, si ce n'est déjà fait .

Deux autres sont spécifiques à Interbase/Firebird :

cursor=<nom du curseur> - Le nom indiqué sera envoyé au serveur de base de données afin de l'utiliser. Pratique pour le monitoring Firebird par exemple (tables MON$xxxxxx)

cashedblob=[yes,no] -Indique si les données contenues dans les blobs seront récupérées immédiatement [yes] ou par l'intermédiaire des API d'Interbase/Firebird [no] .

Attention , FetchRows ne veut pas dire lecture d'un nombre déterminé d'enregistrements , ce que l'on obtient avec une requête Firebird ainsi

SELECT FIRST 10 FROM UNETABLE

Mais plutôt d'un nombre d'enregistrements par paquet envoyé sur le réseau . Si cette propriété est intéressante pour diminuer le trafic (seuls les enregistrements nécessaires transitent) elle peut avoir des effets de bords inattendus : la valeur de recordcount sera « inexacte » , le curseur vertical d'une DBGrid est fonction du nombre de lignes lues et non de la totalité des lignes de la table.

Pour illustrer ce point, rien ne vaut un petit exemple . Pour cela nous allons interroger une table contenant 19 lignes pour l'afficher dans une grille de 5 lignes . Un SpinEdit , permet de régler la valeur FetchRow avant ouverture de la table , le mémo et quelques gestions d'évènements (AfterOpen et AfterScroll) permettront de tracer le nombre d'enregistrements dans le DataSet , un navigateur complète le tout .

procedure TZQForm.FetchRownBtnClick(Sender: TObject);
begin
if ZQCeintures.Active then QCeintureMemo.Lines.Add('Fermeture de la table');
ZQCeintures.Active:=False;
ZQCeintures.FetchRow:=nbRows.Value;
QCeintureMemo.Lines.Add(Format('Ouverture de la table , FetchRow=%d',[nbRows.Value]));
ZQCeintures.Active:=True;
end;

procedure TZQForm.FetchAllBtnClick(Sender: TObject);
begin
ZQCeintures.FetchAll;
QCeintureMemo.Lines.Add(Format('FetchAll RecordCount = %d',[ZQCeintures.RecordCount]));
end;

procedure TZQForm.ZQCeinturesAfterScroll(DataSet: TDataSet);
begin
QCeintureMemo.Lines.Add(Format('Event AfterScroll RecordCount = %d',[ZQCeintures.RecordCount]))
end;

procedure TZQForm.ZQCeinturesAfterOpen(DataSet: TDataSet);
begin
QCeintureMemo.Lines.Add(Format('Event AfterOpen RecordCount = %d',[ZQCeintures.RecordCount]))
end;

Étudions le résultat de l'exécution si FetchRow à la valeur 2 (donc inférieure au nombre de lignes espérée pour la grille)

Malgré (et heureusement) notre demande 5 lignes ont été retournées , le déplacement à l'intérieur de la grille (via le navigateur) , nous montre le comportement suivant

Nous remarquons que , tant qu'il n'y a pas besoin de lecture (dans notre cas jusqu'à 5) , rien n'est fait , puis au fur et à mesure du déplacement le nombre d'enregistrements dans l'ensemble de données augmente . Bref , tout serait parfait sans ce petit « défaut » de la DBGrid (regardez la taille du curseur de la barre verticale de cette dernière) .

Que se passerait-il dans le cas où la valeur de Fetchrow dépassait le nombre de lignes nécessaires ? Comme vous le devinez certainement , c'est le nombre d'enregistrements demandés qui serais renvoyé .

Pour faire bonne mesure , rajoutons une opération de recherche

Pas de surprise , l'enregistrement sera bien trouvé , le nombre d'enregistrements lu ,par contre, dépendra de deux facteurs : la position du curseur (tiens , le revoilà) dans la base de données et, bien sur la valeur de Fetchrow.

Si pour un nombre d'enregistrements peu important la propriété FetchRow à peu d'importance , pour une table de taille importante je vous laisse imaginer les avantages sur le trafic réseau.