Newsgroup: it.comp.appl.access
Titolo: Informazioni aggiuntive su campo

Salve a tutti,
devo sviluppare un'applicazione dove, per quasi ogni campo della tabella 
principale (che verrà visualizzata in una maschera continua) devo poter 
associare delle informazioni aggiuntive: 
- uno "stato", che serve per indicare se il valore del campo è definitivo o 
temporaneo (e che verrà manifestato cambiando il colore del controllo);
- un testo libero, dove l'utente può memorizzare annotazioni sul valore 
inserito;
la prima cosa che mi è venuta in mente è quella di creare tanti campi 
aggiuntivi (boolean per lo stato, testo o memo per le annotazioni), che 
renderebbe la gestione della maschera abbastanza semplice, ma provocherebbe 
(credo) uno spreco di memoria.
Avete qualche soluzione più efficiente da suggerirmi, tenendo conto che 
nella maschera continua dovrò evidenziare le celle in funzione del loro 
stato e gestire una finestra secondaria con associato il campo annotazioni?
Grazie,
BJ

Brown Jenkin ha scritto:

Ti conviene fare come hai già intuito e mettere i campi aggiuntivi nella
stessa tabella.
Spreco di memoria... se i dati ti servono, da qualche parte li dovrai pur
salvare, no?
Se usi access 2000 o successivi puoi usare la formattazione condizionale
per cambiare i colori delle caselle in base al valore del flag stato.
Namor
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 pur salvare, no?
Non avevo specificato che, probabilmente, la maggior parte di questi campi 
per le annotazioni resteranno vuoti, comunque complicare la cosa non ne 
vale la pena. Proverò a ridiscuterne con il cliente, sperando che un solo 
campo memo (a livello di record) possa essere sufficiente.
Ciao,
BJ


[CUT]
Ciao.

 non come norma.
Ora come ora sono orientato per una soluzione "mista": tabella separata per 
i campi memo, campi booleani accodati alla tabella per indicare lo stato. 
Sempre se non riesco a risolvere il problema alla radice...
Grazie mille,
Ciao.
BJ

 ha scritto nel messaggio
news:Xns93FEEDAF5F07Bco...@195.31.190.131...









Non serve che crei una tabella a parte per i campi memo perche access
implementa già internamente una gestione di quel tipo. Puoi mettere tutti i
campi memo che vuoi, ma finchè non ci scrivi dentro non occupi memoria,
almeno non tanta più di quel che occuperesti con l'IDmemo e il contatore. E
semplifichi la gestione.
Namor

 il contatore. E semplifichi la gestione.
Avevo effettuato una prova in merito e se non ho fatto male i conti per un 
campo nullo se ne vanno solo 2 byte (!)...
Tenere i campi in tabella rende le cose un po' più facili, ma è anche meno 
"elegante" come soluzione: un tentativo con la tabella separata lo voglio 
fare, se poi la cosa dovesse diventare troppo complessa tornerò indietro.
Ciao e grazie,
BJ


Non è che usando i campi memo non sia una soluzione elegante, + che altro se
hai una tabella con 10 campi, con le note diventano 20, per 50 campi
diventano 100, ecc... Portando le note sui campi in una tabella a parte,
puoi automatizzare l'inserimento delle note (ad es. con la pressione di un
tasto funzione), in tutte le tabelle ed in tutti i campi del database con
una gestione a se stante.
Certo devi stare attento alle modifiche delle chiavi primarie.
A proposito, per gestire i flag dei vari campi, potresti usare una sola
variabile stringa della lunghezza del N° di campi, in cui ogni carattere
corrisponde ad un campo, da gestire con una - due funzioni.
Ciao.

 carattere corrisponde ad un campo, da gestire con una - due funzioni.
Questo invece non mi era proprio venuto in mente.... Ho fatto qualche prova 
e sembra funzionare bene: una funzione per mappare i nomi dei campi con la 
posizione nella stringa, una per leggere lo stato e una per cambiarlo. 
Non sono riuscito a capire come identificare, all'interno dell'espressione 
della formattazione condizionale, il nome del campo "corrente", in modo da 
usare una sola espressione valida per tutti i campi, tuttavia ho risolto 
inserendo la condizione tramite vba all'apertura della maschera.
Ciao e grazie.
BJ

 [CUT]



Bisognerebbe dare una definizione ad "eleganza".
Secondo me è quella trovata che ti consente di ottenere il risultato
desiderato in un modo che sia il più pulito, veloce e funzionale possibile.
Stai cambiando una soluzione semplice da gestire basata su un'unica
tabella e che spreca solo 2 byte per ogni campo vuoto con una che ha due
tabelle in relazione tra loro, spreca 4 byte (il campo Idmemo) anche se il
campo è vuoto, e ti costringe a creare una maschera complicata per
l'inserimento delle note, e sarà anche più lenta ma forse non tanto da
accorgersene.
Più che di eleganza bisognerebbe parlare di convenienza e funzionalità.
Comunque provare la soluzione che hai indicato può essere un buon
esercizio, ti tornerà utile in futuro.
Visto che usi campi per le note, ho spedito al "team sitocomune" un dbase
con un esempio per fare lo zoom della casella con le note. L'aggiornamento
del sitocomune dovrebbe essere imminente, ma se ti serve prima te lo mando.


 serve prima te lo mando. Namor
