Database Access: le solite rotture...

[DilanDog]

Siamo ormai tutti a conoscenza della fragilità dei db di Ms Access, ma purtroppo sono state sottovalutate da chi ha progettato il sistema su cui mi trovo a fare manutenzione giornalmente e....NON NE POSSO PIU'!

A parte lo sfogo, premesso che il sistema è strutturalmente intoccabile, ovvero NON si possono cambiare i database, e che il motore è ancora il vecchio Jet 3.5 , possibile che questi database si rompano anche quando si lavora in mono utenza??? Dando quindi un pizzico di fiducia in più a Mister Bill, ho cominciato a pensare che forse oltre alla fragilità innata di questi database ci sia anche un utilizzo sconveniente all'interno del software di gestione che mi sono ritrovato tra le mani. Ad esempio, l'apertura di più istanze dello stesso database all'interno dello stesso programma alla fine non equivale ad una multiutenza?? Tipo dieci form differenti con altrettanti DataComponent associati allo stesso database, non è come se ci fosse l'accesso da parte di dieci utenti con relativi rischi di rottura aumentati?? Qualcuno ne sa qualcosa o sa dirmi qualche sito su cui posso documentarmi in proposito?

[Robby78]

Non so dirti se più istanze di apertura di un database access siano paragonabili ad una multiutenza (anche se sospetto di si); posso però confermarti che i database access si rompono tranquillamente anche con una singola utenza, soprattutto se non fai mai ripristina e compatta database. Ricorda che il database si ingigantisce a dismisura senza queste operazioni in quanto ogni transazione rimane memorizzata nel file MDB (delete incluse).

Un piccolo suggerimento (pezza): se proprio non puoi modificare il software, se te la senti di smanettare, e se hai fortuna, potresti provare a fare questo procedimento:

1. Esportare il tuo database access in un altro database più affidabile (ad esempio MSDE).

2. Creare un DSN di sistema per collegarti in ODBC al nuovo DB.

2. Creare un MDB con lo stesso nome di quello che usa ora il tuo programma e creare i collegamenti tramite l'ODBC alle tabelle nel nuovo DB (prestando attenzione a rinominarle correttamente (togli "dbo_"))

