Newsgroup: it.comp.appl.access
Titolo: Maschere associate o dissociate?

Utilizzo una maschera per fare data entry
Genero circa 12.000 record all'anno
Mi occorre conservare i dati almeno per 3 anni
Utilizzo per questa operazione un solo FE per il momento. Il BE è condiviso 
in Rete
Domandone:
E' corretto utilizzare la maschera in modo associato o è meglio di no?
Quali sono i vantaggli e gli svantaggi dei due metodi?
Grazie a tutti per gli insegnamenti
Mario

 E' corretto utilizzare la maschera in modo associato o è meglio di no?
Ovvio che è corretto: qualunque metodo d'associazione tu utilizzi (e
l'onerosità NON è uguale) i dati al client per la visualizzazione li devi
mandare.
Ciao.

 ha scritto nel messaggio
news:d84kjn$8kg$1...@balena.cs.interbusiness.it...

La cosa potrebbe essere da chiarire in modo più
avanzato.
L'utilizzo di Form non associate è un metodo di gestione
da valutare in quanto come ti ha suggerito Simone richiede
più codice e più controlli, ma potrebbe essere utile in
caso di applicazioni Multiutente ad esempio oppure
per gestire l'inserimento nel Server con modalità
differenti da quanto faccia la normale Associazione.
Con un quantitativo di records così se l'utilizzo è limitato
a pochi utenti in Rete oppure adirittura in MonoUtenza
direi che è la soluzione più semplice ed efficace.
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 direi che è la soluzione più semplice ed efficace.
Io invece direi che comunque, nel suo caso, anche impazzendo con controlli
disassociati (ammesso che raggiunga qualcosa di veramente funzionante) non
otterrebbe vantaggi prestazionali   :-)
Ciao, Simone

 Ciao, Simone
Non sono in grado di valutare il suo caso in modo così completo, mi sono
solo
limitato a dare una spiegazione che veda entrambi gli scenari, sarà
lui ad approfondire la questione ed a testare le differenze.
Gestendo bene NomiControlli e NomiCampi sai certamente che la gestione
di una Non associata si riduce a poche righe di codice, omettendo la
possibilità di delegare al Server_SQL eventuali controlli o validazioni.


 possibilità di delegare al Server_SQL eventuali controlli o validazioni.
Mettiamo da parte SQL Server (che è un pochino OT nel contesto della
richiesta origine del Th), non sono d'accordo sulla semplicità di gestione
di una Form Unbound, anche gestendo bene i nomi dei controlli.
Come già ho scritto, la gestione di viste tabellari sarebbe estrememamente
complessa.
Ciao, Simone

 Ciao, Simone
Ciao
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


Ciao come ti ho gia detto al CISA
sicuramente dissociate (ci puoi gestire quello che vuoi via codice)
Stkabisa

 [CUT]

Replico qui per tutti.
Probabilmente nell'applicazione che sto facendo non servono le maschere 
dissociate.
Però sarei molto interessato ad imparare a usarle, perché "intuisco" da 
quanto dite che sono utili.
Tenete conto che conosco poco il VBA uso access da qualche mese.
La richiesta se è possibile è la seguente:
Esiste una qualsiasi applicazione con maschere dissociate da scaricare a 
scopo didattico per studiare il codice?
Vi ringrazio e scusate l'ignoranza.
Ciao
Mario 

 Mario
check your email. 

> check your email.
Grazie 

 al Bound decisamente più invasivo.
Scusa Alessandro ma allora di cosa stiamo parlando?
In un'applicazione, piccola che sia, le maschere a visualizzazione singola
non svolgono certo la parte "del leone"...
I programmi di Data Entry basilari e a utilizzo continuo (Prima Nota,
Ordini/Bolle/Fatture) *devono* contenere sottomaschere tabellari.
E poi le rubriche Clienti/Fornitori, gli scadenziari, gli statistici a
video, etc.
Peraltro la maggioranza dei gestionali, commerciali e non, offre la
possibilità di visualizzare in forma tabellare anche le anagrafiche base
(una visione più globale, più facilità di manutenzione, etc.).
Si può discutere su come prefiltrare i dati, riducendo al minimo i casi di
visualizzazioni tabellari ingolfate da moltitudini di records ... ma non
mettere in discussione la "centralità" della visione tabellare in una
gestione moderna.
Comunque, senza andar tanto lontano: prova a rifare l'.mdb d'esempio
Northwind .mdb senza controlli Bound (e bada bene che non si è ancora
parlato di Reportistica).