Per il momento non è urgente, ci sono anche altri aspetti che devo 
discutere con il cliente prima di iniziare lo sviluppo vero e proprio, 
comunque ti ringrazio molto per la disponibilità.
Ciao,
BJ


Me.ActiveControl (vedi help)
Ciao.

 Me.ActiveControl (vedi help)
Dicono tutti così, ma ti assicuro che avevo già provato....
il fatto che vengano aggiunte le parentesi quadre ( [activecontrol].[name] 
) mi aveva fatto desistere, ma evidentemente l'errore era da qualche altra 
parte (ora funziona...)
Grazie ancora,
BJ

 realtà tutto può succedere (della serie: tutti i campi memo compilati...).
Attenzione che un campo memo lasciato vuoto occupa, da tue prove, 2 byte,
ma un campo numerico (contatore o intero lungo) lasciato vuoto non occupa
zero, occupa sempre i suoi 4 byte. Quindi come occupazione di spazio non
hai vantaggi.
Come dicevi, il consumo di memoria è in entrambi i casi esiguo, quindi non
sarà l'elemento discriminante. Prova con la soluzione che hai detto, poi
se incontri problemi di realizzazione puoi sempre tornare all'altra in
breve tempo.
Ciao.


 all'altra in breve tempo.
Si infatti, potrei farlo tranquillamente anche in un secondo momento, se 
per qualsiasi motivo dovessi cambiare idea.
Ciao e grazie di tutto.
BJ

Brown Jenkin ha scritto:







Ma io non parlavo dei campi vuoti nella tabella dei commenti, che
giustamente non esistono in quanto se non c'è un commento non ci sarà
alcun record associato.
Parlavo dell'altra tabella, quella prncipale: dovrai pur metterci, per
ogni campo da commentare, un numero che faccia da chiave esterna e punti
alla tabella dove salvi i commenti, no? E questo numero ci sarà sempre, in
tutti i record e per ogni campo della tabella primaria, e occuperà spazio
anche se non punta a nessun commento nella tabella "commenti". A quel
punto, invece di usare campi numerici da 4 byte che puntino ai commenti in
un altra tabella ti conviene metterci direttamente i memo da 2 byte.
Per la gestione dei flag è una buona idea quella di usare un campo
numerico e settare i singoli bit, l'ho fatto anch'io un paio di volte. Con
un intero lungo hai ben 32 bit disponibili.


 Con un intero lungo hai ben 32 bit disponibili.
Francesco aveva proposto stringhe, ma forse il formato numerico è ancora 
meglio.
Ciao,
BJ

 BJ
Si, i bit nei numeri li setti con un Or e li controlli con un And.
Namor


Puoi fare un'esempio pratico?
Una volta avevo letto come si fa ma non me lo ricordo.
Certamente con una variabile numerica č + veloce e + risparmioso, l'unico
caso in cui convenga usare una variabile stringa č quello in cui ci possano
essere stati tripli da controllare (ad es. giusto, sbagliato, non inserito),
o ancora di piů.
Ciao.

 > >> da questo punto di vista sono entrambe valide soluzioni;.......
[CUT]
Ci sono + motivi per cui gestirei le note in un file separato e non sono
legati all'occupazione di spazio, nè alla velocità di esecuzione di query od
altro.
Intanto per come è posta la questione, queste note che l'utente potrebbe
mettere o meno su qualsiasi campo di qualsiasi tabella, senza controlli o
influenze particolari sulla gestione dell'applicazione, le vedo come
un'entità a se stante da gestirsi in maniera altrettanto separata dalla
struttura portante di un database.
Il fatto stesso di vedere, stampare e gestire nella struttura di una tabella
tutta una serie di campi che alla fin fine non hanno un significato per
l'applicazione, mi porta anche logicamente a vederli fuori.
Inoltre, una vota create le funzioni che gestiscono il file di note,
dovrebbe (poi bisogna vedere all'atto pratico) essere + semplice
implementare il meccanismo in database già esistenti, senza toccarne la
struttura collaudata.
Ciao.

 Ciao.
Nel caso di una variabile "flags":
dim flags as long
flags=0 'setta tutti i bit a zero
flags=flags or 2^n 'dove n è il numero del bit che vuoi settare
flags=flags and not(2^n) 'per resettare il bit n
if (flags and 2^n) then 'dove n è il numero del bit che vuoi testare
   ...
end if
Sarebbe più corretto if (flags and 2^n)>0 then..., ma visto che viene
considerato true qualsiasi valore non zero puoi risparmiare il controllo.
Ovviamente, pena errori, n deve essere compreso
tra 0 e 7 se flags è di tipo byte
tra 0 e 15 se è un integer
tra 0 e 31 se è un long
