Creare tabelle access

martedì 18 maggio 2004 - 15.13

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: mar 18 mag 2004 - 15:13

Ciao a tutti,
le mie applicazioni multi utente si appoggiano su db access. Sul server metto il db vero e proprio e sui clients metto db con tabelle collegate (con l'apposita procedura di access).
Capita, però, che negli aggiornamenti del programma, vi siano delle modifiche al database.
Io non posso, ogni volta, prendere il db che è già in produzione ed aggiornarlo.
vorrei creare un eseguibile che vada a:
-modificare i campi di tabelle gia esistenti
-creare tabelle nuove ed aggiornare i db con le tabelle collegate.
qualcuno sa come si fa?
Ciao e grazie

alextyx Profilo | Expert

668 messaggi | Data Invio: mar 18 mag 2004 - 15:18

Caro Pecos, ma perchè usi tabelle collegate? Io nn so bene come funzionino, ma nn ho mai sentito la loro mancanza! :-)
Perchè nn lavori direttamente sul DB residente sul server?
Probabilmente avrai ottime ragioni, ma ho bisogno di capirle x tentare di darti una mano. Ciao.

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: mar 18 mag 2004 - 15:20

Io crdevo che velocizzassero l'accesso al db in caso di più utenti collegati contemporaneamente. non è così?

alextyx Profilo | Expert

668 messaggi | Data Invio: mar 18 mag 2004 - 17:26

Conosco poco come ACCESS usa le tabelle collegate. Dimmi un po' PECOS, ma le tabelle collegate contengono dati diversi da quelli del database centrale? Insomma, da quello che capisco, ogni utente dovrebbe avere una o più tabelle soltanto per il suo uso, oppure gli stessi dati li usano in più di uno? Come ti sei regolato, in questo caso, per evitare che più utenti modifichino lo stesso dato?Hai stabilito un locking? Può anche darsi che l'uso di tabelle collegate ti velocizzi il DB. Nn ho mai pensato ad una architettura del genere, francamente, anche perchè quando parlo di multiutenza penso a più utenti che potenzialmente modificano gli stessi dati. In questo caso le tabelle collegate (che, ripeto, sono quasi delle sconosciute x me), dovranno pur riferirsi ad una tabella campione presente sul server, per bloccare i record, aggiornarli, ecc... e quindi nn ci vedo grandi vantaggi, ma potrei sbagliarmi, ovviamente. Io uso un solo DB sul server e accedo ad esso tramite ADO. Laddove c'è possibilità di accesso contemporaneo, prevedo un locking di tipo pessimistico sul record e ovviamente uso un cursore lato server, in genere di tipo KeySet. Se usi ADO.NET, nn dovresti avere problemi,il database se lo ricostruisce già lui localmente, col Dataset. Io nn ho mai notato grandi problemi, ma è vero che ho database piccoli, con tabelle piuttosto leggere. A te la parola, PECOS....intanto spiegami come accedi ai dati, così magari inizio a farmi un'idea più precisa :-) Ciao.

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: mar 18 mag 2004 - 17:59

Come prima cosa ti ringrazio per l'interessamento. Il db sul server contiene tutti i dati e quelli sul client sono fittizi: le tabelle che contengono sono solo dei link al db sul server, mentre le query sono in locale. Se vuoi ricostruirti la struttura apri un tuo db access e vai in "Strumenti" -> "Utilità database" -> "Divisione guidata database" e ti ricostruirà la mia situazione.Access stesso dice che così si riduce il traffico di rete e migliora la gestione multiutente. Il db così gestito si appoggia anche sul file .mdw che regola utenti, gruppi e privilegi.
Per caricare i dati uso una connessione oledb, dei dataadapter e carico tutto in un dataset per poi gestire i dataview coi quali modifico i records.
Non gestisco nessun tipo di lock, le tabelle si "auitogestiscono" e con questo metodo non ho mai incontrato problemi e di modifica dei record da parte di più utenti e a velocità di caricamento dati.
Non sò, però, se il metodo è quello più corretto ed ho, come detto nel primo messaggio problemi ad effettuare modifiche strutturali al db senza averlo "sotto mano".

alextyx Profilo | Expert

668 messaggi | Data Invio: mer 19 mag 2004 - 09:44

