Aggiornamento dati portale

Grazie Giulio ho risolto

Ti eri spiegato benissimo

e la tecnica multimedia serve proprio a risolvere il problema, con un paio di calcoli e senza duplicazione di record/ tabelle di join.

.g.

in realtà forse mi sono spiegato male all’inizio, scusami Giulio,  inserisco un link con un’immagine per farmi capire meglio, faccio pure un esempio:

io vorrei nella scheda anagrafica di Pinco Pallino un portale dove vi sia un campo che prenda il cognome e nome (Rossi Mario in questo caso) dall’elenco di tutte le schede in anagrafica, e quindi la inserisca come persona presente al momento della rilevazione del guasto, e allo stesso tempo, tramite script si inseriscano nel portale della scheda anagrafica di Rossi Mario gli stessi dati ma con il nome Pinco Pallino che è era presente insieme a Rossi Mario. Poi al momento che il guasto verrà riparato i rispettivi record vengano ”chiusi” immettendo la data della riparazione

link all’immagine http://jpegbay.com/gallery/005278394-.html#1

se tu vuoi che un problema sia associato a più di una persona, hai due possibilità:

– una tabella di join
-una relazione multikey

per la seconda di basta una relazione per id ( persone::id=problemi::idpersona), a patto che il campo in questione sia o multiplo oppure con più valori separati da un acapo.  ipotizzando che in un record il campo problemi::idpersona contenga:

33
45
46

il record verrà posto in relazione con le persona che hanno come id il valore, 33, 45 o 46.
questo campo può pure essere un calcolato, purché indicizzato (quindi la combinazione di altri campi in cui inserisci le persone di riferimento).
in questa accezione il fatto che ci siano o meno nuovi dipendenti non c’entra assolutamente nulla.

ovviamente, una tabella di join è più robusta, anche se di più difficile implementazione.

.g.

effettivamente per come me la descrivi sembra molto macchinosa  anche a me (ci ho capito ancora poco di questa relazione con un campo che contenga tutti gli id. Man mano che vengono inseriti i nuovi dipendenti, nuovi record, il suddetto campo si autoaggiornerà? Non ho capito nemmeno cosa intendi per confronto, con cosa?

secondo te quale potrebbe essere un’altra soluzione più ”elegante” per questo problema?

devi avere un campo che abbia tutte le chiavi di relazione una sopra all’altra e utilizzarlo come unico campo di confronto (anche come campo calcolato indicizzato): questo fa si che il record venga correlato tutti gli aventi causa.
ciò detto, se puoi avere anche 50 persone a gestire i guasto, magari dovresti cambiare architettura. funzionare funziona pure, ma la vedo un po macchinosa…

.g.

scusami Giulio non ho capito bene

nel senso che io ho già un campo di relazione tra le due tabelle e che è  ”id”, posso toglierlo mettendo questo ”nuovo campo” o devo averne due?

_ulteriore_?

domanda 1

il problema è che le persone ”coinvolte”, a rilevare i guasti, solitamente sono 2 ma potrebbero essere anche 30 o più. In questo caso come si potrebbe  gestire?

domanda 2

questo ulteriore campo relazionato oltre a quello ”id” mi crea problemi o mi serve solo per far creare i record contemporaneamente sulla scherda di più persone?

fai UNA relazione su un campo con più righe, qualcosa tipo:

persona 1
persona 2

per come funziona il motore di calcolo di FM ciascuna riga agisce da chiave separata. Oppure un campo multiplo con N valori.

.g.

Sul punto 2 mi hai fatto riflettere ed effettivamente è corretta la tua osservazione, vedrò di adattarmi per far si di risolvere tramite script

Inizialmente anche io avrei voluto creare un unico record per il punto 1 ma sconosco la relazione multikey. Come funziona? Come si impostano e uniscono i due record di cui al punto 1 ?

Sei sempre il migliore Giulio

secondo me il punto 2 è corretto proceduralmente (casomai il reparto va aggiornato via script, dato che a livello di storico andrebbe mantenuto il reparto al tempo in cui il problema è stato segnalato).
per i punti 1 e 3 il record deve secondo me essere uno solo, correlato con entrambi gli aventi causa (mediante relazione multikey).

.g.