dichiara l'oggetto connessione e usa quello, inoltre usa il connection mode adModeReadWrite

fammi sapere,
ciao

Se usi recordset disconnessi, con o senza l'oggetto Connection, assicurati che Tutte le costanti ADO che eventualmente utilizzi (per esempio quelle citate nel precedente post) siano definite. Includendo il file allegato dovresti risolvere

@madai said:

... inoltre usa il connection mode adModeReadWrite

...dipende da cosa deve fare la singola query: solo leggere, solo scrivere, leggere e scrivere, ecc...
è bene documentarsi da subito sulle differenze nelle modalità di apertura di connessioni e recordset per avere il massimo delle performance (non percettibili per db piccoli, importanti per db di medie, fondamentali per db di grandi dimensioni - anche se in questo caso non userei MS Access -)

Bene, ho fatto alcune prove e sembra che quella da voi suggerita sia la soluzione giusta!!!
Ovviamente vi ringrazio alla grande!
Per quanto riguarda l'inclusione del file con le dichiarazioni delle costanti ado forse posso farne a meno perchè io uso sempre i numeri:

RS.Open mSQL, Conn, adOpenKeyset , adLockOptimistic, adCmdText

per me è:

RS.Open mSQL, Conn, 1, 3, 1

adUseClient = 3 ecc.

è la stessa cosa o è meglio comunque includere il file?

CIAO!!!

Bene,
usare i valori o i nomi delle costanti è la stessa cosa,
se usi i nomi però il codice è più leggibile e manutenibile.

Si ma per fare le insert e le update devo fare un conn.open prima o poi sennò non me la riconosce la connessione! Non so se mi sono spiegato..

Ovviamente, scusatemi sono stato poco chiaro.
L'utilizzo del (solo) oggetto recordset, evidentemente, è consigliabile solo se si devono leggere dei dati dal DB (e magari clonarli su altri recordset disconnessi)...

No, no eri stato chiarissimo, è solo che ora sono un po' in crisi...
Senze l'utilizzo del DSN il problema sembra sparire, credi che la apertura dell'oggetto Connessione possa ripropormi il problema?

Poi, non credi che sia più performante il tipo di cursore adLockReadOnly, per la sola lettura, appunto?

No, il problema non era sull'utilizzo o meno della connection.
Il problema stava nel DSN perchè, va bene quando lavori sul tuo pc (server web locale), quando invece pubblichi le pagine sul server remoto, le cose non vanno più come prima in quanto sul server web reale (quello del tuo hoster) non puoi (probabilmente) configurare nessuna origine dati ODBC (compresi: DSN di sistema, DSN Utente, DSN su file, ecc...).

Poi, non credi che sia più performante il tipo di cursore adLockReadOnly, per la sola lettura?

Sicuramente si!