timeout connessione al server (ODBC)

[Ammammata]

usando una vpn il cliente accede ai dati sul server remoto tramite ODBC

l'applicazione parte subito con questo codice:

' 20.07.2021 refresh ODBC
On Error Resume Next

Dim db As DAO.Database
Dim tb As DAO.TableDef
Set db = CurrentDb
For Each tb In db.TableDefs
If Left(tb.Connect, 4) = "ODBC" Then
Debug.Print "Connessione " & tb.Connect
tb.Connect = newConnectionString
tb.RefreshLink
Debug.Print "Refreshed ODBC table " & tb.Name
Messaggio ("- " & Time() & " Refresh ODBC : " & tb.Name)
End If
Next tb
Set db = Nothing


lo avevo aggiunto in base ai vostri suggerimenti in un periodo in cui
non si capiva da cosa potessero dipendere strani errori (ovviamente
senza alcuna spiegazione) da parte di access

questo "trucco" ha funzionato e sta funzionando



ogni tanto però, suppongo per il traffico di rete per chi si collega da
fuori ufficio, l'applicazione access si ferma dopo una decina di
secondi con l'errore di connessione ODBC: è sufficiente chiudere e
riprovare che tutto torna a funzionare egregiamente

c'è modo di aumentare questa sorta di timeout?
oppure di dare un comando *prima*, che stabilista la connessione in
qualche modo, per evitare il timeout?

--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

[Giorgio Rancati]

Ciao,
io avevo un problema simile che dipendeva dalla caduta temporanea della connessione ma nel mio caso Access si connetteva a Microsoft Sql server con driver "ODBC 18 driver for Sql server"

tu a quale server ti connetti ?
se a Sql server, con quale driver ?

Ciao
Giorgio Rancati

[@Alex]

> Ciao
> Giorgio Rancati

Ciao Giorgio approfitto con piacere per un saluto.

@Alex

[Ammammata]

Il giorno Sun 16 Apr 2023 01:56:52p, *Giorgio Rancati* ha inviato su
it.comp.appl.access il messaggio news:c314ff59-3f6b-438a-943e-
2fd848...@googlegroups.com. Vediamo cosa ha scritto:

> se a Sql server, con quale driver ?
>

18, più precisamente 2018.181.01.01

[Giorgio Rancati]

ok, puoi aggiungere alla stringa di connessione il parametro ;ConnectRetryCount=2 a me ha risolto il problema della caduta temporanea della connessione
qui ulteriori dettagli
Connection resiliency in the ODBC driver
https://learn.microsoft.com/en-us/sql/connect/odbc/connection-resiliency?view=sql-server-ver16

Ciao
Giorgio Rancati

[Giorgio Rancati]

Ciao Alex :-)

[Simone Calligaris]

> Ciao,
> io avevo un problema simile che dipendeva dalla caduta temporanea della connessione ma nel mio caso Access si connetteva a Microsoft Sql server con driver "ODBC 18 driver for Sql server"
>
> tu a quale server ti connetti ?
> se a Sql server, con quale driver ?

Giorgio Rancati redivivo!

"Che hai fatto in tutti questi anni?"

1) "sono andato a letto presto"

Oppure:

2) "Ho riscritto tutto da ADP ad AccDB/ODBC!"

Saluti da Simone ;-)

[Giorgio Rancati]

Ciao Simone,

la 2 ma è bastato un annetto :-)
nel frattempo è riaffiorata una vecchia passione che ha portato via tempo alla presenza sui forum, però ogni tanto vengo con piacere a leggervi.
:-)
Giorgio Rancati

[RobertoA]

Fatemi sapere se ho capito bene
Avete delle postazioni di lavoro nella sede A
Il db server e' nella sede B, geograficamente distante da A
Le postazioni lavoro usano tabelle collegate via odbc al db server
E tra sede A e sede B c'e' internet di mezzo
Ho capito bene?

La domanda successiva sarebbe, e funziona tutto correttamente?, ma mi
sembra inutile farla visto che se non funzionasse avreste sicuramente
modificato il sistema
E quindi e' la connessione internet che si rivela piu' robusta del
previsto oppure e' il driver odbc che e' stato progettato per lavorare
anche su collegamenti non convenzionali come la classica lan?

Oppure c'e' qualche altro magheggio di mezzo tra postazioni lavoro e db
server remoto?
Scusate la domanda forse ingenua, ma pur avendolo provato per curiosita'
non mi sono mai azzardato ad utilizzare 'dal vero' un db remoto
solamente via suo driver odbc