Se vedi che le prestazioni calano o se hai incompatibilità nei tipi di dati, nei campi contatori ecc... torna al tuo backup precedente (e non tirare troppi accidenti al programmatore che l'ha sviluppato ).

[DilanDog]

Non so dirti se più istanze di apertura di un database access siano paragonabili ad una multiutenza (anche se sospetto di si); posso però confermarti che i database access si rompono tranquillamente anche con una singola utenza, soprattutto se non fai mai ripristina e compatta database. Ricorda che il database si ingigantisce a dismisura senza queste operazioni in quanto ogni transazione rimane memorizzata nel file MDB (delete incluse).

Un piccolo suggerimento (pezza): se proprio non puoi modificare il software, se te la senti di smanettare, e se hai fortuna, potresti provare a fare questo procedimento:

1. Esportare il tuo database access in un altro database più affidabile (ad esempio MSDE).

2. Creare un DSN di sistema per collegarti in ODBC al nuovo DB.

2. Creare un MDB con lo stesso nome di quello che usa ora il tuo programma e creare i collegamenti tramite l'ODBC alle tabelle nel nuovo DB (prestando attenzione a rinominarle correttamente (togli "dbo_"))

Se vedi che le prestazioni calano o se hai incompatibilità nei tipi di dati, nei campi contatori ecc... torna al tuo backup precedente (e non tirare troppi accidenti al programmatore che l'ha sviluppato ).

Grazie dei suggerimenti, ma purtroppo non è così semplice...il database in questione infatti viene utilizzato da una cinquantina di moduli differenti, oltre ad essere in varie occasioni copiato e trasferito in parte o totalmente a sedi remote tramite procedure non molto ortodosse, tutte operazioni che diventerebbero banali con un supporto quale SqlServer o MySql, ma tant'è....anche se per contro si perderebbe la flessibilità che c'è ora di poter spostare o copiare un database con un semplice copia/incolla senza dover installare driver particolari. Insomma, un gran casino in entrambe le direzioni

Tornando al cambio di driver, il mio obiettivo sarebbe proprio quello di modificare i vari moduli passando ad ODBC ed ADO anzichè DAO, in modo che in un secondo tempo si possa cambiare il tipo di database senza grossi traumi, ma è sicuramente un lavoro che richiede tempi lunghi, soprattutto per il discorso della compatibilità visto che non è pensabile di fermare tutto, trasformare tutto e ridistribuire tutto il pacchetto, bisogna per forza fare in modo che due moduli con le due teconologie differenti possano leggere lo stesso database.
Per questo se nel frattempo trovassi qualche articolo o testimonianza diretta che spieghi come minimizzare queste rotture, ottimizzando le varie operazioni, sarebbe l'ideale

[Robby78]

Beh ad accedere allo stesso database non c'è problema: ache con ADO ci si può connettere ad un database access.
L'unico problema è che le sintassi SQL dei vari database differiscono per qualche dettaglio (soprattutto nei campi data, nelle conversione dei datatype, nella gestione dei contatori ecc...). Dovresti creare una funzione che ti converta le stringhe sql nel formato del database che usi.

Per creare una connessione ADO in modo grafico basta creare un file con estensione UDL; fai doppio click e ti crei la connessione; dopo apri il file con notepad e lì dentro trovi la connection string da usare nel tuo codice.
Potresti anche passare al programma direttamente il file UDL in modo da rendere il programma più customizzabile.

[DilanDog]

Beh ad accedere allo stesso database non c'è problema: ache con ADO ci si può connettere ad un database access.
L'unico problema è che le sintassi SQL dei vari database differiscono per qualche dettaglio (soprattutto nei campi data, nelle conversione dei datatype, nella gestione dei contatori ecc...).

Si, è la strada che sto seguendo, ed infatti la differenza maggiore l'ho riscontrata proprio nella gestione dei campi contatore che nel nostro sistema sono molto importanti perché identificano anche il nome di alcuni files ad essi associati quindi ho bisogno di avere subito dopo l'inserimento di un nuovo record il campo contatore aggiornato e la prima cosa che ho scoperto è che con ADO non è sempre così...ed ho scoperto anche che l'istruzione sql "SELECT @@identity" non funziona sugli mdb di access '98...e se li converto in access 2000 poi le vecchie applicazioni non li leggono più se non modificando i riferimenti DAO e ricomplilandoli....insomma, mille problemi che rallentano tantissimo lo sviluppo. E se c'è una cosa che non sopporto è dover limitare le funzioni su un software per garantire la compatibilità con le vecchie versioni

Che tu sappia esiste qualche altro modo oltre ad @@identity per avere i campi contatore aggiornati subito dopo l'upload?

[Robby78]

Che tu sappia esiste qualche altro modo oltre ad @@identity per avere i campi contatore aggiornati subito dopo l'upload?

Cosa intendi dire esattamente? Scusa, non capisco.

[DilanDog]

Che tu sappia esiste qualche altro modo oltre ad @@identity per avere i campi contatore aggiornati subito dopo l'upload?

Cosa intendi dire esattamente? Scusa, non capisco.

Mi spiego meglio: quando ho cominciato a fare prove con ADO mi sono accorto che subito dopo aver inserito un record usando, ad esempio, il dataaccess di VB, il campo contatore non risultava aggiornato se non rieseguendo la query per riaprire il recordset ed in ogni caso lo trovavo aggiornato solo dopo qualche secondo. In pratica dovevo inserire un ciclo che continuasse a rieseguire il requery del recordset fino a quando non trovavo finalmente il record inserito In caso contrario, il record era nel recordset in memoria ma con il campo autoincrementante impostato a null
Indagando su internet ho visto che per avere subito il campo contatore aggiornato dovevo eseguire una query tramite il metodo "execute" di questo tipo:

Codice: Seleziona tutto

AdoConn.Execute "SELECT @@identity FROM NomeTabella"


Ed effettivamente inserendo questa istruzione nell'evento "AfterInsert" il campo contatore risulta correttamente compilato, ma solo utilizzando la versione di access2000 dei files mdb. E quindi, siccome i nostri mdb sono ancora quelli della versione 98 di access, eccomi di fronte ad un nuovo problema di compatibilità

[Robby78]

ok, ma sei sicuro che non sia un banale problema di refresh del tuo dataaccess? io sono convinto che in realtà il campo contatore si aggiorni subito all'interno del database, ma che tu debba aspettare che il dataaccess si aggiorni a sua volta... non ricordo, ma mi pare che ci sia un metodo per forzare il refresh del dataaccess

[DilanDog]

ok, ma sei sicuro che non sia un banale problema di refresh del tuo dataaccess? io sono convinto che in realtà il campo contatore si aggiorni subito all'interno del database, ma che tu debba aspettare che il dataaccess si aggiorni a sua volta... non ricordo, ma mi pare che ci sia un metodo per forzare il refresh del dataaccess

Sicuramente c'è di mezzo il refresh, ma appunto il refresh di un recordset non sempre è possibile, a volte è lento e dopo averlo eseguito bisognerebbe recuperare la posizione in cui si era prima di eseguirlo...insomma, un sacco di operazioni che rallentano notevolmente dove c'è bisogno ad esempio di molti inserimenti veloci fatti in sequenza. La soluzione più veloce e sicura da quanto ho letto in giro pare essere questa istruzione IDENTITY che restituisce appunto l'ID dell'ultimo record inserito. Sempre leggendo in giro tra l'altro si capisce che è una funzione introdotta con il JET 4.0 e quindi in teoria slegata dalla versione di database che si apre...peccato che sia solamente una teoria, perché i risultati sono differenti se utilizzati su una versione di database o su un'altra

Come accade spessissimo quando si prova qualcosa di nuovo in programmazione si passa 1 giorno ad impararla ed una vita a trovare i bug relativi a questa nuova tecnica...come se non bastassero già i nostri

[Robby78]

Come accade spessissimo quando si prova qualcosa di nuovo in programmazione si passa 1 giorno ad impararla ed una vita a trovare i bug relativi a questa nuova tecnica...come se non bastassero già i nostri

hehehe si, infatti!

beh, se scopri qualcosa posta qui, che mi interessa! buon divertimento