FM15: Get riga portale attiva – funzionamento diverso da versioni precedenti?

Grazie Giulio. Ci provo

Saluti

Mario

sempre per citare il tuo esempio: avendo una fattura, se hai molti articoli diventa una tortura usare un menù/lista per inserire il codice prodotto.
in quel caso, preferisco un popover che contenga un portale filtrato con tutti gli articoli. a quel punto ci sono due opzioni:
A – l’utente si ricorda il codice (nel senso che il codice/descrizione inserito genera UN unico articolo): appaiono i dati articolo, l’eventuale immagine e l’utente inserisce la quantità, eventualmente modifica il prezzo e da l’ok: uno script carica il contenuto nel portale
B- l’utente cerca per descrizione: dal portale seleziona una riga e ritorna al punto A.
questa procedura ha lo scopo di ridurre al minimo gli errori.
Se invece serve una procedura automatizzata (tipo lettore barcode) faccio comunque inserire il valore in un campo esterno al portale, per poi inserire i dati mediante script (anche qui per catturare eventuali errori). In generale cerco di sviluppare procedure che siano:
A) modulari e riutilizzabili
B) per quanto possibile ACIDe e transazionali (ovvero che non scrivano nulla nel DB prima della conferma della transazione).

Per quanto riguarda il discorso dell’autorelazione, molto dipende da cosa ti serve in numero riga portale. Se è solo per la stampa, ti basta inserire il simbolo giusto e via. Se invece ha valenza di calcolo, puoi gestirtela in questo modo: sempre assumendo le fatture, diciamo che ti serve un numero progressivo per ciascuna riga, che parta da 1 per ogni fattura. Metti in relazione la tabella righe_fattura con se stessa (duplicando la TO, nell’esempio l’ho chiamata righe_fattura_auto), qualcosa tipo:

righe_fattura::id_fattura = righe_fattura_auto::id_fattura AND
righe_fattura::KP ≠ righe_fattura_auto::KP

dove righe_fattura::KP è la chiave primaria della tabella.
Fatto questo, diciamo che il campo numero progressivo  sia righe_fatture::nprog: metti un semplice calcolo, basato sul contesto righe_fattura qualcosa tipo: max(righe_fattura_auto::nprog)+1

e a questo punto l’utente può fare quello che vuole, ma la procedura è abbastanza robusta.

.g.

Giulio,

m’inchino davanti a tanta conoscenza, e spiegami questo ”conteggio con autorelazione per la chiave primaria”.

Tu mi dici che se hai una gestione a testata e righe (l’es. più immediato è la fattura) non fai immettere le righe tramite un portale correlato alla testata ma usi una ”procedura più strutturata”.  Riesci, se puoi e vuoi, a darmene un’idea a grandi linee? Sono molto incuriosito.

Perdona la mia ignoranza, ma il mio background è formato da anni di programmazione Cobol dove ti dovevi far tutto, anche l’interfaccia utente, e certe tecniche sono per me come la Luna…

Resto comunque convinto che FM sia un ottimo strumento di programmazione, ma gli errori andrebbero sanati al più presto se non vuoi che i clienti perdano fiducia.

Grazie mille per il supporto

Mario Bellini

ciò detto, posso capire la tua irritazione, mi ricordo che nel passaggio fra la 7 e la 8 (e pure con il malefico bug dei globali fra la 8 e la 8.03) ho invocato santi e divinità con convinzione e entusiasmo. Tuttavia, nel tempo mi sono reso conto che è ua caratteristica dello sviluppo di FM (che deve comunque evolversi garantendo la retrocompatibilità in un sistema ”chiuso”) e che quindi è più semplice seguire la filosofia del programma che remare contro oppure andare borderline, a meno ovviamente di un motivo preciso.

.g.

Dico che secondo me la FileMaker non lo vede come un ”errore” ma come una caratteristica del motore di calcolo su una funzione che può dare anomalie se la usi impropriamente. Le modifiche che FMI fa ”sotto il cofano” possono essere anche profonde senza per questo che si riflettano sull’interfaccia (basti pensare alla differenza su vai a record correlato fra la 7 e la 8 o su Evaluate() fra la 12 e la 13).
premetto che nelle nostre soluzioni facciamo inserire raramente dati da portale se c’è più di un campo (preferiamo procedure più strutturate), tuttavia per quanto riguarda la creazione di record da portale, è abbastana documentata: il record viene creato nel momento in cui l’utente scrive il primo campo, ma non viene salvato fino a che non viene salvato il record principale. Ma questo a livello di struttura c’entra abbastanza poco, nel senso che se ti serve un semplice ordine ti basta il simbolo specifico, se invece ti serve una numerazione più solida puoi utilizzare un conteggio con autorelazione per la chiave primaria, che è totalmente scollegato dall’interfaccia.

miei 2 cents

.g.

Giulio,

resta comunque il fatto che la nuova versione contiene questo errore, secondo me grave, secondo te veniale. Io uso rarissimamente l’immissione automatica ma in questo caso l’ho sempre fatto senza problemi. Gestire questa chiave a livello di struttura? Mi fido ancora meno di FM visto come gestisce le righe di un portale: ad es. non si coglie quando la riga del portale viene registrata: quando viene immesso uno dei campi della riga? Quando c’è una variazione o anche se il valore rimane lo stesso? E come riesci a cogliere se l’utente è posizionato su una riga nuova o su una già registrata?

Io per il momento aspetto che se ne accorgano e rimettano a posto in una prossima release; non ho fretta. Non mi pare che tra la 15 e la 14 ci sia stata una rivoluzione di cambiamenti. Tu cosa dici?

Ciao

Mario Bellini

Buongiorno, Mario.
diciamo che assegnare un progressivo riga mediante la funzione get(rigaportaleattiva) è un utilizzo fantasioso della stessa.
Capita spesso che ci siano delle modifiche non (o poco) documentate al motore di calcolo, soprattutto sul focus e la gestione dei portali e delle relazioni, quindi è sempre meglio seguire le best practices, una delle quali recita che le chiavi primarie (progressivi, etc) andrebbero gestiti a livello di struttura e non utilizzando funzioni legate all’interfaccia.

facci sapere!

.g.