Caro Pecos, mi interesso anche x conoscere cose nuove....non sono così disinteressato ! :-)))
Scherzi a parte, cerco di fare il punto su ciò che conosco:
Access è un File /Server, ovvero le Query avvengono sempre in 'locale', ma esso deve passarti ogni volta la tabella/e su cui eseguirle. Mi pare di capire che con questo escamotage ACCESS ti lascia permanentemente i dati presso il client, preoccupandosi esclusivamente di mantenerli allineati col DB centrale. Questo assomiglia all'utilizzo di un cursore lato client, che infatti lavora sempre su una copia dei dati. Se ho ben capito utilizzi ADO.NET con i suoi strumenti, quali il Dataset, il Dataadapter, ecc... Nn li conosco ancora bene, perchè x adesso nn li ho usati, ma nn li ho usati xchè ...se li conosci li eviti, se li conosci nn ti uccidono! :-) In effetti, sono dei gran belli strumenti, ma ti impediscono il locking pessimistico dei record. Credo si possa implementare una sorta di lock pessimistico impastoiandosi in un improprio utilizzo delle transazioni, ma è comunque fortemente sconsigliato. Nel tuo caso, dal momento che il dataset è una copia dell'intero database, comprese relazioni trra tabelle, ecc... e dal momento che è stato fatto apposta x lavorare disconnessi e limitare il traffico di rete, penso che tu possa accentrare tutto il Db senza perdere in velocità. Sarei più io, casomai, ad averne bisogno! Una domanda, hai mai provato a far lavorare due utenti sullo stesso record, contemporaneamente, per vedere quale dato viene alla fine messo nel DB? Cmq, potrai sempre contare sul locking ottimistico, che però devi gestirti da codice. Io ho preferito tenere concentrato il DB su un solo file, che mi rimpallo, copiandolo, dal server al notebook, quando devo lavorarci a casa. Ho anche delle procedure di controllo, che mi eseguono delle verifiche x ripulirlo in caso di crash avvenuti in momenti critici (o di qualche bug ancora da sistemare...eh,eh,eh :-)) )
Mi rendo conto che nn stiamo ancora affrontando il tuo problema principale, ma fare chiarezza può aiutarci a capire come aggredirlo e soprattutto se si stanno usando gli strumenti adatti. Mi spiace di nn sapere utilizzare i dataset, forse da un certo punto in poi sarà necessario l'intervento di qualche altro amico che utilizzi quello strumento. Ma almeno, leggendo questi post, partirà con idee più chiare su cosa deve fare :-)

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: mer 19 mag 2004 - 12:41

In effetti non ho mai provato a lavorare contemporaneamente sullo stesso record da più postazioni, ma è una prova che voglio fare. Il problema però rimane sempre quello: sai creare su un db access una tabella e definirne i campi via codice?

alextyx Profilo | Expert

668 messaggi | Data Invio: mer 19 mag 2004 - 16:27

Nn l'ho mai fatto. Ho scorso qualcosa leggendo vari libri. Con un po' di calma potrei avere le informazioni che ti servono. Ho un amico che lo faceva in VB6, ma credo che sia comunque un buono spunto. Ad ogni modo è tuto basato su comandi SQL se nn ricordo male. Cerco di informarmi o di ricercare qualche notizia su un libro che ho sottomano. Tu, magari, controlla se il dataset fa quello che dico io. Potresti semplificarti la vita non di poco. Ciao

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: mer 19 mag 2004 - 17:54

lo faccio subito, così mi tolgo il dubbio. Ti farò sapere. Ciao

alextyx Profilo | Expert

668 messaggi | Data Invio: ven 21 mag 2004 - 10:07

Caro Pecos, come promesso mi sono attivato e ho reperito le informazioni che ti servono, nel senso che ho sotto gli occhi le pagine che descrivono come creare tabelle da codice. Il problema è che nn so come condensare 5 pagine in un post. Cerco di darti degli spunti, poi magari, cercando articoli o altri esempi su internet, potrai chiarirti meglio la cosa.
La creazione della struttura delle tabelle, in SQL, si realizza con l'istruzione CREATE TABLE. Devi specificare gli attributi e i tipi di dati. Tipi frequenti, previsti dallo standard ANSI, sono:
CHAR(n) n=numero caratteri
CHAR VARYING(n)
DEC(t,f) t=cifre(max.15) di cui f sono i decimali
SMALLINT Integer a 2 byte
FLOAT(n) Numero a virgola mobile. Con n tra 1 e 21 il formato è a precisione semplice(8Byte) tra 22 e 53 è a doppia precisione. Si può usare REAL nel primo caso e DOUBLE PRECISION nel secondo.
DATE data nel formato AAAA-MM-GG in molti DBMS equivale a CHAR(10). I vari DBMS in commercio adottano in parte questi tipi e solitamente ne aggiungono altri nn a standard ANSI.
Esempio:

CREATE TABLE Studente
(matricola CHAR(8), cognome CHAR(30), nome CHAR(30), data_nascita DATE, indirizzo CHAR(50), corso_laurea CHAR(30), esami SMALLINT, laureato CHAR(1), note CHAR VARIYNG(255))

