[vb] Salvare dati su un file generico .XXX

[lyllo]

salve gente, dopo mesi di assenza vi propongo un nuovo quesito:

il mio programma si basa su un DB access.
siccome le dimensioni risultano alquanto proibitive, (tra driver e roba del genere) vorrei sapere una cosa:

sarebbe possibile salvare in un file genereico .XXX il contenuto del form di immissione invece che in un database?

quello che vorrei è che l'utente compila il form, tutte le info dovrebbero salvarsi in un file.lyl ed essere però poi utilizzabili con le stesse caratteristiche del DB, cioè i "record" memorizzati dovrebbero poi poter essere RICERCATI, salvati automaticamente e così via.ù

il file in cui salvare vorrei fosse generico invece che un .txt per evitare che, almeno formalmente, questi risulti leggibile cliccando su di esso (ad esempio da Esplora Risorse)

[Boldan]

Puoi farlo ma devi implementare tutte le funzioni di ricerca, e non è poco...
Ho scritto una piccola classe in VB6 che permette di gestire dei file di testo indicizzati, funziona abbastanza bene, ma non ha le stesse prestazioni di un DB, soprattutto quando la mole dei dati inizia ad essere consistente.

Se intendi iniziare a scrivere delle procedure che ti permettano di lavorare su file di testo come se si trattasse di tabelle di DB fammelo sapere, potrei darti qualche indicazione utile...

Ciao!!:gren:

[lyllo]

no in realtà speravo che qualcuno mi dicesse come fare da 0...

[vonkranz]

Chi si rivede!
1,5 mesi fa ti ho mandato una mail.
L'hai ricevuta?
Penso di no, visto il post che hai fatto...... ha deciso di abbandonare il DB a causa dei problemi che ti ha dato ADO decidendo cosi' di passare ai file di Testo?
Non penso ti convenga, anche perche' implementare una ricerca affidabile e veloce, non e' molto semplice (ricerche dicotomiche ecc.)
in + devi mettere anche in conto gli algoritmi di ordinamento....
Cmq, puoi provare a gestire i file di testo tramite ODBC:
ti crei la tua DNS e poi gestisci i file via RecordSet ecc.: dovresti avere a disposizione anche funzioni di ricerca, ordinamento ecc, proprio come per i DB solo che funziona tutto su file TXT.
Io non ci ho mai provato, pero' la Micro$oft dice che la cosa e' supportata.
Prova a guardare nell'help in linea alla voce ODBC.
Ciao.

[lyllo]

mi hai abbandonato!!!!!

non ho deciso di passare ai txt per gli errori, è solo che volevo apere se fosse meglio...
tu che novità hai avuto dal mio prog?

ho iniziato a lavorare in ASP e ho cpaito il perchè del ytuo shock nel vedere la stringa di connessione al DB... :tongue:

il fatto è che credo che dovrò ricominciare tutto da capo per evitare casini.

anche se sono spaventato.
sai com'è report e cose del genere...

tu hai qualche suggerimento da darmi sull'aspetto grafico?
che con tutta quella roba da gestire non so come metterla, per avere un programma ordinato e leggibile (vorrei evitare cose alla WinMX)

[vonkranz]

Originariamente inviato da lyllo
mi hai abbandonato!!!!!

......

...non dire cosi... non e' vero!

Ti ho mandato una mail dicendoti di provare a fare una cosa e tu NIENTE!, neanche una virgola per alleviare le mie preoccupazioni nel non sapere se eri riuscito ad andare avanti con il programma...:gren:

Cmq, un primo consiglio che ti posso dare e' quello di separare le varie sezioni (inserimento dati, ricerca, cancellazione) evitando di inserire il codice tutto in un'unica routine: quindi routine + piccole possibile (che tra l'altro sono + "controllabili").

Un altro consiglio che ti posso dare e' quello di evitare la gestione dei dati con i TXT xke' quando la quantità dei dati da memorizzare aumenta, diventa difficile gestirli.

Quindi:
-fai un bel DB ordinato, magari suddividendo il piu' possibile i dati al suo interno creando tabelle "omogenee" (nel senso non mischiare capre e cavoli, non so' se mi sono spiegato), collegale fra di loro in modo razionale.(evita di inserire oggetti OLE per es. per memorizzare le immagini, ci sono altri modi meno "stressanti" per il DB)
-crea un progetto VB articolato: un form per l'inserimento/ancellazione/modifica dati, uno per le ricerche, uno per le stampe/visualizzazioni.

