@ Leo:
Mi pare che stiate facendo la cosa un po' troppo complicata. Come ti ho suggerito io non devi stare a guardare se il commento è all'inizio delle descrizioni, a metà, se legato alla riga precedente ecc... Lo metti dove e quando ti pare, tanto poi salvi le descrizioni in una tabella a parte per cui hai lì tutte le righe ordinate del documento.
Prima di dare un consiglio a tornu ho guardato il contenuto delle due tabelle di cui già dispone ed ho visto che la Tabella "righe si documento" non dispone di una colonna di tipo "Descrizione", dove potere inserire le righe di commento, al posto della descrizione dell'articolo. Avrai certamente notato che abbiamo ragionato sull'eventualità di aggiungere un'ulteriore colonna in detta tabella, ma vista l'impossibilità previsionale della quantità di commenti che da gestire e soprattutto la non snellezza della funzione split (secondo il mio modestissimo puinto di vista), ho consigliato la costruzione della nuova tabella "Commenti". Io non vedo alcuna difficoltà di gestione tabellare. Infatti, basta, all'apertura del documento, griglia o stampa che sia, interrogare la tabella commenti per conoscere se, per il documento in trattamento, sia presente un gruppo di righe di commento, diciamo di testata, e portarlo in output; poi, per tutte le righe di dettaglio, richiamando semplicemente le righe di commento, legate allo stesso codice-articolo, si produce l'output solo se le righe sono presenti; Infine, per le righe di commento di fine-documento, vale lo stesso ragionamento fatto per le righe di testata. E l'output è bello che pronto.
Secondo me, si tratta semplicemente di un metodo di applicazione, diverso sicuramente da quello da te suggerito, ma che porta allo stesso risultato.
Io credo che tornu abbia ragionato su tutto quello di cui è stato detto e che si sia indirizzato su un utilizzo confacente alle sue necessità. È giusta, comunque, la tua osservazione, perchè così possa ulteriormente rivedere la logica organizzativa del tutto ed optare per la soluzione più pratica. Come soluzione più pratica, intendo quella che rende l'operativià più semplice, non quella di rendere più semplice la stesura della parte di programma occorrente; quest'ultima, infatti, lo sappiamo, si svolge una volta e dopo svolta risulta una fatica già dimenticata perchè l'importante è gestire agevolmente l'input ripetitivo dei dati.
@ tornu:
No, ai interpretato male, oppure con tutte le immagini che ho allegato ti ho portato fuori strada.
Se torni indietro di qualche risposta troverai due allegati dove ho detto che sono il form e il documento stampato originali che uso realmente, gli allegati delle altre risposte ignorali, mi servivano per darti l'dea pratica.
Ho riguardato tutti i post ed ho trovato complessivamente solo tre tipi di documento, di cui uno è sicuramente un esempio, infatti riporta nelle testate di colonna le diciture "ITEM x", ma gli altri due sono:
- una, la form con la sua gridview, dove effettivamente il cod-articolo è un numero;
- l'altra, la stampa di un documento cartaceo, dove la colonna "articolo" presenta sempre lo stesso codice alfabetico di tre crt seguito un codice di 9 crt che potrebbe essere il "rif.articolo".
Da ciò, apparentemente, il cod.articolo sembrerebbe un campo alfanumerico, tuttavia se tu mi dici che il campo è definito "integer", essendo l'integer un tipo di dato di 4 byte, con un estensione numerica compresa fra "-2147483648" e "+2147483647 ", possiamo, per esempio, pensare ad un codice-articolo-commento-testata --> 11111111 ed ad un codice-articolo-commento-chiusura --> "99999999".
Se l'idea non fosse di tuo gradimento, per qualche motivo a me non chiaro, scegli tu un'altra combinazione.
Ciao.
