[VB6] Creare oggetto Data per database Access da codice

[Cavaliere Nero]

Nel mio caso la versione di Access è vecchia, ma il programma è triutente... mi serve un DAOADO XD
Dovrei provare entrambe per vedere quale vada meglio
Grazie per l'approfondimento!

[gibra]

Originariamente inviato da Cavaliere Nero
Nel mio caso la versione di Access è vecchia, ma il programma è triutente... mi serve un DAOADO XD
Dovrei provare entrambe per vedere quale vada meglio
Grazie per l'approfondimento!

Non ne vale proprio la pena di investire tempo in una tecnologia vecchia e sorpassata (DAO).
Dato che il tuo programma è multi-utente, hai una ragione ancora maggiore per passare ad ADO, tanto devi mettere mano al codice in ogni caso.

In una applicazione multi-utente la cosa primaria è: NON usare il Contatore di Access! MAI!
Si deve invece utilizzare un contatore custom (vedi i link sotto).
Sto preparando un progetto, per questo, che pubblicherò fra breve.

In queste discussioni troverai un mare di suggerimenti 'determinanti'

Tipi di dati non corrispondenti nell'espressione criterio
http://forum.html.it/forum/showthrea...9#post12894609

Gestione DB multiuser
http://www.visual-basic.it/forum/b.asp?m=181619

In multi-utenza, nelle mie applicazioni ho sempre utilizzato questa tecnica:
Utilizzo della concorrenza ottimistica
http://msdn.microsoft.com/it-it/library/aa0416cz(VS.80).aspx

[gibra]

Come promesso, ecco il progetto aggiornato (anzi direi che è una mini-applicazione!) che implementa la multi-utenza, Command, esportazione Excel e molte altre funzionalità:

Progetto Prova Login 2
http://nuke.vbcorner.net/Progetti/VB...3/Default.aspx

[Cavaliere Nero]

Originariamente inviato da gibra
In una applicazione multi-utente la cosa primaria è: NON usare il Contatore di Access! MAI!

Non uso quasi mai i contatori automatici nemmeno per le applicazioni mono-utente, penso che sia sempre meglio averne il pieno controllo (in caso di Access ricordo che continua a incrementarsi senza possibilità di modifica).

Nel mio caso il programma era già finito, ciò che ho fatto è solo una aggiunta, dovrei apportare una modifica radicale per poter inserire i controlli che mi hai indicato e non mi conviene in termini di tempo... però risolvono molti problemi. Mi conviene tenerne conto per applicazioni future o quando avrò tempo di poter fare aggiornamenti più grandi... il problema è sempre il tempo... se ci fosse un programma per rallentarlo XD

Grazie per i preziosissimi consigli e dei link Gibra! (Utilizzo della concorrenza ottimistica http://msdn.microsoft.com/it-it/library/aa0416cz(VS.80).aspx <--- non trova la pagina qui).

[alka]

Originariamente inviato da gibra
In una applicazione multi-utente la cosa primaria è: NON usare il Contatore di Access! MAI!

Perché non dovrebbe essere utilizzato?

[gibra]

Originariamente inviato da alka
Perché non dovrebbe essere utilizzato?

Perchè il Contatore di Access può sballare in multi-utenza.
Quando lo usai all'inzio mi ritrovai più di qualche record che avevano lo stesso numero.

Che è appunto il problema segnalato nel seguente articolo:
HOW TO Implement Multiuser Custom Counters in Jet 4.0 and ADO 2.1
http://support.microsoft.com/default...b;EN-US;240317
che recita:


Because the Microsoft Jet database engine has a read cache and lazy writes, you can get duplicate values in your custom counter field if two applications add records in less time than it takes for the cache to refresh and the lazy-write mechanism to flush to disk. This article presents a method that takes these factors into account.

Il problema è che l'articolo richiede:
- una tabella-contatore 'supplementare' per ogni tabella del database
(non proprio agevole)
- il campo contatore deve già esistere (bisogna aggiungerlo a manina)
- se la tabella non è vuota, bisgona impostare il valore di ogni contatore a mano!!!

Invece nel mio progetto mostro come ho perfezionato la tecnica suggerita dall'articolo:
- basta una sola tabella per tutti i contatori
- se il campo contatore non esiste viene creato automaticamente
- se la tabella non è vuota, viene utilizzato il progressivo corretto

Così è molto più pratico, lo sviluppatore non si deve preoccupare di niente, se non di ricava l'ID con l'apposita funzione.

Mai più avuto problemi.

[gibra]

Originariamente inviato da Cavaliere Nero
Non uso quasi mai i contatori automatici

Bene.

Originariamente inviato da Cavaliere Nero
(Utilizzo della concorrenza ottimistica http://msdn.microsoft.com/it-it/library/aa0416cz(VS.80).aspx <--- non trova la pagina qui).

Come vedi, la parte sottolineata non include tutto il link (misteri del web...)

Copiati il link completo
http://msdn.microsoft.com/it-it/libr...cz(VS.80).aspx
ed incollalo sulla barra degli indirizzi del tuo browser

[alka]

Originariamente inviato da gibra
Perchè il Contatore di Access può sballare in multi-utenza.

Che io sappia, si tratta di un problema "datato" e che è stato ampiamente risolto nelle versioni più recenti di Microsoft Access. Da più ricerche fatte non molto tempo fa, ad esempio su StackOverflow, il campo "AutoNumber" risultava il metodo più sicuro e gestito per ottenere un contatore per il quale è garantita l'univocità in ambito multiutenza (anche perché si incrementa sempre).

Originariamente inviato da gibra
Quando lo usai all'inzio mi ritrovai più di qualche record che avevano lo stesso numero.

Dovrebbe essere sufficiente una chiave.

Originariamente inviato da gibra
Che è appunto il problema segnalato nel seguente articolo:
HOW TO Implement Multiuser Custom Counters in Jet 4.0 and ADO 2.1
http://support.microsoft.com/default...b;EN-US;240317
che recita: [...]

Come indicato nell'articolo, il problema sembrerebbe riguardare più problemi di cache nel driver specifico che il campo "Contatore" in quanto tale. In ogni caso, come dicevo all'inizio, l'articolo è datato.

Ciao!

[gibra]

Originariamente inviato da alka
Che io sappia, si tratta di un problema "datato" e che è stato ampiamente risolto nelle versioni più recenti di Microsoft Access.

Non importa quanto sia datato.
E' un problema del motore JET, che niente ha a che vedere con Microsoft Access (che è un'ambiente di sviluppo);
e dato che il JET non va oltre la versione 4... (a cui l'articolo fa riferimento) il problema è attuale fino a quando si usa il JET.

Il discorso è diverso per un database Access nel nuovo formato 2007/2010 in cui si usa il nuovo Provider Microsoft.ACE.OLED.12.0.

Originariamente inviato da alka
Da più ricerche fatte non molto tempo fa, ad esempio su StackOverflow, il campo "AutoNumber" risultava il metodo più sicuro e gestito per ottenere un contatore per il quale è garantita l'univocità in ambito multiutenza (anche perché si incrementa sempre).

Non ho idea a cosa tu ti riferisca.
Io comunque l'ho provato sulla mia pelle.

[alka]

Originariamente inviato da gibra
Non importa quanto sia datato.
E' un problema del motore JET, che niente ha a che vedere con Microsoft Access (che è un'ambiente di sviluppo);
e dato che il JET non va oltre la versione 4... (a cui l'articolo fa riferimento) il problema è attuale fino a quando si usa il JET.

MS Jet è stato aggiornato più volte da diversi Service Pack.

Originariamente inviato da gibra
Non ho idea a cosa tu ti riferisca.
Io comunque l'ho provato sulla mia pelle.

A me non è mai capitato. Sarò fortunato...