Date de creation/modification d'un enregistrement

Est-ce que cette(ces) information(s) existe(nt) dans l’enregistrement de 4D ? Si oui y a t’il un moyen de la(les) lire ? Avec l’introduction de ORDA cela donne-t-il accès à des infos qu’on nous cachait autrefois ?

Cela pour éviter de refaire le travaille et de le stocker une seconde fois inutilement.

: Manuel PIQUET

on nous cachait autrefois ?

JPR n’aurait il pas fait un data analyser ou qq chose du genre ?

Peut être des choses à gratter : https://kb.4d.com/assetid=77253DataAnalyzer V1.0>

Bonjour,

: Manuel PIQUET

Est-ce que cette(ces) information(s) existe(nt) dans l’enregistrement
de 4D ? Si oui y a t’il un moyen de la(les) lire ? Avec
l’introduction de ORDA cela donne-t-il accès à des infos qu’on nous
cachait autrefois ?

Non.

: Manuel PIQUET

Cela pour éviter de refaire le travaille et de le stocker une
seconde fois inutilement.

Stocker une seconde fois ?

Cordialement,

Non mais je veux quand même des choses officielles qui ne risquent pas de disparaître du jour au lendemain. :expressionless:
Je demande juste si cette information n’est pas déjà stockée et si on peut pas y avoir accès simplement en lecture.
Je pensais que l’arrivée d’ORDA pouvait peut-être nous permettre cela :?:

: Olivier DESCHANELS
: Manuel PIQUET

Cela pour éviter de refaire le travaille et de le stocker une
seconde fois inutilement.

Stocker une seconde fois ?

Il fallait lire stocker l’information une seconde fois…

Mais si elle n’est pas présente, on ne peut donc pas la lire :wink:

On va donc le faire à la main… :cry:

Je ne suis pas allé voir mais il pourrait y avoir une méthode pour la lecture de tes timestamp ?

Oui et non, je dirais : d’après https://doc.4d.com/4Dv17R5/4D/17-R5/Replication-via-le-SQL.300-4142706.fr.htmlla doc>, tu peux lire __ROW_ID, __ROW_STAMP et __ROW_ACTION ; respectivement : le numéro d’enregistrement, un numéro incrémental délivré chaque fois qu’un enregistrement est “touché” (ajout, modif, suppr), en quoi il l’est.

Limites de __ROW_STAMP : interrogeable en sql seulement, stocké dans un entier64 et, surtout, un stamp n’est pas un time stamp ; si j’ai bien compris, c’est un numéro incrémental, l’enregistrement qui porte le numéro le plus élevé étant le plus récemment touché. Inutile d’en attendre des requêtes telles que “les enregistrements touchés depuis le …” ou “entre le … et le …”. Par contre tu as sans doute la possibilité de faire un truc du genre “cherche moi les x derniers modifiés”. Tu as un exemple https://forums.4d.com/Post/FR/28676491/1/28676492#28676492ici> avec les formulaires, eux aussi sont “tracés” par un stamp.

Olivier semble dire que non, non ? :doubt:

Qu’entends-tu par Timestamp ? un UUID (génération automatique) contient-il une quelconque information encodée qui contiendrait une notion de date incluse ?

Si c’était le cas cela pourrait effectivement fonctionner car il est créé au moment de la création de l’enregistrement et ne varie plus ensuite. Donc, cela pourrait constituer une date de création.

Je n’ai rien été voir. Souviens-toi qu’à l’époque de Datacheck (avant la v11) on lisait ces valeurs sans problème

En résumé, j’ai du oui, du non, et du peut-être… :lol:

Si l’UUID contient une notion de date, je ne sais pas la ressortir.

Il me semblait aussi qu’à l’époque on avait effectivement des infos non accessibles directement, mais bon…

: Manuel PIQUET

un UUID (génération automatique) contient-il une quelconque
information encodée qui contiendrait une notion de date incluse ?
ce https://en.wikipedia.org/wiki/Universally_unique_identifierfut le cas>, mais ils ont compris que ça ne passerait pas le rgpd :mrgreen:

T’es sérieux :?: :doubt:
Tu me fais peur des fois…

Ton article ne me dit pas quelle variante est utilisée par 4D…

Ce serait la 4, selon https://forums.4d.com/Post/FR/15463320/1/15484407#15484407certaines sources>.

Bonjour,

Pour recentrer le débat :
1/ le timestamp inclus dans l’entête de l’enregistrement ne permet pas (et n’a jamais permis au temps dans les temps anciens) de connaitre la date de création
2/ l’expérience montre que la date de modification ne sert à rien. Si l’on doit garder quelque chose c’est les dates successives de modification, accompagnées de l’utilisateur l’ayant effectuée. En effet, si l’on recherche une erreur, une modification … la réponse est rarement dans la dernière modification.

Cordialement,

Je suis assez d’accord, mais c’est une demande récurrente de client :cry:. De toute façon, cela ne règle rien, cela n’indique que l’utilisateur connecté et cela ne permet absolument pas de conclure à quoi que ce soit…(la plupart du temps les logins et mot de passe ne sont pas respectés comme ils le devraient).

Mais, la date de création à parfois un intérêt, ainsi que la dernière date de modification. (Ce n’est pas pour rien que ces 2 dates sont conservées par les OS dans leur gestion de fichier.)

Olivier, tu as répondu sur le timstamp 4D interne, mais qu’en est-il avec un UUID automatique comme clé primaire de la table ?

: Olivier DESCHANELS

Si l’on doit garder quelque chose c’est les dates successives de
modification, accompagnées de l’utilisateur l’ayant effectuée. En
effet, si l’on recherche une erreur, une modification … la réponse
est rarement dans la dernière modification.
J’ajoute souvent ce qui a été modifié : le besoin de tracer des modifications est presque toujours relatif au “métier” pris en charge par l’application. Exemple : on modifie a posteriori une pièce comptable, si c’est la date ou le montant, c’est important, si c’est le champ note on s’en fiche.

: Manuel PIQUET

Olivier, tu as répondu sur le timstamp 4D interne, mais qu’en est-il
avec un UUID automatique comme clé primaire de la table ?
Je suis pas Olivier mais relis plus haut, il n’y a pas de timestamp dans un uuid version 4. C’est grave aléatoire.

Bonjour,

: Arnaud DE MONTARD
: Manuel PIQUET

Olivier, tu as répondu sur le timstamp 4D interne, mais qu’en est-il
avec un UUID automatique comme clé primaire de la table ?
Je suis pas Olivier mais relis plus haut, il n’y a pas de timestamp
dans un uuid version 4. C’est grave aléatoire.
Exact, et exact !

Cordialement,