[Ammammata]

RobertoA brought next idea :

> Avete delle postazioni di lavoro nella sede A
> Il db server e' nella sede B, geograficamente distante da A
> Le postazioni lavoro usano tabelle collegate via odbc al db server
> E tra sede A e sede B c'e' internet di mezzo
> Ho capito bene?

esatto: gli utenti attivano la VPN ed eseguono il software in locale
che va a pescare i dati dal server remoto
è una operazione una tantum, di solito giornaliera ma spesso passano
più giorni, che impiega un paio di minuti: il resto delle operazioni
(produzione di stampe statistiche) è fatto senza più la necessità di
collegarsi, in queso modo i venditori e i responsabili possono
controllare al volo la situazione/andamento di clienti e fornitori

[Giorgio Rancati]

Ciao Roberto,

nessun magheggio, nel mio caso gli utenti lavorano da remoto come se fossero in sede, nel loro computer c'è solo l'applicazione fatta con Access che si collega al Db server (nel mio caso Sql server)
La parte più lenta è in fase di apertura del programma quando collega le tabelle (circa 40 secondi per 120 tabelle) poi la velocità è di poco più lenta che in sede ma sempre più che accettabile.

Ciao
Giorgio Rancati

[RobertoA]

Il 17/04/2023 10:03, Ammammata ha scritto:
> RobertoA brought next idea :
>> Avete delle postazioni di lavoro nella sede A
>> Il db server e' nella sede B, geograficamente distante da A
>> Le postazioni lavoro usano tabelle collegate via odbc al db server
>> E tra sede A e sede B c'e' internet di mezzo
>> Ho capito bene?
>
> esatto: gli utenti attivano la VPN ed eseguono il software in locale che
> va a pescare i dati dal server remoto
> è una operazione una tantum, di solito giornaliera ma spesso passano più
> giorni, che impiega un paio di minuti: il resto delle operazioni
> (produzione di stampe statistiche) è fatto senza più la necessità di
> collegarsi, in queso modo i venditori e i responsabili possono
> controllare al volo la situazione/andamento di clienti e fornitori
>

Va beh, se e' qualche minuto di collegamento e' gia' piu' comprensibile,
invece collegamenti permanenti tipo classico gestionale mi sembrerebbero
gia' piu' delicati da mantenere
Ma Giorgio Rancati dice che e' piu' che accettabile

Personalmente ho fatto qualche esperimento ed ho visto che tutto
funzionava a dovere ma non mi sono mai sentito di proporre un
collegamento di questo tipo a qualcuno che lavora col gestionale in modo
costante durante tutto il giorno, magari sono solo miei timori infondati
Ho sempre preferito dirottare su collegamenti via rdp e quindi in
sostanza gestionale e db sempre sulla stessa lan

[RobertoA]

Si, ovviamente, do' per scontato che ricollegamenti tabelle siano piu'
lenti e le query debbano essere ottimizzate per lavorare lato db server
Ma anche cosi' lanciare qualche interrogazione che impieghi piu' di
qualche secondo per alimentare la form che hai sotto gli occhi, mi fa'
un po' venire i brividi, una roba del tipo 'io speriamo che me la cavo'

Da come scrivi sembra che ricolleghi le tabelle ad ogni apertura
programma, ma non basta farlo una volta sola?

[Xÿmox]

Il 17/04/23 11:06, RobertoA ha scritto:

> Da come scrivi sembra che ricolleghi le tabelle ad ogni apertura
> programma, ma non basta farlo una volta sola?

stessa domanda che mi stavo ponendo, ci sarà altro, aspettiamo la risposta.

[Giorgio Rancati]

Sì basterebbe una volta sola, nel mio caso il cliente può avere più di una azienda da gestire, ogni azienda è memorizzata in un db diverso e può avere tabelle o viste diverse come struttura, la scelta di avere una azienda per db è determinata dal fatto che il cliente può mandare una copia al commercialista per controllo bilanci ecc. ho un commercialista che segue diversi miei clienti e un db solo con tutte le aziende memorizzate avrebbe complicato molto questo aspetto quindi la via più semplice e a mio parere sicura era ricollegare le tabelle.

Giorgio Rancati

[ciroteo]

Ciao Giorgio! Che piacere leggerti!
Allora è tempo di fare una nuova CISA!

un caloroso abbraccio!
Matteo

[Giorgio Rancati]

Ciao Matteo,
vedo che sei sempre brillante :-)
abbraccio ricambiato
Giorgio Rancati