Newsgroup: it.comp.lang.visual-basic
Titolo: Numero di campi molto alto

Sto avendo problemi con una tabella Access che un numero di campi piuttosto
elevato, circa 250. Il limite massimo è 255.
Quando apro da VB la tabella ottengo un errore di protezione nel kernel. Ho
il sospetto che il problema derivi anche dal fatto che una buona parte dei
campi ha dei nomi piuttosto lunghi. Ho tentato di accorciarli un po' ma ho
comunque bisogno che il nome sia esplicativo.
Il problema si verifica anche con la tabella vuota. Eliminando una ventina
di campi il problema non si manifesta più. Oltretutto non è sistematico, ma
si verifica dopo un numero variabile di volte (da 1 a 6-7 in genere) che la
tabella viene aperta e chiusa.
Il problema è gravissimo perchè ho già consegnato il software ormai completo
al cliente, che però mi ha chiesto di aggiungere questi nuovi campi. Non ho
nessuna intenzione di cambiare proprio adesso la gestione, dividendo i campi
in tabelle "parallele". Devo assolutamente risolvere.
Qualcuno ha mai riscontrato lo stesso problema?
In ogni caso se qualcuno potesse aiutarmi gli manderei l'MDB e un piccolo
programmino di test per verificare magari se con VB6 il problema si verifica
ugualmente (io sviluppo in VB5 con SP3).
Grazie a tutti
--
Nino Stella
Inteldata Srl
email: 
nino...@tin.it

Credo che non hai molte alternative...
Che succede se poi devi aggiungere altri campi?
Però forse potresti fare così (per non fare troppe modifiche al programma):
Apri l'mdb con access suddividi la tua tabella in più tabelle relazionate
fra loro.
Poi crei una query (con lo stesso nome della tabella originale, che intanto
avrai rinominato e suddiviso) che raggruppa tutti i campi.
Tutto questo però presupponendo che sulla tabella in questione (nella tua
applicazione) non hai usato istruzioni tipo "seek".
Spero di esserti stato utile e soprattutto spero di essermi spiegato
chiaramente.
P.S. Sinceramente non riesco ad immaginare il perchè di una tabella con
tanti campi...
 __     __
<o>  <o>
      []
  \____/   ......(Ciao!)
Pasquale Minerva
mine...@libero.it

 wrote in message



Si tratta di una specie di questionario con piů di 200 domande.


 Si tratta di una specie di questionario con più di 200 domande.
Ok credo di aver capito!
A mio avviso la soluzione migliore in questi casi è progettare diversamente
il database, ad esempio (...ovviamente l'esempio è molto semplificato...)
così:
_________TABELLE______________
TabellaALUNNI
------------------
IDalunno (*)
Nome
Cognome
.......
TabellaRISPOSTE
-------------------
alunnoID (#)
domandaID (#)
risposta
........
TabellaDOMANDE
--------------------
IDdomanda (*)
domanda
......
________RELAZIONI_________
TabellaALUNNI[IDalunno] ----> TabellaRISPOSTE[alunnoID]
                                         1 ----> N
TabellaDOMANDE[IDdomanda] ----> TabellaRISPOSTE[domandaID]
                                                  1 ----> N
di conseguenza:
TabellaALUNNI <----> TabellaDOMANDE
                       N <----> N
___________________________
Ovviamente per adottare questa soluzione devi riscrivere un bel po' di
codice, però ci sono almeno tre buoni motivi per farlo:
1) E' la soluzione più elegante. :)
2) Potresti aggiungere alla tua applicazioni funzioni di aggiunta, modifica
ed eliminazione di domande(quindi aumenti la qualità dell'applicazione
stessa).
3) La manutenzione e modifica futura dell'applicazione ne risulterebbe
semplificata.
Per l'inserimento delle risposte te la cavi con pochissimo codice...
poi se invece è proprio necessaria una visualizzazione del tipo:
ALUNNO    DOMANDA1    DOMANDA2       ecc..
-----------    ---------------     --------------    ------------
Giovanni          15                           16                    20
puoi sempre creare una query a campi incrociati facendo sempre attenzione
che non superi i 255 campi per volta...
Spero di esserti stato d'aiuto, ma forse ti ho detto cose che sapevi già...
Comunque anche se la mia analisi si basa su pochi dati, credo che questa sia
la soluzione migliore, in questi casi.
 __     __
<o>  <o>
      []
  \____/   ......(CIAO!)
Pasquale Minerva
mine...@libero.it

 la soluzione migliore, in questi casi.
Ti ringrazio davvero tanto, la tua analisi era ottima. Purtroppo non ti
avevo fornito molti dati.
Il tipo di soluzione da te proposto può essere utilizzato in tante
applicazioni, sarà quindi di certo uno spunto utile a più di uno.
Grazie ancora


 relazione 1:1 tra loro.
E così il danno l'avrei fatto io. Io utilizzo un sistema di database che ha
dei limiti dichiarati, e su questo niente da ridire. Tutti i sistemi di
database ne hanno.
Però se non supero i limiti dichiarati vorrei che le cose funzionino. Ho
cominciato ad avere problemi già quando avevo 180 campi. Ho dovuto ridurre
la lunghezza dei nomi dei campi per evitare l'errore nel kernel.
E' evidente che il DAO alloca un'area di memoria per contenere la struttura
della tabella. L'area però evidentemente non è abbastanza grande per
contenere grosse strutture.
Ma come li testano i programmi in Microsoft?????


Ma come li testano i programmi in Microsoft?????
Perche', li testano?
Roal Zanazzi

 Perche', li testano?
se lo facessero loro, noi a che serviremmo ? tutti i soldini che gli diamo
ci daranno ben diritto a qualcosa  ! <g>
andrea