Newsgroup: it.comp.appl.access
Titolo: Applicazione Access su server

Ciao a tutti,
al lavoro mi sto cimentando con la costruzione di una applicazione Access
per la gestione delle commesse. Fino ad ora ho non ho mai avuto la necessità
di condividere i dati.
Ho messo l'applicazione sul server, ma se viene aperta su un PC, gli altri
non possono aprirla, neanche in sola lettura... è possibile aggirare il
problema? Ho fatto, o meno, qualcosa che non dovevo fare?
Grazie in anticipo...
Massimiliano

 wrote in message
news:kPTjb.7281$
e5.2...@news1.tin.it

Devi spezzare la struttura in 2 parti:
1)BE(Tabelle)
2)FE(Interfaccia Utente)
La 1° deve avere l'accesso condiviso, la 2° deve essere
installata su ogni Client.
Se leggi l'help c'è descritto tutto, nel menù trovi anche il Wizzard
per la scomposizione.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

> al lavoro mi sto cimentando con la costruzione di una applicazione Access
Quella suggerita da Alessandro è la soluzione tecnicamente + corretta 
anche se ti provocherà probabilmente dei terribili rallentamenti quando
collegherai le tabelle, e qualcosa dovrai riscrivere se hai usato VBA +
DAO.
Comunque io ho spostato spesso applicazioni simili alla tua (tutti gli 
oggetti in unico mdb se ho capito bene) sul server senza riscontrare i
problemi da te segnalati (altri si). Prova a controllare le opzioni di
apertura o quelle dei vari oggetti.
L'argomento è comunque molto interessante.
Sarebbe interessante approfondirlo .....
Ciao Giò


 Ciao Giò
Non sono completamente in accordo.
E' pur vero che Access non è una struttura nata per
lavorare Client_Server, ma se ottimizzi le risorse di 
Access fino a circa 8/10 utenti non dovresti trovare
sosanziali rallentamenti nell'esecuzione di attività.
Tutto deve però nascere da una corretta gestione dell'INDICIZZAZIONE
delle Tabelle e dei relativi Fields.
Se esegui Query Parametriche su Campi non indicizzati su un DB
corposo noti sicuramente grossi rallentamenti, perchè
JET elabora in locale tutto il contenuto.
Se la QRY lavora su campi ottimizzati si è dimostrato che
il traffico di dati in rete si riduce drasticamente con conseguente
aumento delle prestazioni.
Ovviamente un minimo di rallentamento tra LOCALE e RETE c'è 
non fosse altro che una Rete 10/100 non è come un BUS interno.
@Alex.


Grazie mille!
Chiedo scusa per non aver preliminarmente letto la guida. Ho pensato con un
vostro consiglio "caldo" fosse più stimolante. Grazie ancora.
--
-------------------------------------------------
Massimiliano Pratelli

 delle Tabelle e dei relativi Fields.
Quello che dici è assolutamente vero, ma è vero sempre.
Se non indicizzi correttamente sei lento a prescindere.
Io ho scritto procedure "importanti" che funzionano tuttora ma ho dovuto
rinunciare a dividere FE e BE.
E' impensabile ad esempio usare come origine dati di una form una
tabella
di 3/4000 records e popolare i combo della stessa form con dati (sempre
3/4000) ricavati da altre tabelle. Non ti passa più.
Magari non è il sistema migliore per trattare l'input ma trovandolo
estremamente efficace (e trovandolo efficace anche l'utente finale)
preferisco sono costretto a fare con 1 solo mdb.
O esistono altre possibilità ?
Tra l'altro dividendo FE e BE ho avuto anche enormi (sottolineo enormi)
problemi di memoria (esaurita).
Spero di risentirti.
Ciao
Giò  


 @Alex.
ciao @Alex,
cosa intendi per query ottimizzate?
Sono sempre avido di ottimizzazioni e cerco di rubare sempre tempo alle
esecuzioni di query.
MAssimiliano


La prima parte del tuo discorso è la BIBBIA, purtroppo non tutti usano
il concetto di guidare l'utente ad una selezione mirata in modo da ottenere
strutture con qualche decina di Records.
I problemi di memoria li hai se fai elaborare ad Access in  locale troppa
roba, è il difetto principale di JET anche se ottimizzi le QRY su campi
indicizzati.
Purtroppo solo quando passi ad un vero sistema Client-Server ti accorgi
la limitazione di JET.
Ciao.
@Alex.


Circa 3/4 mesi fa quando ancora il Nostro MVP(Borrelli) frequentava
il NG ha dimostrato dati alla mano, alla faccia dei miscredenti, che
l'estrazione di Query parametriche su campi indicizzati riduceva
drasticamente il traffico di dati in rete, ne consegue che ciň rende
piů agevole anche con JET una gestione MultiClient.
Cerca il 3D, ma non ricordo il Subject, prova a cercare Maurizio Borrelli.
Ciao.
@Alex.

> Verissimo, ma ci stiamo allontanado dal problema originale.
Il problema originale era quello di spostare l'applicazione sul server
ed utilizzarla in monoutenza, cosa che io ho fatto e faccio
regolarmente.
Non si puň , non si deve o sarebbe solo meglio non farlo ?
Grazie ancora
Giň


 Spero di risentirti.
Ti sbagli Giovanna, i problemi che denunci s'incontrano solo su reti che
funzionano male o con decine di postazioni concorrenti.
Da un paio d'anni noi stiamo utilizzando .ADP per evitare corruzioni e
gestire moli di dati enormi ... ma la configurazione che denunci non ha mai
creato problemi in contesti di multiutenza ordinaria.
Anche il discorso dell'esauriemento di risorse mi sorprende e comunque non
centra affatto con un discorso FE/BE.
Al contrario, distribuire applicazioni con access con maschere e tabelle in
un unico .mdb è follia pura...
Bye

 Giò
Se l'applicazione è in  MONOUTENZA secondo me
è una cazzata metterla sul Server.
Sul Server ci vanno le applicazioni Server, di conseguenza
ti devi creare un pacchetto Client che si collega al Server.
Se usi Access Tabelle sul Server e sul Client Collega Tabelle
al Server.....!
Ciao.
@Alex.