Bonjour,
Soit un dataset : dts (Tclientdataset ou TTable) déclaré en public

Voici ce que je voudrais faire :

procedure traite
begin
dts.locate('IDENTIFICATION', 12,[]);
ici bloquer la position de dts sur l'enregistrement courant
try // dans le bloc try finally ne pas pouvoir bouger
dans dts
fonction1 // dans fonction avoir accès à l'enregistrement en
lecture, edit, post
fonction2
......

finally
débloquer dts
end;
end;

En bref c'est d'être sur que dans fonction1 à ..... que l'on reste bien sur
le bonne enregistrement.
J'ai une première solution : c'est de mettre une clé unique sur dts et de
faire un dts.setrange([12],[12]);

Comment écrire cela au mieux.

Merci pour toute proposition.


--
Antoine Ostinelli
AZLAC Tél. 04 50 67 13 55 web : www.azlac.com

N'imprimez ce mail que si nécessaire






--
Raphaël Vivien

> ici bloquer la position de dts sur l'enregistrement courant
bloquer le rafraichissement de l ecran , tu veux dires ???

"F" <ff@ff.com> a écrit dans le message de news:
mn.0b427d8233f46c27.24174@ff.com...
>> ici bloquer la position de dts sur l'enregistrement courant
> bloquer le rafraichissement de l ecran , tu veux dires ???
>
Non, bloquer le dataset sur l'enregistrement en question.
Les traitements contenus dans les fonctions se rapportent à un élément
particulier pointé par le dataset, je dois être sur que l'enregistrement
courant du dataset reste le même.
Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
Bloquer le dataset n'est peut être pas la bonne méthode, est il possible de
créer un objet style 'Record' contenant les mêmes champs que le dataset.
Le "record" est rempli avec les champs de l'enregistrement sélectionné.
Le "record" est passé en arguments var aux différentes fonctions.
A la fin le "record" est recopié dans le dataset à la place de
l'enregistrement d'origine.

Le" record" pourrait être traité comme un dataset :
record.fieldvalues['NOM_DU_CHAMP'] :=


Ma question est comment faire cela le mieux possible ?

R.V.

Raphael Vivien a écrit :
> "F" <ff@ff.com> a écrit dans le message de news:
> mn.0b427d8233f46c27.24174@ff.com...
>>> ici bloquer la position de dts sur l'enregistrement courant
>> bloquer le rafraichissement de l ecran , tu veux dires ???
>>
> Non, bloquer le dataset sur l'enregistrement en question.
> Les traitements contenus dans les fonctions se rapportent à un élément
> particulier pointé par le dataset, je dois être sur que l'enregistrement
> courant du dataset reste le même.
> Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
> Bloquer le dataset n'est peut être pas la bonne méthode, est il possible de
> créer un objet style 'Record' contenant les mêmes champs que le dataset.
> Le "record" est rempli avec les champs de l'enregistrement sélectionné.
> Le "record" est passé en arguments var aux différentes fonctions.
> A la fin le "record" est recopié dans le dataset à la place de
> l'enregistrement d'origine.
>
> Le" record" pourrait être traité comme un dataset :
> record.fieldvalues['NOM_DU_CHAMP'] :=
>
>
> Ma question est comment faire cela le mieux possible ?
>
> R.V.
>
>
C'est quoi que tu crains ?... Qu'il bouge tout seul une fois sélectionné
par un Locate ?

> Bonjour,
> Soit un dataset : dts (Tclientdataset ou TTable) déclaré en public
>
> Voici ce que je voudrais faire :
>
> procedure traite
> begin
> dts.locate('IDENTIFICATION', 12,[]);
> ici bloquer la position de dts sur l'enregistrement courant
> try // dans le bloc try finally ne pas pouvoir bouger dans
> dts
> fonction1 // dans fonction avoir accès à l'enregistrement en
> lecture, edit, post
> fonction2
> ......
>
> finally
> débloquer dts
> end;
> end;
>
> En bref c'est d'être sur que dans fonction1 à ..... que l'on reste bien sur
> le bonne enregistrement.
> J'ai une première solution : c'est de mettre une clé unique sur dts et de
> faire un dts.setrange([12],[12]);
>
> Comment écrire cela au mieux.
>
> Merci pour toute proposition.
>
>
> --
> Antoine Ostinelli
> AZLAC Tél. 04 50 67 13 55 web : www.azlac.com
>
> N'imprimez ce mail que si nécessaire

et si tu ouvre qu'un seul enregistrement?

--
Michael

"BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
message de news: fnv8me$c0a$1@sd-6836.dedibox.fr...
> Raphael Vivien a écrit :
>> "F" <ff@ff.com> a écrit dans le message de news:
>> mn.0b427d8233f46c27.24174@ff.com...
>>>> ici bloquer la position de dts sur l'enregistrement courant
>>> bloquer le rafraichissement de l ecran , tu veux dires ???
>>>
>> Non, bloquer le dataset sur l'enregistrement en question.
>> Les traitements contenus dans les fonctions se rapportent à un élément
>> particulier pointé par le dataset, je dois être sur que l'enregistrement
>> courant du dataset reste le même.
>> Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
>> Bloquer le dataset n'est peut être pas la bonne méthode, est il possible
>> de créer un objet style 'Record' contenant les mêmes champs que le
>> dataset.
>> Le "record" est rempli avec les champs de l'enregistrement sélectionné.
>> Le "record" est passé en arguments var aux différentes fonctions.
>> A la fin le "record" est recopié dans le dataset à la place de
>> l'enregistrement d'origine.
>>
>> Le" record" pourrait être traité comme un dataset :
>> record.fieldvalues['NOM_DU_CHAMP'] :=
>>
>>
>> Ma question est comment faire cela le mieux possible ?
>>
>> R.V.
> C'est quoi que tu crains ?... Qu'il bouge tout seul une fois sélectionné
> par un Locate ?
Pas exactement tout seul, mais dans les fonctions de traitement une erreure
de programmation peut conduire à un déplacement de l'enregistrement courant.
Si j'ai un système qui me garanti de ne pas pouvoir faire l'erreur c'est
mieux.

RV

Raphael Vivien a écrit :
> "BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
> message de news: fnv8me$c0a$1@sd-6836.dedibox.fr...
>> Raphael Vivien a écrit :
>>> "F" <ff@ff.com> a écrit dans le message de news:
>>> mn.0b427d8233f46c27.24174@ff.com...
>>>>> ici bloquer la position de dts sur l'enregistrement courant
>>>> bloquer le rafraichissement de l ecran , tu veux dires ???
>>>>
>>> Non, bloquer le dataset sur l'enregistrement en question.
>>> Les traitements contenus dans les fonctions se rapportent à un élément
>>> particulier pointé par le dataset, je dois être sur que l'enregistrement
>>> courant du dataset reste le même.
>>> Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
>>> Bloquer le dataset n'est peut être pas la bonne méthode, est il possible
>>> de créer un objet style 'Record' contenant les mêmes champs que le
>>> dataset.
>>> Le "record" est rempli avec les champs de l'enregistrement sélectionné.
>>> Le "record" est passé en arguments var aux différentes fonctions.
>>> A la fin le "record" est recopié dans le dataset à la place de
>>> l'enregistrement d'origine.
>>>
>>> Le" record" pourrait être traité comme un dataset :
>>> record.fieldvalues['NOM_DU_CHAMP'] :=
>>>
>>>
>>> Ma question est comment faire cela le mieux possible ?
>>>
>>> R.V.
>> C'est quoi que tu crains ?... Qu'il bouge tout seul une fois sélectionné
>> par un Locate ?
> Pas exactement tout seul, mais dans les fonctions de traitement une erreure
> de programmation peut conduire à un déplacement de l'enregistrement courant.
> Si j'ai un système qui me garanti de ne pas pouvoir faire l'erreur c'est
> mieux.
>
> RV
>
>
Tu pourrais par exemple : Lancer une exception ou un abort dans
BeforeScroll ? Utiliser la propriété Filter pour ne conserver que
l'enregistrement qui te convient ?

Si vraiment tu veux t'equiquiner la vie, tu peux avoir un VirtualDataset
qui contient seulement ton enregistrement...

