File in uso al programma di gestione bolle

[Franco_da_vc]

Come mi faceva notare Arco nel precedente topic Come governare un bottone in evento click una procedura complicata come questa potrebbe governare i file tramite un gestore di Data Base, attualmente la situazione può essere spiegata con questo specchietto che vi propongo:

CAPINEW.dat	Elenco dei capi su cui si svolgono le varie lavorazioni, elencati sia al singolare che la plurale
CLIENTINEW.dat	Elenco anagrafico dei negozi nostri clienti e dati inerenti agli stessi
DDTaaa@mm.dat	File riepilogativo bolla, <aaa> rappresenta la sigla di un dato cliente e viene presa dal file CLIENTENEW.dat, <mm> è il mese a cui si riferisce il file, ogni cliente genera un file simile ogni mese in cui è attivo
FATaaa@mm.dat	File finale fattura, stessa sintassi del precedente prodotto da un secondo programma che non ho ancora posto in lavorazione
last.ddt	File di memorizzazione dell'ultimo numero di D.D.T. usato (contiene solo quel numero
last.fat	File di memorizzazione dell'ultimo numero di fattura usato (contiene solo quel numero
LISTINO.dat	File che contiene il listino prezzi di un particolare negozio (quello relativo alla form di cui stavo scrivendo il codice nell'ultimo post su cui discutevamo
LISTINOaaa.dat	File che contiene il listino prezzi di tutti gli atlri negozi, <aaa> rappresenta la sigla di un dato cliente e viene presa dal file CLIENTENEW.dat, ogni cliente di questi ultimi dispone di un proprio file

Bisogna anche aggiungere che i file CLIENTINEW.dat e LISTINOaaa.dat dispongono di un loro particolare programma che li edita, per ora questi programmi non sono ancora tradotti.

Per ora non specifico i vari file come sono composti per non tediarvi troppo.

Grazie dell'attenzione.

Ciaoooooo 

[Arco]

Tutti i vari fili dat penso che siano strutturati così:
su ogni linea sono presenti tutti i dati riferiti al cliente, listino, ecc e separati tra loro con un separatore.
se devi aggiungere un nuovo cliente, ecc aggiungi in fondo una nuova linea.

Se tutti i dati presenti nei file dat li racchiudi in un database la gestione è più veloce (quando richiami un cliente ti ritrovi il suo listino disponibile senza ulteriori ricerche). Puoi tramite il linguaggio SQL fare tutte le ricerche possibili (ad esempio sapere tutti i DDT non ancora fatturati oppure i lavori ancora da terminare, ecc. Ricerche che con il tuo sistema non si possono fare) anche in tempi successivi aggiungendo pochissimo codice.
Per questo ti si consigliava di utilizzare un database.
Spero di essere stato chiaro.

[Franco_da_vc]

Grazie per l'interessamento.

Tutti i vari fili dat penso che siano strutturati così:
su ogni linea sono presenti tutti i dati riferiti al cliente, listino, ecc e separati tra loro con un separatore.
se devi aggiungere un nuovo cliente, ecc aggiungi in fondo una nuova linea.

Beh abbastanza come tu dici, ma non proprio, ti faccio un esempio:

Qui di seguito ti visualizzo il file CLIENTINEW.dat:

Codice: [Seleziona]

*CLIENTI3*
10
Nome della ditta: DITTA PINCO PALLO S.r.l.
Primo indirizzo - Riga 1: DITTA PINCO PALLO S.r.l.
Primo indirizzo - Riga 2: Via della ditta
Primo indirizzo - Riga 3: 13100 Vercelli (VC)
Secondo indirizzo - Riga 1: DITTA PINCO PALLO S.r.l.
Secondo indirizzo - Riga 2: Eventuale seconda via
Secondo indirizzo - Riga 3: Eventuale seconda città
Partita IVA: <Partita iva>
Codice fiscale: <Codice fiscale>
Tipo bolla: 1
Aspetto: BORSA
Nome file: and
Visualizzazione: 0

il primo campo: *CLIENTI3* è l'etichetta del file, in effetti quello che vedi è la terza evoluzione del file stesso, di seguito il numero 10 è il numero di clienti registrati, qui ne vedi solo uno ma nel file originale sono contenuti di seguito 10 blocchi con i dati di 10 clienti diversi, non sto a spiegarti i vari dati che si susseguono, ma penso che data la prima parte di ogni riga siano molto comprensibili.

Che ne dici è un bel casino?

Ciaooooo

[Gianluigi]

Se non sono un'esagerazione, i dati ti conviene caricarli manualmente dopo che hai creato il programma con le maschere di immissione.
Se invece sono tanti allora occorre studiarci un po anche perché ci sono campi a più valori e come ho già detto...

 

P.S. ti stavo preparando un esempio di come caricare i dati nelle tabelle ma visto il file ho interrotto immediatamente 

[Arco]

I dati mi sembrano in linea con un normale gestionale di una ditta.
Se non hai letto questa discussione leggila potresti trovare degli spunti utili.
http://www.gambas-it.org/smf/index.php?topic=5473.0

[Gianluigi]

Franco,
ti allego due esempi molto semplici per darti un'idea di come potresti estrapolare e poi importare i dati nelle tabelle.
Naturalmente creare un database da zero non è cosa semplice occorre ragionare su tutti i dati che servono e poi creare le tabelle aggregando i dati in relazione fra di loro.
Io non so se lo hai mai fatto se no, ti converrebbe allegarli e sentire un po cosa abbiamo da dirti.

Ci ho inserito anche lo schema parziale proposto a suo tempo da Sotema nella discussione poi abortita di "Rubinetto felice" allora non l'avevo capito ora a mente fredda mi sembra molto valido, non credo che tu abbia bisogno di cose tanto complicate ma potrebbe ispirarti.
Comunque ti sconsiglio di leggere quella discussione, perderesti ogni fiducia in me 

Arco,
ho finalmente dato un'occhiata a myReport e devo dire che non è poi così male.
In effetti ricordavo male.

Attenzione però che le variabili globali sono tutte pubbliche mentre dovrebbero essere private, la tool bar è sbagliata e altre cose meno importanti, però un'idea a Franco la può dare come giustamente avevi scritto.

 

[Franco_da_vc]

Per prima cosa ringrazio sia GianLuigi che Arco che si stanno prodigando con esempi e rimandi ad altre discussioni che sono veramente utili e che pian piano sto inglobando, purtroppo mi ci vuole un po' per seguirvi, anche perché le ferie sono finite ed il mio lavoro mi lascia veramente poco tempo a disposizione, ieri sono rientrato e tra arretrati dei 15 giorni scorsi e ciò mi è stato prospettato per il tempo a venire mi fanno presagire un mese di settembre entusiasmante, bando comunque alle ciance (o come diceva un tal presentatore della Rai: Ciancio alle bande!).

Ritengo che sia utile che vi esponga i file di memorizzazione dei dati veri e propri, partirei da quello per il cui negozio stavo codificando ultimamente il form:

Codice: [Seleziona]

*DDT01*
fac
RI1     220/12     01/06/2012
RI2     103/12     30/05/2012
LIN     Pantalone           66     3.87
LIN                 71     5.79
LIN     Giacca           01     5.79
LIN                 03     8.67
LIN     Pantalone           12     3.14
LIN     Giacca     2     05     1.56

Alura...
La prima linea è la solita etichetta che ci metto sempre, direte che è inutile ma.... la seconda linea è il codice del cliente a cui si riferisce il file, lo stesso che compare nel nome file, per la cronaca DDTfac@06.dbl, in RI1 ed RI2 vi sono i dati relativi alla al DDT da inserire nell'Header, rispettivamente prima linea numero e data del documento e nella seconda gli stessi relativi al documento del cliente.

Di seguito, con LIN le varie linee che compongono la bolla, che comprendono il capo su cui si esegue una lavorazione, il codice della lavorazione ed il prezzo applicato, ove non compare un nome di un capo i dati si riferiscono ad una seconda (ed oltre) lavorazione sul capo della linea precede, naturalmente ciò verrà poi gestito dal programma per le fatture.

Per ora penso che basti, vi postero anche il medesimo file per i negozi "normali".

Ciaoooo.........

[Gianluigi]

Ciao Franco,
sempre che tu sia ancora intenzionato a migrare verso un database per conservare i dati dell'attività, visto che da quanto ho inteso tu non hai esperienza di database e che questo servirebbe solo un operatore per volta io ti consiglierei di utilizzare SQLite che per un neofita è più semplice.
Ti consiglierei anche di installare DB Browswe for SQLite che aiuta per fare le prove di interrogazione.
Entrambi dovrebbero essere presenti nei repositori di Suse.

Nel file che ti ho inviato oltre alle due applicazioni per trasferire i dati c'è lo schema (parziale) che Sotema aveva suggerito per "Rubinetto felice".
Anche per il tuo database occorre fare uno schema possibilmente completo.
Per poter fare lo schema occorre conoscere tutti i dati che ti servono a far funzionare la tua applicazione legacy.
Non serve sapere come essi sono attualmente memorizzati, serve sapere quali sono e tutti quanti.
Ti basta guardare i dati memorizzati e stilare un elenco molto chiaro, ad esempio:

Data di ricevimento ordine cliente
numero ordine cliente
codice cliente
nome cliente
il nome del contatto
indirizzo cliente completo di....
indirizzo di spedizione completo di...
telefono cliente
fax cliente
mail cliente
il tipo di capo: giacca, pantalone, camicia...
il tipo di intervento: ...
ecc.

Se ad esempio alcuni clienti hanno più indirizzi dove recapitare la merce scrivilo, insomma più particolari tiri giù e più è facile non sbagliare.
Non ti devi preoccupare di riunirli in relazione fra loro, quello lo si vedrà in seguito, piuttosto pensa se ci sono dati che attualmente non conservi e che invece vorresti conservare.
Dovresti spiegare bene in modo che sia comprensibile anche a chi non sa nulla del tuo lavoro del perché conservi certi dati particolari, questo esercizio sarà più utile a te che a noi perché ti permetterà di capire meglio come migliorare l'applicativo, soprattutto mi raccomando non dimenticarne nessuno.

Una volta che l'elenco sarà completo di tutti i dati potrai creare le tabelle e potrai farti le utility per trasferirci i dati dai file dat, sulla falsariga di quanto ti ho spedito.

 

P.S. Avevo scritto stillare invece di stilare, ciò non significa che io sia un ubriacone 

[tornu]

Buongiorno a tutto il Forum.
Ciao Franco_da_vc,
stò seguendo con interesse questa discussione, in quanto come ho avuto modo di
dire svariate volte la programmazione mi appassiona specialmente se utilizzata
per sviluppare gestionali. Ora nel tuo caso se ti dovessi dare un consiglio,
oltre a tutte le dritte che già ti hanno dato gli altri utenti, passa decisamente
senza indugio a un database, qualunque esso sia, come opportunamente già consigliatoti
da Gianluigi. Dici di non essere molto ferrato in materia, però mi sembra che hai le
idee molto chiare riguardo l'obiettivo che vuoi raggiungere. Se opterai per questa
soluzione ben disponibile a darti il mio contributo per quanto posso e compatibilmente
al tempo disponibile, in questo caso avrei già parecchie domande da farti. 

[Franco_da_vc]

Grazie Tornu,

In effetti ho aperto questa discussione perché anch'io penso che invece di usare file diretti è senz'altro meglio usare un data base.

Da quel che ho capito il più indicato per la mia procedura dovrebbe essere Sqlite (ho scritto giusto?), in fondo non ho file enormi e non penso sia il caso di scomodare altri gestori sicuramente più performanti, ma che forse alla fine sarebbero un po sprecati.

Sto anche pensando che facendo una scelta del genere non avrebbe più tanto senso avere tanti file, uno per mese ed uno per cliente, dei dati delle bolle, non ho ben chiaro pero se si potrà integrare i vari clienti in un unico file essendo i dati registrati (come potrete veder dal prossimo post) molto diversi.

L'unica cosa che penso in antitesi ad arco (anche se la ragione sarebbe dalla sua parte) è che prima di sviluppare questo tema vorrei arrivare ad avere il processo funzionante in Linux per poi realizzare una seconda versione basata sul dbase, il progetto che sto traducendo è già funzionante e nell'altro sistema ha gia avuto versioni ed è da quest'ultima che sono partito per realizzare la quinta, quella funzionante in Linux mediante Gambas.

Caiooo 

[Gianluigi]

Franco,
io credo che per te non sia indispensabile avere un progetto funzionante su Linux.
Tu hai già le idee chiare avendo il progetto funzionante su Windows.
Rifarlo pedissequamente su Linux per poi passare a un database a mio avviso ha poco senso, dovrai operare molte variazioni in quanto il recupero dei dati sarà completamente diverso.
Come ho già avuto modo di dirti quello che conta sono i dati che tu voi ottenere e come vuoi visualizzarli e quello lo hai già fatto, anche se su altro OS.
Che senso avrebbe completare un lavoro che andresti subito a stravolgere?
Probabilmente senza riuscire a salvare nulla?

 

P.S. Ciao Tornu mi stavo giusto chiedendo quando saresti intervenuto 

[Arco]

Come ti ha detto Gianluigi non ha senso scrivere un programma per poi modificarlo.
Come inizio potresti creare una tabella per ogni tuo file.
Tutte le tabelle create vanno poi collegate in base all'uso.
Prova a postare le varie tabelle ricavate dai tuoi file (al massimo vediamo di correggerle)
Esempio
Tabella anagrafe clienti (di seguito i campi necessari)
- Nome ditta
- eventuale 2 riga ditta
- via
- cap
- città
- provincia
- via consegna
- cap consegna
- città consegna
- provincia consegna
- ecc.
Per quanto riguarda le città volendo si può creare una tabella con tutti i comuni d'Italia e automaticamente ricavare il CAP e provincia.
Spero di essere stato chiaro.

[tornu]

...
Che senso avrebbe completare un lavoro che andresti subito a stravolgere?
Probabilmente senza riuscire a salvare nulla?

 

Concordo pienamente 

P.S. Ciao Tornu mi stavo giusto chiedendo quando saresti intervenuto 

Ciao Gianluigi,
periodaccio...perriodaccio...
Non sono molto attivo sul Forum (purtroppo), ma ti garantisco che quando ho qualche minuto vi seguo sempre.
A presto   

[Franco_da_vc]

Franco,
io credo che per te non sia indispensabile avere un progetto funzionante su Linux.
Tu hai già le idee chiare avendo il progetto funzionante su Windows.

Ciao GianLuigi, senz'altro non è indispensabile la rev. 5 del programma, ma mi è utile perché solo ora inizio ad avere un po' di esperienza con il ganberetto, (intendiamoci in ogni caso concordo molto con quanto scrivete) penso che ora inizio ad avere la dimestichezza che mi serve per poter codificare in modo valido, prima chissa cosa avrei scritto....

A proposito il precedente programma non girava sotto Windovs, ma era scritto con il SuperBaasic del Sinclar Ql, quindi da li a Linux il salto non è per niente piccolo, l'ambiante era molto meno sofisticato e con poche istruzioni si poteva governare le varie periferiche.

Ciao....... 

[Gianluigi]

Franco,
io credo che per te non sia indispensabile avere un progetto funzionante su Linux.
Tu hai già le idee chiare avendo il progetto funzionante su Windows.

Ciao GianLuigi, senz'altro non è indispensabile la rev. 5 del programma, ma mi è utile perché solo ora inizio ad avere un po' di esperienza con il ganberetto, (intendiamoci in ogni caso concordo molto con quanto scrivete) penso che ora inizio ad avere la dimestichezza che mi serve per poter codificare in modo valido, prima chissa cosa avrei scritto....

A proposito il precedente programma non girava sotto Windovs, ma era scritto con il SuperBaasic del Sinclar Ql, quindi da li a Linux il salto non è per niente piccolo, l'ambiante era molto meno sofisticato e con poche istruzioni si poteva governare le varie periferiche.

Ciao....... 

Accidenti Franco,
Sinclar QL e SuperBasic diventerai un mito! Praticamente sei l'Indiana Jones del basic