Time: gestione precisione superiore al minuto secondo

[C.Zecca]

La proposta è quella di aggiungere a

o - hour()
o - minute()
o - second()

una ulteriore funzione (subsecond() ?) che permetta di accedere e rappresentarre la parte di un Time con precisione superiore a quella del minuto secondo.
Dettagli qui sotto.

---------------------------------------


Ho un pannello "di testata" (master) implementata su IMDB (vista la presenza di ciò che in table orientation sarebbero state due colonne calcolate e quindi inibite all'input, ovvero Data Operazione e Ora Operazione).
Per vari motivi essa è stata implementata con SalvaAutomatico acceso (permette di evitare che partano cicli di salvataggio indesiderati) ma ciò comporta, in uscita dalla videata, che sia necessario controllare a mano se i dati di testata siano stati modificati o meno.

In fase di aggiornamento (in fase di creazione ciò non si verifica, non possono essere considerati modificati dati prima inesistenti) ciò avviene verificando se i dati in memoria e quelli ricaricati da base dati siano uguali.
Al momento della creazione, si chiede al sistema il time(): questa contiene, sibillamente, una parte di riferimento temporale inferiore al secondo (decimi, centesimi, millesimi o inferiore). InDe, d'altra parte, NON mette a disposizione (sto usando la 13.5), attualmente, la gestione dei Time per parti inferiori al minuto secondo (intendo una API per la gestione di decimi, centesimi di secondo, etc. anche se nelle maschere qualcosa del genere fa capolino).

Insomma, in salvataggio il sistema scriveva una Date SQL con decimi, centesimi, etc. di secondo, originata proprio col riferimento cronologico (time()) iniziale.

Problema
Al momento del controllo inerente la modifica o meno della testata, si assemblava un Time di fatto troncato al secondo (con InDe, non è possibile una precisione superiore): il riferimento cronologico caricato da base dati risultava diverso da quello in memoria, nonostante essi fossero uguali al secondo.

Soluzione
Al momento della creazione della operazione di movimento, ora tronchiamo il tempo al minuto secondo; esso viene salvato poi così in base dati (insert in tabella master) e risulta coerente (quindi anche uguale) con i dati in memoria, il sistema non dà più dei falsi positivi (ovvero non dice più che il Time di pannello è diverso da quella caricata da base dati).

Nell''immagine qui sotto, il tracer, al momento della Close Form, sezione inerente i controlli cronologici.
o - la parte Time in memoria (campo di pannello, lOraMemoria, parametro pTimeOp)
o - la parte Time caricata da base dati (originata con la chiamata a time() e precisione superiore al min. secondo ovveronon troncata al min. secondo)

risultano diverse (lOreDiverse = -1 (true) anche se uguali al secondo.

TimeGestionePrecisioneSuperioreMinutoSecondo.png (74.18 KiB) Viewed 5387 times

[g.cassanelli]

Non è un problema quotidiano, ma quando ce l'hai è una rogna.
Appoggio

[g.lanzi]

Nel caso in questione il problema non è tanto di una non disponibilità di API, ma di come vengono gestiti i datetime da Instant Developer rispetto al database.
Instant Developer non mette a disposizione una libreria per valori inferiori al secondo perché tutte le date sono _sempre_ troncate al secondo.

In creazione non dà problemi perché il valore letto dal db non c'è e non c'è niente con cui confrontare il valore corrente del pannello.

In aggiornamento il problema si può manifestare solo perché i dati del pannello sono diversi da quelli presenti sul database, ma se è stato Instant Developer a scriverli allora non possono avere una precisione maggiore del secondo.

Non è che c'è un trigger che fa qualcosa o qualcosa di simile?

Nel caso descritto da @c.zecca il problema non sarebbe risolto da una precisione maggiore, perché si tratta di un problema di disallineamento tra il db e il pannello e non di una precisione insufficiente.

Credo che la cosa migliore sia di guardare insieme il caso.

[C.Zecca]

E' passato un po' di tempo, ma ho recuperato le mie annotazioni di check-in 16663 (del 29 gennaio u.s.)
Il parametro attuale pTimeOperazione passato alle funzioni InitParXxxx() era stata modificato

Code: Select all

da  time()
a   LTimeAlSecondo
con questa così inizializzata

  LTimeAlSecondo = TimeAlSecondo(time())


TimeAlSecondo_inizializzazione_Prima_Dopo.png (37.23 KiB) Viewed 5281 times

Ecco la TimeAlSecondo()

Code: Select all

// **********************************************************************************************
// Troncatura/costruttore di un valore Time con precisione al secondo (viene annullata la parte
// cronologica inferiore al secondo)
// **********************************************************************************************
public time Gcsgc.TimeAlSecondo(
  time pTime //
)
{
  int lOra = hour(pTime)
  int lMinuto = minute(pTime)
  int lSecondo = second(pTime)
  time lResult = toTime(lOra, lMinuto, lSecondo)
  return lResult
}



> Non è che c'è un trigger che fa qualcosa o qualcosa di simile?
Ho eseguito un veloce controllo e non ho trovato azioni dei trigger in inserimento sulla colonna Data_Operazione di Movimenti_Fondo.
La base dati che utilizzavamo, per lo sviluppo della nuova interfaccia Web, era vuota di dati e quindi i dati furono e sono creati dalla nuova interfaccia. Come si nota dall'immagine sopra in questo intervento, si tratta del ramo Inserimento, ovvero di record creati ex novo (nuovi di zecca! ;)

Riepilogando:
'sta dataora generati da time() venivano salvati taloqualo ;) in base dati (senza intervento di trigger)
al momento della chiusura della videata per varie ragioni etc. - confrontavamo la data + ora in pannello riassemblati in dataora (pTimeOp nell'istantanea del tracer, sopra), con quella caricata al volo da base dati (e generata con time(), salvata in precedenza con insert, lTimeOp nell'instantanea del tracer) e risultavano diverse.

Inizializzando (ovvero troncando) la dataora restituita da time() con precisione al secondo, non ci sono più differenze.
Ora, per riverificare, ho riportato il codice, in una delle funzioni, allo stato pre check-in 16663 e ho riprodotto il problema.

[g.lanzi]

Ammetto che non so se ho capito bene il giro, ma una cosa è certa: il codice c#/java del visual code non dovrebbe creare un datetime/time o simili con precisione superiore al secondo.

Ti risulta che invece sia così? Potresti inserire una segnalazione di malfunzionamento con il codice con cui hai riprodotto il caso?