Newsgroup: it.comp.appl.access
Titolo: Tabelle collegate in rete intranet

Finora ho avuto a che fare con FE collegati a BE su piccole reti locali, e 
tutto è sempre filato licio (...o quasi...).
Mi è stato chiesto di collocare su un server della rete intranet il BE di 
una mia applicazione che gestisce dati di archivio.
Ho fatto delle prove collegando tramite Menu\File\collega tabelle il FE al 
BE. Per funzionare, funziona, ma con tempi biblici! Solo per aprire una 
maschera 80 secondi!!! Per passare da un controllo all'altro circa 4-5 
secondi! Una guduria unica!
Io non sono pratico di collegamenti fra PC su reti intranet.
Vorrei sapere se fosse possibile avere un collegamento decente (anche 
manuale, non necessitano procedure automatiche) con questo sistema, dove 
posso eventualmente documentarmi.
Purtroppo sono limitato anche dal fatto che non conosco la lingua inglese.
I PC sono dotati di win 2000/XP e di Office 2000.
Grazie.
Napi 

 inglese. I PC sono dotati di win 2000/XP e di Office 2000.
Difficile a dire senza conoscere la tua applicazione e la tua rete.
Prova come'� il comportamento se nella finestra db apri una
tabella abbastanza grande e vai al ultimo record.
Il FE si trova in locale?
-- 
Ciao
Karl
*********
Access FAQ: 
www.donkarl.com/it
 

 inglese. I PC sono dotati di win 2000/XP e di Office 2000.
Difficile a dire senza conoscere la tua applicazione e la tua rete.
Prova come'è il comportamento se nella finestra db apri una
tabella abbastanza grande e vai al ultimo record.
Il FE si trova in locale?
-- 
Ciao
Karl
*********
Access FAQ: 
www.donkarl.com/it
---------------
Sì il FE è in locale e il server con il BE si trova a circa 40 km. La rete 
comprende varie sedi sparse per tutta la provincia e sono collegate tramite 
IP fissi. Il mio BE contiene normali tabelle con qualche migliaio di record, 
niente di eclatante. È proprio l'apertura delle maschere che impiega un 
sacco di tempo.
Dopo aver premuto Invio dopo la modifica di un controllo, prima che il 
cursore si sposti sul controllo successivo passano 3-4 secondi e questo 
avviene solo con il BE sul server. Se il FE e il BE si trovano su PC diversi 
della stessa rete dell'ufficio, tutto funziona bene.
L'amministratore di sistema dice che è colpa del server (infatti sarà 
cambiato fra circa un mese), ma io non ne sono troppo convinto  che sia 
l'unica causa.
Comunque grazie Karl sempre per la tua disponibilità.
Napi 

 l'unica causa.
Ti ho consigliato di fare delle prove con aprire tabelle direttamente
perchï¿½ le maschere possono "ingannare" molto in piï¿½ delle tabelle.
Se le tabelle hanno chiavi e indici buoni e aprono e mostrano
gli ultimi record in un tempo ragionevole, ci sono prospettive
che puoi ottimizzare la prestazione delle maschere.
Se no, no.
-- 
Ciao
Karl
*********
Access FAQ:  
http://www.donkarl.com/it
 

 l'unica causa.
Ti ho consigliato di fare delle prove con aprire tabelle direttamente
perché le maschere possono "ingannare" molto in più delle tabelle.
Se le tabelle hanno chiavi e indici buoni e aprono e mostrano
gli ultimi record in un tempo ragionevole, ci sono prospettive
che puoi ottimizzare la prestazione delle maschere.
Se no, no.
-- 
Ciao
Karl
*********
Grazie Karl, ho capito.
Questa prova però posso farla solo oggi pomeriggio, poi riprenderò questo 
thread, e se vorrai cortesemente darci un'occhiata...
Ciao
Napi 

 l'unica causa.
Ti ho consigliato di fare delle prove con aprire tabelle direttamente
perché le maschere possono "ingannare" molto in più delle tabelle.
Se le tabelle hanno chiavi e indici buoni e aprono e mostrano
gli ultimi record in un tempo ragionevole, ci sono prospettive
che puoi ottimizzare la prestazione delle maschere.
Se no, no.
-- 
Ciao
Karl
*********
Se apro le tabelle direttamente dal FE, la più grossa (circa 5000 record) si 
apre praticamente subito e visualizza il numero dei record in circa 2 sec. 
Passo dal primo all'ultimo record immediatamente.
Ho provato ad eseguire delle query con criteri un po' elaborati e il tempo 
di esecuzione è ragionevole.
Il problema sorge quando apro la maschera principale associata basata sulla 
tabella principale. Questa impiega (abbiamo provato a usare come server un 
pc più snello di quello precedente) circa 30-35 secondi e un'attesa di 3-5 
secondi fra l'Invio su un controllo e il focus su quello successivo.
Devo dire che questa maschera è abbastanza pesante come numero di controlli 
(è composta da 4 schede) ma non fa elaborazioni molto complicate. Anzi i 
controlli calcolati visualizzano subito il valore.
Le altre maschere sono più leggere e si aprono in un tempo più o meno 
dimezzato, ma comunque inaccettabile per lavorare bene.
Ovviamente tutti questi problemi non esistono lavorando anche in multiutenza 
(3-4 PC) in rete locale.
Ti ringrazio per l'attenzione.
Napi 

 multiutenza (3-4 PC) in rete locale.
Karl, risolveresti un problema anche a me con qualche bel suggerimento
Stesso problema
Antonio 

 Stesso problema
È difficile da lontano. Di solito aiuta molto un recordset
persistente al Backend. Spesso bisogna adattare gli indici
nelle tabelle, ottimizzare le query che fanno l'origine dati
delle maschere, report, caselle combinate... ottimizzare
il momento quando vengono caricati i dati nelle maschere
(un quasi Late Binding), qualche volta anche suddividere
le maschere, togliere la sistema di sicurezza di Access ecc.
Spesso è meglio comprare un nuovo server e rete. ;-)
Ci sono siti che hanno tanti buoni consigli come
http://www.granite.ab.ca/access/performancefaq.htm
(purtroppo in inglese per Napi).
Sono direttive di lavoro soprattutto per il rete, ma molto
dipende dalle circostanze e bisogna sempre fare delle
prove, prove, prove nel rete e carico concreto.


 - Mostra testo citato -
Hai provato ad utilizzare SQLExpress? Avresti le Viste che
specialmente per le combo o le list box velocizzano tantissimo.
Con Access, e specialmodo in remoto, potresti avere problemi di
corruzione alle tabelle. Con SQLExpress è praticamente
impossibile, salvo guasti al server.
--
sv

?"Napi"  ha scritto nel messaggio 
news:4d3877a7$0$2053$4faf...@reader1.news.tin.it...



-- 
Ciao
Karl
*********


___
Hai tolto la correzione automatica dei nomi??
MA

"MA"  ha scritto nel messaggio news:ihc69b$pfh$1...@tdi.cu.mi.it...




-- 
Ciao
Karl
*********


