[FB1.5][IBX] Paramètres ISC_TPB_ [Résolu]

[Cl@udius]

Bonjour

Dans une application Delphi utilisant les compos IBX pour accéder à ma base, après lecture de cet excellent article de PierreY chez Firebird-fr, j'ai défini les paramètres de la transaction ainsi:

Code :

1
2
3
4
 
isc_tpb_write
isc_tpb_consistency
isc_tpb_wait

En réalité ce compo IBTransaction est lié à un compo IBStoredProc. La PS en question me renvoie un n° unique (N° de commande en l'occurrence). Celle-ci construit ce n° en accédant à une table COMPTEUR.

J'aimerais savoir si ces paramètres me garantirons de me prémunir d'accès simultanés sur la table COMPTEUR qui aurait pour concéquence de renvoyer des n° identiques.

Bref, accès concurrentiels ou pas, et est-ce la bonne méthode ou pas ?

@+ Claudius

[makowski]

ben non pas forcément
mais on a déjà répondu X fois à ce genre de question, je ne vois pas pourquoi à chaque fois vous voulez tous réinventer la roue
il y a deux documents qui traitent de cette question et qui apportent des solutions


http://www.ibobjects.com/docs/ti_AuditableSeries.ZIP

et

http://octobinz.developpez.com/artic...e/generateurs/

[Cl@udius]

Réinventer la roue, sûrement pas !

J'avais déjà lu l'article sur les incréments purs qui est assurément une bonne méthode pour numéroter des documents tels que des factures.

Cependant je ne suis pas à la recherche d'un tel incrément. Peu importe si il y a des trous dans la numérotation.
Les pièces que je dois numéroter possèdent un format un peu particulier: Annee+Mois+Incrément. L'appel d'un GEN_ID via un trigger ne peut satisfaire à cette demande.

Donc mon soucis reste de pouvoir m'assurer d'un accès exclusif à ma table COMPTEUR.

N'utilisant les composant IBObjects je regarderais plus tard en détail ce projet exemple.

Claudius

[Yurck]

Bonjour,

Tu veux un accès exclusif à une table de numérotation.
Moi j'enregistre mon nouveau numéro formater comme le tien (annee mois itération dans le mois) dans une table sur une procédure stockée qui me retouorne le nouveau numéro valide.
Dans cette table ce numéro fait partie d'un index unique donc si un autre appel à cette procédure tente d'enregistrer le même numéro il a le droit à une violation de clef et alors je traite cette vialoation dans ma procédure pour demander un nouveau numéro.

Ce n'est pas plus compliqué que d'attendre qu'un table soit libéré en écriture.

a+

[makowski]

Envoyé par Claudius40

Les pièces que je dois numéroter possèdent un format un peu particulier: Annee+Mois+Incrément. L'appel d'un GEN_ID via un trigger ne peut satisfaire à cette demande.

et pourquoi donc ?

je ne vois pas pourquoi ce ne serait pas possible via un trigger, c'est basique presque

Code :

1
2
3
 
  IF (new.DESIGNATION IS NULL)
  then new.DESIGNATION = CAST(EXTRACT(YEAR FROM CURRENT_DATE) AS CHAR(4))||'-'||CAST(EXTRACT(MONTH FROM CURRENT_DATE) AS CHAR(2))||'-'||CAST(gen_id(G_ID_T_ENTRP, 1) AS CHAR(8));

c'est à affiner, mais vraiment pas très compliqué

[Yurck]

Bonjour,

La solution de makowski me paraît franchement séduisante, d'autant plus que tu peux réinitialiser ton générateur en début de mois.

a+

[Cl@udius]

Envoyé par makowski

je ne vois pas pourquoi ce ne serait pas possible via un trigger, c'est basique presque

Cette solution d'une simplicité effarante m'avait échappé !
Pourquoi faire simple quand on peut faire compliqué ?

Merci à vous deux.
@+

[PierreY]

Envoyé par Claudius40

article de PierreY chez Firebird-fr

Merci ;-)