Degli attributi possono essere associati a particolari proprietà. Può essere imposto che un attributo nn assuma mai valore nullo, oppure che faccia parrte della chiave primaria, oppure che sia una chiave esterna. Tali 'vincoli d'integrità' possono essere specificati nel comando CREATE TABLE
In genere si usano NOT NULL e UNIQUE (nn ammette valori duplicati di questo campo)
Esempio:

CREATE TABLE Articolo
(........., codice INTEGER CONSTRAINT V1 UNIQUE, ......)

Qui a 'codice' è stato imposto un vincolo (CONSTRAINT significa vincolo, come sanno i nostri beneamati della BCE con i loro BUDGET CONSTRAINT che ormai tutti i paesi di Europa si accingono allegramente a sforare :-) ) il cui nome è V1 e che costringe il codice ad essere univoco.

Riassumendo, di base quello che vuoi fare tu lo si realizza con comandi SQL (credo si usi EXECUTENONQUERY). Bisogna controllare quali attributi permette il database in uso. Esistono comandi anche x rimuovere tabelle e campi di tabelle, se nn sbaglio, ma nn li vedo in questi esempi. Ho un paio di libri su SQL che ho consultato solo per quanto riguarda le Query di selezione e scalari. Cercherò di reperire qualche ulteriore informazione, ma nn riuscirò mai ad esaurire l'argomento in dei posts del forum. Penso sia più produttivo se, sapendo in che direzione muoverti, attivi una tua personale ricerca, nn disdegnando una buona visita in libreria, onerosa per le nostre povere tasche, ahinoi, ma talvolta estremamente proficua sotto altri aspetti. Ciao e buon lavoro.

pecos81 Profilo | Junior Member

68 messaggi | Data Invio: ven 21 mag 2004 - 16:13

Ciao Alextyx,
innanzitutto ti voglio ringraziare di cuore x l'attenzione che hai dato al mio problema, poi...senti qua!
L'utilizzo delle tabelle collegate di Access migliora la gestibilità per utente. Si possono definire proprietà ed autorizzazioni per ogni utente e gruppo.
Nonostante l'utilizzo di questa utility, se 2 o + utenti cercano di modificare lo stesso record il comportamento del programma (senza gestione ottimistica,pessimistica, etc etc dei records) è: due utenti caricano il dataset, il primo che lo modifica e salva va liscio, al secondo dà "Concurrency violation". Cosa ho fatto? Ho racchiuso tutto in un try e catch e se il numero dell'errore corrisponde all'eerore sopracitato allora mi da un amessagebox dove mi avverte che siamo in troppi a voler modificare il record. Per le mie necessità questo basta.
Altra cosa: la benedetta creazione di tabelle!
Girando x la rete mi sono avvalso di due siti per raggiungere la soluzione. Ecco i link (spero ke ti possano essere utili):

http://www.able-consulting.com/tech.htm (ci sono un sacco di connectionstring)

http://www.codeguru.com/vb/gen/vb_database/microsoftaccess/article.php/c5149 (c'è il mio caso)

Ora devo capire se posso, sempre da codice, creare collegamenti a tabelle.
Questo credo che sia davvero dura, ma nel peggiore dei casi sovrascrivo il db con le tabelle collegate tanto non contengono dati ma solo, appunto, links!

ringraziandoti ancora per lo sbattimento ti saluto e se la prox volta sarai tu ad avere un problema, sarai ricambiato con la stessa moneta.

Ciao ciao

alextyx Profilo | Expert

668 messaggi | Data Invio: ven 21 mag 2004 - 16:34

Figurati Pecos, sei troppo buono, ho solo reperito un libercolo da sopra uno scaffale! :-)
Anch'io faccio come te, ma nel mio caso, avendo un locking pessimistico, quando un utente entra in modalità modifica, il record nn è più modficabile da altri e se tentano di entrare anch'essi in modifica, vengono avvertiti dell'impossibilità di farlo (sempre con un Try-catch, come nel tuo caso). Il tuo mi pare sia un caso di locking ottimistico, in cui l'utente viene avvertito che mentre indugiava a chiacchierare, un altro gli ha soffiato dal magazzino l'articolo che finalmente era riuscito a piazzare al cliente, dopo una estenuante trattativa :-) E' comunque il sistema che usa ADO.NET e mi sa che dovrò piegarmici anch'io, prima o poi. Per gli accessi e tutto il resto, devo dire che preferisco filtrare tutto da codice, se necessario, ma capisco cosa intendi. In pratica, mentre io uso ACCESS davvero come un contenitore stupido, tu, conoscendolo meglio di me, tendi ad usare delle funzionalità che io delego al codice. Buon lavoro Pecos, avremo sicuramente altre occasioni di impazzire su qualcosa e...grazie x i link! :-)

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !