Post by pileggiCiao Roberto,
era solo un momento di sclero dovuto alla difficoltà che incontravo.
Sicuramente dipendeva dalla mia ignoranza e non da Access. Ho imparato ad
usarlo in gran parte 'empiricamente' ma Access è un programma complesso, non
proprio 'user friendly'.
Come tutti gli altri applicativi della suite Office penso che Access sia
abbastamza 'user friendly' se vuoi semplicemente usarlo, ma se poi vuoi
programmarlo o studi almeno i fondamentali di Access, di VBA e di SQL,
oppure di 'momenti di sclero' ne vivrai una infinità e spesso non riuscirai
comunque a centrare l'obiettivo che ti sei proposto.
Insomma, nulla da ecceppire sull'empirismo come metodoto di apprendimento
sull'uso di Access, ma come metodo di apprendimento per programmarlo ho
delle grandissime riserve: nessuno mette in discussione il fatto che sia
molto 'user friendly' usare Word per scrivere e stampare una lettra, ma
prova a programmare Word o ancora peggio prova a programmare Excel: anche in
quei casi devi far ricorso alle macro o a VBA ed incontreresti gli stessi
problemi che incontri con Access.
Onestamente con Access hai un problema di più che non hai con Word ed Excel:
prima di iniziare la programmazione devi progettare e realizzare la
struttura e la relazione delle tabelle; fare bene questa parte del progetto
risolve, a mio avviso, il 70% della programmazione di Access e non a caso in
questo threand io e te stiamo discutendo proprio della struttura delle
tabelle (chiavi primarie e chiavi esterne) edella loro relazione (nessuna,
uno-a-uno, uno-a-molti, molti-a-molti).
Post by pileggi...non è assolutamente scritto da nessuna parte che
nel fare un join tra due tabelle il campo di join debba essere
necessariamente chiave primaria di una delle due tabelle.
Onestamente non vedo il problema, specie se la query la crei
direttamente
Post by pileggiscrivendo il suo codice SQL senza ricorrere alla griglia di struttura.
Avevo crato la query con la griglia di struttura, ma mi visualizzava
soltanto i dati, senza possibilità di modificarli. Quando rendevo chiave
primaria uno dei due campi collegati i record diventavano modificabili. Ho
dovuto risolvere togliendo dalla query la nuova tabella e aggiungendo un
campo con la funzione DLookUp. Così funziona.
Questo significa che avevi creato una query che risultava essere un
recordset non registrabile, cosa che non necessariamente è dovuto al fatto
che non esista una chiave primaria, ma è più probabile dipenda dal modo in
cui le tabelle sono in relazione tra di loro e/o dal modo in cui le hai
messe in join nella query.
I casi per i quali una query risulta non aggiornabile sono molti e li trivi
indicati nell'help in linea di Access leggendo l'argomento Quando aggiornare
dati da una query; come vedrai per alcuni casi di query non aggiornabile ci
sono delle soluzioni, per altri invece no.
Non mi sento da escludere a priori che la struttura delle tabelle del tuo
databse non sia congeniale per un database Access e che non siano rispettate
neppure le più elementari rgole di normalizzazione che vanno invece
applicate in un databse Access.
Post by pileggi...i mal di pancia a non usare chiavi univoche nelle
tabelle sono di ben altra natura e non tarderai a provarli.
Mi hai incuriosito, puoi accennermene alcuni?
Due per tutti, ma considerali solo un esempio:
1) Nel voler far riferimenti ad un record con le funzioni di aggrgazione sui
dominii (DLookup, DCount, DSumm ecc.) è molto più complesso scrivere i
criteri se non si può far riferimento alle chiavi primarie delle tabelle
2) Access per definizione gestisce database relazionali, ma per definizione
non esiste un database relazionale se non esistono le chiavi primarie e
secondarie delle tabelle; a questo punto se non vuoi creare un databse
relazionale usa un altro apllicatico, non si capisce perché usi Access.
3) E' addirittura impossibile in un progetto multiutenza gestire un FE con
Access che usi un BE su SQL Server che non abbia le chiavi primarie.
D'altra parte le regole sono regole e non si può usare Access o qualsiasi
altro applicativo senza rispettare almeno quelle fondamentali.
Post by pileggiPremetto che l'applicazione me la sono trovata già impostata e io non ho
fatto altro che continuare sulla stessa linea. Non è che non ci siano le
chiavi primarie, quelle ci sono. Non ci sono le relazioni.
E' qui a mio avviso il vero problema.
Non esplicitare le relazioni tra tabelle crea dei grossimi problemi nel
programmare con Access: te ne elenco solo alcuni:
1) Maggiore difficoltà nel creare le query basate su più tabelle usando la
griglia di struttura (se non sbaglio è un mal di pancia di cui hai già
provato i sintomi)
2) Ridurre di molto la possibilità dell'utilizzo di alcuni strumenti di
autocomposizione, strumenti dei quali chi è agli inizi della programmazione
Access non può fare assolutoamnte a meno.
3) Gestione automatica da parte di Access delle integrità referenziali tra
tabelle: rinunciare a questo automatismo penso che è semplicemente da pazzi
visto ce significherebbe crearsi a manino santa una infinità di codice VBA
per questa gestione, cosa fra l'altro possibile solo programmatori veramente
in gamba e tu, scusami, ma non mi senbra che sei ancora a quel livello. Di
contro fare un datbase che non preveda l'integrità referenziale tra tabelle
e semplicemente da pirati.
Post by pileggiho un'applicazione con tante maschere tebelle e query. Questa lavora già da
un po' e dunque le tabelle sono piene di dati. Mi accorgo che mi serve una
nuova tabella. Se voglio collegarla al resto nel modo 'ortodosso' devo non
solo creare un campo 'chiave primaria' nella tabella, ma anche dei capi
'chiave esterna' in tutte le tabelle che voglio collegare. Questo significa
creare delle query di aggiornamento per riempire questi campi, e modificare
il codice in tutte le maschere che inseriscono dei record in queste tabelle,
in modo che inseriscano anche questo campo 'chiave esterna'. Ammetterai che
si può trattare di un lavoro non indifferente, soprattutto se lo paragoni con
la volocità del sistema 'non ortodosso'.
E' qui che noi due non siamo d'accordo: io ritengo che programmare Access
con il sistema 'non ortodosso' sia mooooolto meno veloce che programmare con
il sistema 'ortodosso' visto che non si può far ricorso a molte delle
autocomposizioni e perché dovresti programmarti tu le integrità referenziali
tra tabelle che Access invece è in grado di gestire per te automaticamente;
inoltre ritengo che chi con Access crea un datbase NON normalizzato lo fa
per ignornza compromettendo, come vedi, gli sviluppi futuri, specialmente se
questi prevedono che il datbase fosse relazionale; oppure chi lo fa viene da
una esperienza di progettazione di database NON relazionali o infine vuole
scientemente mettere le cose in modo che altre persone si trovino in forte
difficoltà a mettre le mai sul suo database.
Ipotizzo che il datbase che devi modificre sia un database NON relazionale
realizzato però stranamente con Access e che ora tu vorresti innestare in
esso nuove tabelle rendendo relazionale TUTTO il database: penso che questa
non sia una cosa possibile e devi pertanto a lasciare il datbase NON
relazionale anche dopo l'inserimento di nuove tabelle, ma per fare questo
dovresti avere una buona esperienza di gestione di datbase NON relazionali,
ed essendo in un NG di Accesss penso che non sia facile trovare aiuto in tal
senso.
Post by pileggiCiao, grazie per la spegazione,
Prego.
--
Roberto
-----------------------------------------------------
il Sito Comune di it.comp.appl.access
http://www.sitocomune.com
----------------------------------------------------