Ma non discuto la facilità di gestione in casi "scolastici" come l'esempio
più sopra.
Tuttavia nell'ambito di un'applicazione reale ci fai poco con quel codice:
le viste tabellari?
La reportistica?
Senza contare poi SubDatasheets (qualcuno li usa, non io per la verità) o le
visualizzazioni Pivot (queste sì fanno molto comodo).
In conclusione: Access va usato con gli strumenti preforniti da MS (a
partire dagli oggetti BOUND), diversamente si perdono le caratteristiche RAD
del prodotto e molte features potenzialmente interessanti.
In tal caso, va da sè, sarebbe stato meglio scrivere l'applicazione con
ambienti non RAD...
Tra l'altro esistono molti modi d'utilizzare gli oggetti Bound: non sta
scritto da nessuna parte che si debba associare tutto nel Design della Form
... facendolo a Runtime durante l'utilizzo della Form (quando ne valga la
pena) si risolvono facilmente i problemi prestazionali origine di Thread
come questo  :-)
Ciao.

parlato di Reportistica).
Credo che alla base di tutto ci siano esperienze lavorative differenti
e forse non confrontabili su tutto, ma mi ripeto per l'ultima volta non
ho
detto che è meglio UNBOUND è una possibilità da non sottovalutare
ma occorre conoscere.
Io nel caso in cui uso UNBOUND non troverei altro che rotture di
scatole che così mi evito, altri vedono UNBOUND un mostro altri che
usano VB o altri linguaggi che non supportano BOUND_Object sono
costretti.
Ciao.
@Alex

Direi che su questo argomento si potrebbe formare un gruppo di studio
composto da entrambe e da chi altro vuole partecipare
per esaminare il tutto in modo approfondito e sistematico.
.
Potreste quindi esporre le conclusioni nel prossimo CISA.
Sarebbe molto interessante... che ne dite? ;-)
Ciao
MArio

 Mario
e' assolutamente opinabile sia l'una scelta che l'altra.
non è il numero di record a farti propendere per l'una o l'altra soluzione.
Personalmente ti dico che io associo sempre le maschere, tranne quando o mi
serve un oggetto dove posizionare le sottomaschere
con ciui io lavoro molto, o mi serve appoggiare un oggetto tipo pulsante per
la nciare delle procedure,
ma non lo faccio associando on the fly il recordset origine maschera
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa1 - I° Conferenza Italiana per Sviluppatori Access Arezzo 4+5
Giugno 2005 Info:  
www.donkarl.com/it

 Sarebbe molto interessante... che ne dite? ;-)
Sarebbe tempo perso, è c'è poco da studiarci.
L'utilizzo di controlli unbound nelle applicazioni basate su Access è una
curiosità applicabile solo in poche situazioni (mascherine singole) e i
vantaggi prestazionali
non esistono:  basta armarsi dell'analizzatore prestazioni di win per
valutare
razionalmente la cosa.
Ciao.

ma occorre conoscere.
Mah: sì e no, parlando di applicazioni basate su Access.
L'unico utilizzo razionalmente giustificabile potrebbe essere
l'implementazione di blocchi records personalizzati (come già hai fatto
notare tu) ma resta un'idea più teorica che pratica: con le sole maschere
singole non si va da nessuna parte.
Ciao, Simone

 Ciao
Ciao e grazie
Ho cercato di proporre un argomento per il CISA2, ma come vedi non ha 
incontrato molto ;-)
Mario 

 Mario
-- 



Grazie penso di avere capito
Ciao