----
Yes!
Però mi viene un dubbio. Non sarà mica perché sono juventino?
Qualcuno, qualche tempo fa, con logica granitica, scrisse da qualche parte 
che chi non tifa Napoli non conosce un c***o di access! Che sia vero!?! :-(
Napi

"Karl Donaubauer"  ha scritto nel messaggio 
news:8pt5r1...@mid.individual.net...



-- 
Ciao
Karl
*********
Grazie Karl.
Purtroppo temevo mi dessi una risposta in questo tono. Ogni consiglio, però, 
è buono.
Adesso devo fare il punto con l'amministratore di sistema e vedrò cosa ne 
salterà fuori.
Ciao
Napi 

"sv"  ha scritto nel messaggio 
news:e150f1d4-1d9a-4768...@u9g2000pra.googlegroups.com...


--
sv
---
Stabilito che SQLExpress non è mia materia (conosco, anche se non 
profondamente, solo MySql), non mi ci addentrerei comunque per l'impegno che 
comporterebbe in funzione del risultato ricercato. Ci sono una serie di 
problemi, non ultimo quello economico, da valutare.
La buona notizia è, come già detto in altra parte a Karl, che è in arrivo 
dalla sede nazionale un nuovo server più potente.
Ti ringrazio comunque per il tuo suggerimento.
Napi 

 Napi
--
sv
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Napi
--
sv
-- 
Azz...!!! Non mi sono spiegato.
Non mi riferivo al costo di SQLExpress. Lo so che è gratuito. L'avevo anche 
provato e condivido quello che dici.
Mi riferivo al tempo che si dovrebbe dedicare a rifare un programma già 
fatto in access, cioè quello attualmente esistente, fatto da me, per le 
esigenze mie e dell'ufficio in cui sono chiamato a dare una prestazione a 
intervalli periodici, nato quasi per caso qualche anno fa, usato in rete 
locale da 2/5 persone, modificato e perfezionato nel tempo secondo 
necessità.
Visto che funziona, e bene, perché fatto su misura per me/noi, mi è stato 
chiesto di renderlo disponibile per altre sedi in ambito provinciale 
localizzando un unico server. Da qui nasce il problema e lo scopo del mio 
intervento.
Sarebbe un lavoro piuttosto lungo trasferirlo in un ambiente in cui non sono 
per niente a mio agio: questo è l'aspetto economico a cui mi riferivo.
Ciao
Napi

 l'unica causa.
Ti ho consigliato di fare delle prove con aprire tabelle direttamente
perchï¿½ le maschere possono "ingannare" molto in piï¿½ delle tabelle.
Se le tabelle hanno chiavi e indici buoni e aprono e mostrano
gli ultimi record in un tempo ragionevole, ci sono prospettive
che puoi ottimizzare la prestazione delle maschere.
Se no, no.
-- 
Ciao
Karl
*********
Se apro le tabelle direttamente dal FE, la piï¿½ grossa (circa 5000 record) si
apre praticamente subito e visualizza il numero dei record in circa 2 sec.
Passo dal primo all'ultimo record immediatamente.
Ho provato ad eseguire delle query con criteri un po' elaborati e il tempo
di esecuzione ï¿½ ragionevole.
Il problema sorge quando apro la maschera principale associata basata sulla
tabella principale. Questa impiega (abbiamo provato a usare come server un
pc piï¿½ snello di quello precedente) circa 30-35 secondi e un'attesa di 3-5
secondi fra l'Invio su un controllo e il focus su quello successivo.
Devo dire che questa maschera ï¿½ abbastanza pesante come numero di controlli
(ï¿½ composta da 4 schede) ma non fa elaborazioni molto complicate. Anzi i
controlli calcolati visualizzano subito il valore.
Le altre maschere sono piï¿½ leggere e si aprono in un tempo piï¿½ o meno
dimezzato, ma comunque inaccettabile per lavorare bene.
Ovviamente tutti questi problemi non esistono lavorando anche in multiutenza
(3-4 PC) in rete locale.
Ti ringrazio per l'attenzione.
Napi
___
Hai tolto la correzione automatica dei nomi??
MA
----
Yes!
Perï¿½ mi viene un dubbio. Non sarï¿½ mica perchï¿½ sono juventino?
Qualcuno, qualche tempo fa, con logica granitica, scrisse da qualche parte
che chi non tifa Napoli non conosce un c***o di access! Che sia vero!?! :-(
Napi
__
Ma allora dillo prima...
MA

 Napi
--
sv
-- 
Azz...!!! Non mi sono spiegato.
Non mi riferivo al costo di SQLExpress. Lo so che � gratuito. L'avevo anche
provato e condivido quello che dici.
Mi riferivo al tempo che si dovrebbe dedicare a rifare un programma gi�
fatto in access, cio� quello attualmente esistente, fatto da me, per le
esigenze mie e dell'ufficio in cui sono chiamato a dare una prestazione a
intervalli periodici, nato quasi per caso qualche anno fa, usato in rete
locale da 2/5 persone, modificato e perfezionato nel tempo secondo
necessit�.
Visto che funziona, e bene, perch� fatto su misura per me/noi, mi � stato
chiesto di renderlo disponibile per altre sedi in ambito provinciale
localizzando un unico server. Da qui nasce il problema e lo scopo del mio
intervento.
Sarebbe un lavoro piuttosto lungo trasferirlo in un ambiente in cui non sono
per niente a mio agio: questo � l'aspetto economico a cui mi riferivo.
Ciao
Napi
___
Guarda l'upsize a SQL (se collegato in ODBC) ha un impatto veramente minimo 
come
riscrittura del software, enorme come prestazioni
MA

 Napi
--
sv
-- 


-------
Eh...s�! Mi sto mentalmente convincendo che forse ne vale la pena. Vedr� 
cosa c'� in prospettiva per il futuro.
E che io, con access, sai, mi trovo comodo come quando porti un buon paio di 
scarpe vecchie.
Ciao
Napi 

 Napi
--
sv
-- 
Azz...!!! Non mi sono spiegato.
Non mi riferivo al costo di SQLExpress. Lo so che è gratuito. L'avevo anche
provato e condivido quello che dici.
Mi riferivo al tempo che si dovrebbe dedicare a rifare un programma già
fatto in access, cioè quello attualmente esistente, fatto da me, per le
esigenze mie e dell'ufficio in cui sono chiamato a dare una prestazione a
intervalli periodici, nato quasi per caso qualche anno fa, usato in rete
locale da 2/5 persone, modificato e perfezionato nel tempo secondo
necessità.
Visto che funziona, e bene, perché fatto su misura per me/noi, mi è stato
chiesto di renderlo disponibile per altre sedi in ambito provinciale
localizzando un unico server. Da qui nasce il problema e lo scopo del mio
intervento.
Sarebbe un lavoro piuttosto lungo trasferirlo in un ambiente in cui non sono
per niente a mio agio: questo è l'aspetto economico a cui mi riferivo.
Ciao
Napi
___
Guarda l'upsize a SQL (se collegato in ODBC) ha un impatto veramente minimo
come
riscrittura del software, enorme come prestazioni
MA
-------
Eh...sì! Mi sto mentalmente convincendo che forse ne vale la pena. Vedrò
cosa c'è in prospettiva per il futuro.
E che io, con access, sai, mi trovo comodo come quando porti un buon paio di
scarpe vecchie.
Ciao
Napi
Certo, ma dipende dove devi andare
MA