Pour répondre strictement à ta question, et sachant que la bonne réponse est d'utiliser un générateur, il manque des paramètres, ton souhait est de faire fonctionner firebird au niveau d'isolement "SERIALIZABLE" :

SERIALIZABLE : isc_tpb_consistency + isc_tpb_wait + isc_tpb_lock_read (lock explicite des tables auxquelles on accède uniquement en lecture) + isc_tpb_lock_write (lock explicite des tables auxquelles on accède en lecture et écriture)

Les phrases "lock explicites..." indiquent qu'il faut passer aussi le NOM des tables auxquelles on veut un lock explicite en lecture ou en écriture.

isc_tpb_write est implicite, on utilise isc_tpb_read quand on veut indiquer explicitement qu'on n'a que l'intention de faire des lectures (et se protéger d'une erreur de manipulation ou d'un injection de SQL qui risquerait de provoquer une écriture "malgré nous")

@+

--
Pierre Y.

[Cl@udius]

Bonjour

Envoyé par PierreY

Pour répondre strictement à ta question, et sachant que la bonne réponse est d'utiliser un générateur, ...

Bien évidemment je me suis orienté vers la solution du générateur, étant la solution la plus simple et la plus sûre.

Cependant, par simple curiosité, j'ai essayé de paramétrer un lock explicite en lecture / écriture sur ma table et je n'y suis pas parvenu.
J'ai essayé différentes syntaxes sans succès.

Code :

1
2
3
4
5
6
7
8
9
 
isc_tpb_write   // Inutile puisque implicite
isc_tpb_consistency
isc_tpb_wait
isc_tpb_lock_write "MATABLE"
ou
isc_tpb_lock_wirite 'MATABLE'
ou 
isc_tpb_lock_write MATABLE

Le message en retour est paramètre TPB non reconnu !

Ah, question subsidiaire: les compos IBX sont-ils les mieux adapter à Firebird ?

Merci @+

[makowski]

pas vraiment non
et surtout pour jouer comme tu le fais
le mieux dans ce cas c'est de prendre les UIB

[Cl@udius]

Bonjour

Envoyé par makowski

le mieux dans ce cas c'est de prendre les UIB

Merci je vais regarder ca de plus près.

Envoyé par makowski

et surtout pour jouer comme tu le fais

Je cherche simplement à comprendre mais pas forcément à le mettre en place. Je suis assez curieux de nature.

Bonne journée. Je tag résolu.

@+

[makowski]

mais tu as raison, c'est en essayant que l'on apprend
"jouer" n'était pas péjoratif

[PierreY]

Envoyé par Claudius40

Cependant, par simple curiosité, j'ai essayé de paramétrer un lock explicite en lecture / écriture sur ma table et je n'y suis pas parvenu.
J'ai essayé différentes syntaxes sans succès.

Code :

Le message en retour est paramètre TPB non reconnu !

Oufti :-) On est loin du compte, soit tu attaques directement les API de Firebird (isc_start_transaction()) et tu envoies directement le TPB encodé correctement comme dernier paramètre (voire les sources de l'API...) soit tu as des composants "bien faits" qui font ça pour toi.

En général il y a des propriétés dans les composants T[XXX]Transaction (où XXX in (IB, UIB, JvUIB, IBO, ...) qui permettent de contrôler les paramètres, le tout est ensuite encodé par le composant pour être passé à l'API :

Dans JvUIB ces paramètres sont LockRead et LockWrite.

Ca donnerait :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
var
  T: TJvUIBTransaction;
begin
  T := TJvUIBTransaction.CREATE(nil);
  T.DATABASE := UnTJvUIBDatabase;
  T.Options := [tpWrite, tpConsistency, tpWait, tpLockWrite, tpExclusive];
  T.LockWrite := 'MATABLE';
 
  WITH TJvUIBQuery.CREATE(nil) do
  begin
    Transaction := T;
    SQL.Text := 'select NEW_ID from PS_GET_UN_ID_POUR_MATABLE';
    try
      Open;
      Result := FIELDS.AsInteger[0];
      Close(etmCommit);
    finally
      Free;
      T.Free;
    end;
  end;
end;

@+

--
Pierre Y.