access lento in rete
gianfranco
ho fatto un'applicazione alquanto corposa tra maschere query e report
i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
che si collegano alle tabelle purtroppo ora tutti i pc si sono
rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
o mysql la gestione era piￜ veloce e che tipo di collegamento occorre
effettuare per far vedere all'applicazione le tabelle.
Grazie
Fair87
>Salve a tutti ho un problema di velocit� di access in rete
>ho fatto un'applicazione alquanto corposa tra maschere query e report
>i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>che si collegano alle tabelle purtroppo ora tutti i pc si sono
>rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>Grazie
Con SQL server sicuramente � tutto + veloce (e sicuro) con alcuni SE (server
dedicato, buone schede di rete, buona struttura dell'accesso ai dati...). Ma
in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la lentezza?
Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
concorrenze? Dicci qualcosa di +!!!!!
--
Questo articolo e` stato inviato dal sito web http://www.nonsolonews.it
Massimiliano Bertoglio
"gianfranco"
> Salve a tutti ho un problema di velocit� di access in rete
> ho fatto un'applicazione alquanto corposa tra maschere query e report
> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
> che si collegano alle tabelle purtroppo ora tutti i pc si sono rallentati.
>Volevo sapere se istallando sul pc delle tabelle sql server o mysql la
>gestione era pi� veloce
Dipende da come hai sviluppato l'mdb.
Di solito i problemi cui fai riferimento si risolvono con pochi
accorgimenti, qui trovi indicazioni utili:
http://www.granite.ab.ca/access/performancefaq.htm
E in particolare:
LDB locking which a persistent recordset connection fixes
Saluti di fine anno.
gianfranco
> gianfranco ha scritto:
>> Salve a tutti ho un problema di velocitￜ di access in rete
>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>> Grazie
>
> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...). Ma
> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la lentezza?
> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
> concorrenze? Dicci qualcosa di +!!!!!
>
record in fase di ricerca, faccio presente che quando richiamo un record
si attvano diverse query che caricano alcune sottoschede. In sql server
aumenta la velocitￜ di trasmissione dei dati, ma occorre trasferire
oltre alle tabelle anche le query? Ho letto che occorre passarle a mano
e quelle che fanno riferimento a delle form specifiche? occorre
riscrivere tutto? oppure bastano le tabelle?
mi spiegate che cosa fa la LDB locking which a persistent recordset
connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
il collegamento alle tabelle ￜ sbagliato? conviene mantenere il
collegamento diretto?
grazie
Fair87
>Fair87 ha scritto:
>> gianfranco ha scritto:
>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>> Grazie
>>
(server
>> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...).
Ma
>> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la
lentezza?
>> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
>> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
>> concorrenze? Dicci qualcosa di +!!!!!
>>
>La lentezza la vedo sia nell'apertura delle form che quando richiamo un
>record in fase di ricerca, faccio presente che quando richiamo un record
>si attvano diverse query che caricano alcune sottoschede. In sql server
>e quelle che fanno riferimento a delle form specifiche? occorre
>riscrivere tutto? oppure bastano le tabelle?
>mi spiegate che cosa fa la LDB locking which a persistent recordset
>connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
>collegamento diretto?
>grazie
qui c'� gente molto pi� scafata di me, ma nel mio piccolo ti dico come ho
risolto io.
Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
Massimigliano Bertoglio)
Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
concorrenza sullo stesso set di record
Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
inserimenti (di solito non associate)
Se la form � estremamente pesante, popolo combo e similari sulla loro
attivazione
Gestisco la multiutenza impostando il blocco a livello di record (modificati
)se form associate o gestendo gli errori per le concorrenze (soprattutto il
3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
Indicizzo ogni campo su cui posso fare le ricerche (access se pu�, pur essendo
un file-sharing e non un client-server, importa sul client solo la tabella
degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
la possibilit� di annullare tutto (chiaro che a volte non si pu�...)
Uso una marea di Public Function per le operazioni comuni e ripetute, la
leggibilit�, ottimizzazione e velocit� di esecuzione del codice
Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
indici e opta per il table scan, operazioni di scelta tra tabelle-query in
join multipli e cose cos�) hanno un costo prestazionale, tutto st� a renderle
il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
che quella particolare operazione impiega parecchio tempo (se no comincia a
pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
niente!!!!!@#]#@#...!!!'
Se ti pu� essere d'aiuto.....
us...@domain.invalid
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>>> Grazie
> (server
>>> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...).
> Ma
>>> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la
> lentezza?
>>> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
>>> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
>>> concorrenze? Dicci qualcosa di +!!!!!
>>>
>> La lentezza la vedo sia nell'apertura delle form che quando richiamo un
>> record in fase di ricerca, faccio presente che quando richiamo un record
>> si attvano diverse query che caricano alcune sottoschede. In sql server
>> e quelle che fanno riferimento a delle form specifiche? occorre
>> riscrivere tutto? oppure bastano le tabelle?
>> mi spiegate che cosa fa la LDB locking which a persistent recordset
>> connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
>> collegamento diretto?
>> grazie
>
> qui c'ￜ gente molto piￜ scafata di me, ma nel mio piccolo ti dico come ho
> risolto io.
> Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
> Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
> Massimigliano Bertoglio)
> Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
> grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
> concorrenza sullo stesso set di record
> Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
> inserimenti (di solito non associate)
> attivazione
> Gestisco la multiutenza impostando il blocco a livello di record (modificati
> )se form associate o gestendo gli errori per le concorrenze (soprattutto il
> 3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
> un file-sharing e non un client-server, importa sul client solo la tabella
> degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
> Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
>
> Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
> indici e opta per il table scan, operazioni di scelta tra tabelle-query in
> il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
> questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
> che quella particolare operazione impiega parecchio tempo (se no comincia a
> pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
> niente!!!!!@#]#@#...!!!'
>
>
mi sembrano delle ottime idee, anche io riallego ad ogni avvio mi
potresti dire la procedura per la forzatura dell'ldb e la gestione dei
dati con l'mdb di appoggio come viene aggiornato quest'ultimo copi il
file collegato nel pc locale? aggiorni i duel file contemporaneamente?
ti ringrazio cmq dell'aiuto
us...@domain.invalid
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>>> Grazie
> (server
>>> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...).
> Ma
>>> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la
> lentezza?
>>> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
>>> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
>>> concorrenze? Dicci qualcosa di +!!!!!
>>>
>> La lentezza la vedo sia nell'apertura delle form che quando richiamo un
>> record in fase di ricerca, faccio presente che quando richiamo un record
>> si attvano diverse query che caricano alcune sottoschede. In sql server
>> e quelle che fanno riferimento a delle form specifiche? occorre
>> riscrivere tutto? oppure bastano le tabelle?
>> mi spiegate che cosa fa la LDB locking which a persistent recordset
>> connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
>> collegamento diretto?
>> grazie
>
> qui c'ￜ gente molto piￜ scafata di me, ma nel mio piccolo ti dico come ho
> risolto io.
> Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
> Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
> Massimigliano Bertoglio)
> Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
> grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
> concorrenza sullo stesso set di record
> Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
> inserimenti (di solito non associate)
> attivazione
> Gestisco la multiutenza impostando il blocco a livello di record (modificati
> )se form associate o gestendo gli errori per le concorrenze (soprattutto il
> 3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
> un file-sharing e non un client-server, importa sul client solo la tabella
> degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
> Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
>
> Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
> indici e opta per il table scan, operazioni di scelta tra tabelle-query in
> il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
> questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
> che quella particolare operazione impiega parecchio tempo (se no comincia a
> pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
> niente!!!!!@#]#@#...!!!'
>
us...@domain.invalid
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>>> Grazie
>
> qui c'ￜ gente molto piￜ scafata di me, ma nel mio piccolo ti dico come ho
> risolto io.
> Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
> Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
> Massimigliano Bertoglio)
> Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
> grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
> concorrenza sullo stesso set di record
> Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
> inserimenti (di solito non associate)
> Se la form ￜ estremamente pesante, popolo combo e similari sulla loro
> attivazione
> Gestisco la multiutenza impostando il blocco a livello di record (modificati
> )se form associate o gestendo gli errori per le concorrenze (soprattutto il
> 3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
> Indicizzo ogni campo su cui posso fare le ricerche (access se puￜ, pur essendo
> un file-sharing e non un client-server, importa sul client solo la tabella
> degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
> Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
> la possibilitￜ di annullare tutto (chiaro che a volte non si puￜ...)
> Uso una marea di Public Function per le operazioni comuni e ripetute, la
> leggibilitￜ, ottimizzazione e velocitￜ di esecuzione del codice
>
> Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
> indici e opta per il table scan, operazioni di scelta tra tabelle-query in
> join multipli e cose cosￜ) hanno un costo prestazionale, tutto stￜ a renderle
> il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
> questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
> che quella particolare operazione impiega parecchio tempo (se no comincia a
> pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
> niente!!!!!@#]#@#...!!!'
>
us...@domain.invalid
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>>> Grazie
> (server
>>> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...).
> Ma
>>> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la
> lentezza?
>>> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
>>> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
>>> concorrenze? Dicci qualcosa di +!!!!!
>>>
>> La lentezza la vedo sia nell'apertura delle form che quando richiamo un
>> record in fase di ricerca, faccio presente che quando richiamo un record
>> si attvano diverse query che caricano alcune sottoschede. In sql server
>> e quelle che fanno riferimento a delle form specifiche? occorre
>> riscrivere tutto? oppure bastano le tabelle?
>> mi spiegate che cosa fa la LDB locking which a persistent recordset
>> connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
>> collegamento diretto?
>> grazie
>
> qui c'ￜ gente molto piￜ scafata di me, ma nel mio piccolo ti dico come ho
> risolto io.
> Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
> Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
> Massimigliano Bertoglio)
> Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
> grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
> concorrenza sullo stesso set di record
> Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
> inserimenti (di solito non associate)
> attivazione
> Gestisco la multiutenza impostando il blocco a livello di record (modificati
> )se form associate o gestendo gli errori per le concorrenze (soprattutto il
> 3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
> un file-sharing e non un client-server, importa sul client solo la tabella
> degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
> Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
>
> Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
> indici e opta per il table scan, operazioni di scelta tra tabelle-query in
> il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
> questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
> che quella particolare operazione impiega parecchio tempo (se no comincia a
> pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
> niente!!!!!@#]#@#...!!!'
>
us...@domain.invalid
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>
gianfranco
> gianfranco ha scritto:
>> Fair87 ha scritto:
>>> gianfranco ha scritto:
>>>> ho fatto un'applicazione alquanto corposa tra maschere query e report
>>>> i dati sono su un altro mdb e su un pc ci sono 4 pc con l'applicazione
>>>> che si collegano alle tabelle purtroppo ora tutti i pc si sono
>>>> rallentati. Volevo sapere se istallando sul pc delle tabelle sql server
>>>> Grazie
> (server
>>> dedicato, buone schede di rete, buona struttura dell'accesso ai dati...).
> Ma
>>> in teoria Access lavora molto bene con 2/3 utenti....In cosa noti la
> lentezza?
>>> Apertura maschere? Accesso ai record? Rialleghi le tabelle ad ogni avvio?
>>> Utilizzi qualcosa per forzare l'apertura dell'mdb BE da parte dell'FE? Le
>>> concorrenze? Dicci qualcosa di +!!!!!
>>>
>> La lentezza la vedo sia nell'apertura delle form che quando richiamo un
>> record in fase di ricerca, faccio presente che quando richiamo un record
>> si attvano diverse query che caricano alcune sottoschede. In sql server
>> e quelle che fanno riferimento a delle form specifiche? occorre
>> riscrivere tutto? oppure bastano le tabelle?
>> mi spiegate che cosa fa la LDB locking which a persistent recordset
>> connection fixes. Io ogni volta che faccio partire l'appicazione eseguo
>> collegamento diretto?
>> grazie
>
> qui c'ￜ gente molto piￜ scafata di me, ma nel mio piccolo ti dico come ho
> risolto io.
> Riallego ad ogni avvio tutte le tabelle (2 mdb come BE)
> Forzo, tramite tabelle dummy, la persistenza dell'ldb (come ti consiglia
> Massimigliano Bertoglio)
> Utilizzo un mdb di appoggio (locale) per la visualizzazione dei recordset di
> grandi dimensioni (in sola lettura). Mi evita ogni tipo di problemi di
> concorrenza sullo stesso set di record
> Tutte le form sono in sola lettura. Utilizzo altre form per modifiche e
> inserimenti (di solito non associate)
> attivazione
> Gestisco la multiutenza impostando il blocco a livello di record (modificati
> )se form associate o gestendo gli errori per le concorrenze (soprattutto il
> 3218 e 3022) per form non associate (uso QUASI esclusivamente queste ultime)
> un file-sharing e non un client-server, importa sul client solo la tabella
> degli indici). Rallenta in fase di scrittura, ma dipende dall'utilizzo.....
> Cerco di fare le procedure sempre step-by-step per non attendere troppo e dare
>
> Chiaro che alcune operazioni (ricerche con * davanti che manda a ramengo gli
> indici e opta per il table scan, operazioni di scelta tra tabelle-query in
> il + performanti possibili (magari in 2/3 step tipo 'ora ti faccio vedere
> questo, se hai bisogno allora anche quest'altro'...) ed avvisare cmq l'utente
> che quella particolare operazione impiega parecchio tempo (se no comincia a
> pestare come un matto sulla tastiera e dire 'Ecco...e adesso non funziona +
> niente!!!!!@#]#@#...!!!'
>
>
Fair87
>>
>mi sembrano delle ottime idee, anche io riallego ad ogni avvio mi
>potresti dire la procedura per la forzatura dell'ldb e la gestione dei
>dati con l'mdb di appoggio come viene aggiornato quest'ultimo copi il
>file collegato nel pc locale? aggiorni i duel file contemporaneamente?
>ti ringrazio cmq dell'aiuto
la mia struttura � cos� formata: 2 mdb diciamo 'server' e 1 mdb locale. Il
locale � composta solo da tabelle vuote e ce ne 1 per ogni client. Per
riallegare i vari BE ho una tabella (in quello locale) che annota i percorsi
relativi (tipo /CartellaApplicativo/NomeApplicativo) e un codice
(locale/server).Sul server ho 1 tabella x mdb vuota, alla quale mi collego per
primo e apro un recordset (in una maschera di avvio nascosta). Questo
recordset non viene mai chiuso se non alla chiusura dell'applicativo stesso
(la maschera nascosta � l'ultima a chiudersi e mi serve anche per non far
chiudere l'applicazione dalla crocetta rossa). Il db di appoggio mi serve
invece per scrivere fisicamente i record da visualizzare (SENZA relazioni,
tabelle piatte) o per fare operazioni locali (ordini, analisi di dati,
ricerche, tutte cose per cui non ha senso appesantire il server o rallentare
gli atri utenti). Magari anche tutta la reportistica....Il senso � questo:
devo fare una ricerca su una tabella molto grossa e un tot di join. Se faccio
una select, � ancora il server a gestire tutto. La fanno anche altri 2 utenti
e l'mdb-server va in crisi (una per tutto la navigazione tra i record....). Io
faccio una INSERT con tutti i join che mi servono nella tab locale (SOLA
LETTURA). Ora ho il mio set di record li sul mio pc, posso tenerli li anche
tutto il giorno, non causo problemi a nessuno. In + aggiungo sempre anche 1
boolean x selezionare i record (uso sempre maschere continue). La velocit� di
esecuzione della INSERT da me � molto + veloce di una SELECT multiutenza.
Ovvio che con SQL server non hai bisogno di tutti questi orpelli, ma con mdb
si......
Se hai altri dubbi chiedi pure!!!!!!
gianfranco
> [cut]
>> mi sembrano delle ottime idee, anche io riallego ad ogni avvio mi
>> potresti dire la procedura per la forzatura dell'ldb e la gestione dei
>> dati con l'mdb di appoggio come viene aggiornato quest'ultimo copi il
>> file collegato nel pc locale? aggiorni i duel file contemporaneamente?
>> ti ringrazio cmq dell'aiuto
>
> locale ￜ composta solo da tabelle vuote e ce ne 1 per ogni client. Per
> riallegare i vari BE ho una tabella (in quello locale) che annota i percorsi
> relativi (tipo /CartellaApplicativo/NomeApplicativo) e un codice
> (locale/server).Sul server ho 1 tabella x mdb vuota, alla quale mi collego per
> primo e apro un recordset (in una maschera di avvio nascosta). Questo
> recordset non viene mai chiuso se non alla chiusura dell'applicativo stesso
> chiudere l'applicazione dalla crocetta rossa). Il db di appoggio mi serve
> invece per scrivere fisicamente i record da visualizzare (SENZA relazioni,
> tabelle piatte) o per fare operazioni locali (ordini, analisi di dati,
> ricerche, tutte cose per cui non ha senso appesantire il server o rallentare
> devo fare una ricerca su una tabella molto grossa e un tot di join. Se faccio
> e l'mdb-server va in crisi (una per tutto la navigazione tra i record....). Io
> faccio una INSERT con tutti i join che mi servono nella tab locale (SOLA
> LETTURA). Ora ho il mio set di record li sul mio pc, posso tenerli li anche
> tutto il giorno, non causo problemi a nessuno. In + aggiungo sempre anche 1
> esecuzione della INSERT da me ￜ molto + veloce di una SELECT multiutenza.
> Ovvio che con SQL server non hai bisogno di tutti questi orpelli, ma con mdb
> si......
> Se hai altri dubbi chiedi pure!!!!!!
>
carico dal server quando devo richiamare un record ed ￜ qui che rallenta
molto le tabelle nel server sono molte, credo che dovrￜ studiarmi l'sql
server per velocizzare il flusso di dati. Ti ringrazio
Fair87
>> [cut]
>>
>anche io uso tabelle locali temporanee per l'inserimento dati e le
>carico dal server quando devo richiamare un record ed � qui che rallenta
>molto le tabelle nel server sono molte, credo che dovr� studiarmi l'sql
>server per velocizzare il flusso di dati. Ti ringrazio
Io parlo solo della visualizzazione...per l'inserimento uso solo form non
associate, cos� controllo l'input e poi faccio INSERT magari incapsulata in
una transazione. Se passi a SQL server e utilizzi ODBC all'inizio puoi 'quasi'
lasciare intatta la scrittura del FE (a parte alcune necessita, vedi il sito
di @Alex). Poi pian pianino lo converti totalmente (xch� a quel punto dovresti
centralizzare tutto sul motore db del server: migliori prestazioni, miglior
manutenzione, FE leggerissomo)