Ceci dit... Si tu penses que le dataset va bouger tout seul, vaut mieux
cesser de suite de "croire" en l'informatique... Si je devais partir du
postulat que mes datasets vont bouger alors qu'ils ne le sont pas
supposés, j'avoue que ça m'augmenterait grandement mes heures de
développement... ... ...

filtre ton dataset sur une clé, même apres close open il restera sur
l'enregistrement
le problème se pose si la clé n'est crée qu'après, au moment de la première
édition
là nous avons un enregistrement avec une clé vide encours jusqu'au post
commit
si plusieurs utilisateurs font de même la valeur renvoyer apres le commit de
la basse peut être n'importe quoi
sur un nombre d'utilisateur, j'ai trié ma table en ordre croissant et
j'appelle le dernier enregistrement

mais maintenant que je connais les guid,
je prendrais une clé a chaque nouvel enregistrement avant de le poster et je
pourrai filtré sur ma clé.
ainsi quoi qu'il arrive je reste sur la valeur de ma clé
si vraiment j'ai peur arret du pc, du serveur etc, tu peux mettre la cle
dans un fichier texte pour la recuper apres que l'application soir éteinte

enfin j'espère ne pas être trop nébuleux

handman

"BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
message de news:fnvc03$dg3$1@sd-6836.dedibox.fr...
> Raphael Vivien a écrit :
>> "BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
>> message de news: fnv8me$c0a$1@sd-6836.dedibox.fr...
>>> Raphael Vivien a écrit :
>>>> "F" <ff@ff.com> a écrit dans le message de news:
>>>> mn.0b427d8233f46c27.24174@ff.com...
>>>>>> ici bloquer la position de dts sur l'enregistrement courant
>>>>> bloquer le rafraichissement de l ecran , tu veux dires ???
>>>>>
>>>> Non, bloquer le dataset sur l'enregistrement en question.
>>>> Les traitements contenus dans les fonctions se rapportent à un élément
>>>> particulier pointé par le dataset, je dois être sur que
>>>> l'enregistrement courant du dataset reste le même.
>>>> Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
>>>> Bloquer le dataset n'est peut être pas la bonne méthode, est il
>>>> possible de créer un objet style 'Record' contenant les mêmes champs
>>>> que le dataset.
>>>> Le "record" est rempli avec les champs de l'enregistrement sélectionné.
>>>> Le "record" est passé en arguments var aux différentes fonctions.
>>>> A la fin le "record" est recopié dans le dataset à la place de
>>>> l'enregistrement d'origine.
>>>>
>>>> Le" record" pourrait être traité comme un dataset :
>>>> record.fieldvalues['NOM_DU_CHAMP'] :=
>>>>
>>>>
>>>> Ma question est comment faire cela le mieux possible ?
>>>>
>>>> R.V.
>>> C'est quoi que tu crains ?... Qu'il bouge tout seul une fois sélectionné
>>> par un Locate ?
>> Pas exactement tout seul, mais dans les fonctions de traitement une
>> erreure
>> de programmation peut conduire à un déplacement de l'enregistrement
>> courant.
>> Si j'ai un système qui me garanti de ne pas pouvoir faire l'erreur c'est
>> mieux.
>>
>> RV
>>
>>
> Tu pourrais par exemple : Lancer une exception ou un abort dans
> BeforeScroll ? Utiliser la propriété Filter pour ne conserver que
> l'enregistrement qui te convient ?
>
> Si vraiment tu veux t'equiquiner la vie, tu peux avoir un VirtualDataset
> qui contient seulement ton enregistrement...
>
> Ceci dit... Si tu penses que le dataset va bouger tout seul, vaut mieux
> cesser de suite de "croire" en l'informatique... Si je devais partir du
> postulat que mes datasets vont bouger alors qu'ils ne le sont pas
> supposés, j'avoue que ça m'augmenterait grandement mes heures de
> développement... ... ...

Merci pour vos différentes suggestions, finallement je retiens une solution
ultra simple :
le dataset est placé en private.
En public j'ai :
procedure DatasetEcrit(champ_: string; val_:variant);
function DatasetLit(champ_ : string): variant;

A l'extérieur de l'objet je ne peux que lire et écrire l'enregistrement
courant.
Avantage de cette méthode par rapport au dataset en public, elle oblige dans
le code à respecter la structure de l'application.

R.V.

"handman" <handman@tiscali.fr> a écrit dans le message de news:
fo3suk$iqe$1@sd-6836.dedibox.fr...
> filtre ton dataset sur une clé, même apres close open il restera sur
> l'enregistrement
> le problème se pose si la clé n'est crée qu'après, au moment de la
> première édition
> là nous avons un enregistrement avec une clé vide encours jusqu'au post
> commit
> si plusieurs utilisateurs font de même la valeur renvoyer apres le commit
> de la basse peut être n'importe quoi
> sur un nombre d'utilisateur, j'ai trié ma table en ordre croissant et
> j'appelle le dernier enregistrement
>
> mais maintenant que je connais les guid,
> je prendrais une clé a chaque nouvel enregistrement avant de le poster et
> je pourrai filtré sur ma clé.
> ainsi quoi qu'il arrive je reste sur la valeur de ma clé
> si vraiment j'ai peur arret du pc, du serveur etc, tu peux mettre la cle
> dans un fichier texte pour la recuper apres que l'application soir
> éteinte
>
> enfin j'espère ne pas être trop nébuleux
>
> handman
>
> "BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
> message de news:fnvc03$dg3$1@sd-6836.dedibox.fr...
>> Raphael Vivien a écrit :
>>> "BigGrizzly" <bigENLEVERCECIgrizzly@zoo-loETCAgique.org> a écrit dans le
>>> message de news: fnv8me$c0a$1@sd-6836.dedibox.fr...
>>>> Raphael Vivien a écrit :
>>>>> "F" <ff@ff.com> a écrit dans le message de news:
>>>>> mn.0b427d8233f46c27.24174@ff.com...
>>>>>>> ici bloquer la position de dts sur l'enregistrement courant
>>>>>> bloquer le rafraichissement de l ecran , tu veux dires ???
>>>>>>
>>>>> Non, bloquer le dataset sur l'enregistrement en question.
>>>>> Les traitements contenus dans les fonctions se rapportent à un élément
>>>>> particulier pointé par le dataset, je dois être sur que
>>>>> l'enregistrement courant du dataset reste le même.
>>>>> Les fonctions peuvent lire ou écrire dans l'enregistrement courrant.
>>>>> Bloquer le dataset n'est peut être pas la bonne méthode, est il
>>>>> possible de créer un objet style 'Record' contenant les mêmes champs
>>>>> que le dataset.
>>>>> Le "record" est rempli avec les champs de l'enregistrement
>>>>> sélectionné.
>>>>> Le "record" est passé en arguments var aux différentes fonctions.
>>>>> A la fin le "record" est recopié dans le dataset à la place de
>>>>> l'enregistrement d'origine.
>>>>>
>>>>> Le" record" pourrait être traité comme un dataset :
>>>>> record.fieldvalues['NOM_DU_CHAMP'] :=
>>>>>
>>>>>
>>>>> Ma question est comment faire cela le mieux possible ?
>>>>>
>>>>> R.V.
>>>> C'est quoi que tu crains ?... Qu'il bouge tout seul une fois
>>>> sélectionné par un Locate ?
>>> Pas exactement tout seul, mais dans les fonctions de traitement une
>>> erreure
>>> de programmation peut conduire à un déplacement de l'enregistrement
>>> courant.
>>> Si j'ai un système qui me garanti de ne pas pouvoir faire l'erreur c'est
>>> mieux.
>>>
>>> RV
>>>
>>>
>> Tu pourrais par exemple : Lancer une exception ou un abort dans
>> BeforeScroll ? Utiliser la propriété Filter pour ne conserver que
>> l'enregistrement qui te convient ?
>>
>> Si vraiment tu veux t'equiquiner la vie, tu peux avoir un VirtualDataset
>> qui contient seulement ton enregistrement...
>>
>> Ceci dit... Si tu penses que le dataset va bouger tout seul, vaut mieux
>> cesser de suite de "croire" en l'informatique... Si je devais partir du
>> postulat que mes datasets vont bouger alors qu'ils ne le sont pas
>> supposés, j'avoue que ça m'augmenterait grandement mes heures de
>> développement... ... ...
>