E non spaventarti! Lo so che rompe le OO ricominciare tutto dall'inizio, soprattutto quando uno pensava di essere quasi arrivato alla fine; ti assicuro pero' che ci impiegherai sicuramente di meno per arrivare dove sei arrivato ora, visto l'esperienza che hai accumulato durante la stesura del primo progetto.

E poi c'e' sempre il forum
Ciao!

[lyllo]

molte cose che feci all'epoca.. sono riuscito a farle solo a CuL0||||||

cmq mi spigheresti cosa intendi per:
1> suddvidere il database per non mischiare capre e cavoli
2> per dividere le routine
3> creare più form separati per le varie operazioni.

perchè:

1) non so cosa voglia intendere (includi la spiegazioni sul fatto di collegare le tabelle)
2) semplicemente ho implementato le routine che gli stessi creatori delle activeX che ho usato, si comportavano allo stesso modo
3) per la stampa c'è il report, che quindi si apre per i cavoli suoi, per la ricerca c'era il formino piccino apposito e per l'immisione c'era e da quello potevi inserire, cancellare (ricevendo tonnellate di errori) e stop.

PS: stavo scherzando sul fatto dell'abbandono, non sai quanto ti sono grato per i servigi che per gentilezza ed amicizia mi stai fornendo. ben poche persone su questo forum sono così disponibili (non che siano b@st@rd|, semplicemente sei tu una grandiosa eccezione)

[vonkranz]

1> suddvidere il database per non mischiare capre e cavoli

Creare + tabelle che contengano dati omogenei:
ad es:
un DB che contiene animali potrebbe essere composto da una sola tabella tipo

tabellaAnimali
  campoSpecie
  campoDescrizioneSpecie
  campoNumeroDiZampe                :eek: 
  campoDescrizioneNumeroDiZampe   Ri:eek: 
  campoAbitat
  campoDescrizioneAbitat

oppure composto cosi:

TabcampoSpecie
   campoNomeSpecie
   campoDescrizione

TabAbitat
   CampoAbitat
   campoDescrizione

TabNumDiZampe
   campoNumeroDiZampe
   campoDescrizione

tabellaAnimali
  campoSpecie
  campoNumeroDiZampe
  campoAbitat

e ciascun campo "in comune" della tabellaAnimali e' collegato al rispettivo campo delle altre Tabelle (e' solo un piccolo stupido esempio di quanto sia importante razionalizzare in modo corretto un DB)


2> per dividere le routine (avrei dovuto dire in modo + appropriato FASI)

Creare una sezione (form) di inserimento dati, una per la modifica/ cancellazione, una per le ricerche (ed eventuali modifiche sul campo trovato), una per le stampe (si puo' ad esempio prevedere vari tipi di stampa con vari ordinamenti e che so' stampare soltanto un certo range di dati)

3> creare più form separati per le varie operazioni.

Ciascuna delle sezioni di cui al punto 2 dovrebbe risiedere su un form proprio (le sezioni che hanno molti "aspetti" in comune possono risiedere su uno stesso form che, a seconda di vari flag chiamino una routine piuttosto che un'altra)

Ti ho detto questo perche', analizzando il codice che tempo fa mi avevi mandato, ho notato che facevi tutto nell'evento click della commandBar e decidevi cosa fare utilizzando un Select sul parametro che ti veniva restituito dall'evento (mi pare fosse index, ora non ricordo).

E' meglio, ad esempio, prevedere 4 commandbutton:

1 per Aggiungere un record al DB (cmdAggiungi)
1 per Aggiornare i dati del record (cmdAggiorna)
1 per Cancellare il record (cmdCancella)
1 per Annullare le modifiche (cmdAnnulla)

il codice relativo (ad es. RecordSet.AddNew) lo piazzi nell'evento Click del CommandButton corrispondente.

Il tutto resta + sintetico (routine + piccole) ed e' + facile da gestire.

Originariamente inviato da lyllo

....
PS: stavo scherzando (lo so ) sul fatto dell'abbandono, non sai quanto ti sono grato per i servigi che per gentilezza ed amicizia mi stai fornendo. ben poche persone su questo forum sono così disponibili (non che siano b@st@rd|, semplicemente sei tu una grandiosa eccezione)

:commozione:

[lyllo]

oddio non è che abbia capito molto...

ma comunque...

(colpa mia)