Newsgroup: it.comp.appl.access
Titolo: [HELP] Meglio MSDE o MySQL

Domanda:
dovendo scegliere di migrare la base dati e di effettuare l'upsize del
codice del mio dbase da ADO a DAO, secondo Voi, sulla base di quanto scritto
in oggetto, cosa č meglio tra MSDE o MySQL e soprattutto ... perchč?
Grazie per eventuali delucidazioni "illuminanti"!
Buona giornata,
--
MC

"MC" <achi...@lachieda.ame> ha scritto nel messaggio
news:d83eoq$tr6$1...@domitilla.aioe.org...

MSDE fa (quasi tutto) quello che fa MS SQL ma  hai un limite fisico di 6-7
utenti connessi simultaneamente,
usando MySQL mi pare che non dovresti avere questo limite, perň non puoi
usare i progetti di ACCESS (adp)
bye David


In realtà non è chiaro cosa tu intenda per upgrade da ADO a DAO, di solito è 
il contrario.
Non sono chiare ragioni per cui tu intenda migrare l'applicazione, 
ciononostante è chiaro che tu voglia passare a qualcosa di più di Jet, che 
sia sempre gratuito. Giusto?
Come ti è già stato risposto MSDE ha un limite fisico di n utenti, ma non è 
necessario utilizzarlo con i progetti .adp, si può altresì collegare tramite 
odbc.
Anche Mysql può essere utilizzato come back end tramite odbc, senza dover 
necessariamente stravolgere la tua applicazione.
La scelta è forse determinata dalla maggior scalabilità verso il "vero" sql 
server nel caso in cui tu utilizzassi MSDE (in efetti questa è la ragione 
per cui MS lo rende freeware) . Un domani che le tue finanze o le tue 
esigenze te lo consentissero potrai facilissimamente fare il porting verso 
SQL server.
In tal caso avrai tutto il tool enterprisemanager e query analizer, nonchè 
backup, mentre con Mysql dovresti comunque ricorrere a tools esterni.
Facci sapere, perchè la cosa interessa anche a me.
 


Il fatto è che sono in fase di analisi per capire le reali esigenze e
eventuali costi da far caricare e per le nostre necessità,
SQL è un pianeta che difficilmente sarà raggiunto, al massimo lo piazzeremo
in sede dove avviene il travado dei dati dei punti satellite ... ma anche
questo è un passaggio prossimo venturo.
Intanto ho le idee un pochetto più chiare e nel dubbio leggo qualcosa su
MSDE, MySQL gia lo conosco abbastanza lavorandoci tramite un sito in PHP.
Intanto grazie, poi vista la tua richiesta, se dovessi aumentare il know-how
in materia, se ti fa piacere, ti passo qualche input.
Saluti,
--
MC


Ciao
Cinzia

 ha scritto nel messaggio 
news:42a55b35$0$19531$5fc...@news.tiscali.it...

L'hai fatto apposta!!!!
Spiegaci meglio: l'unica sostanziale differenza tra MSDE o come si chiamerà 
SQL Server 2005 Express, sarà la mancanza di interfaccia grafica di 
amministrazione????
Allora contrariamente a quanto affermava Carlo Costarella ci potrà essere un 
futuro per .adp?

 futuro per .adp?
Spero proprio di sì :-)
Ciao Giorgio

 futuro per .adp?
Speriamo di si,  ma accidenti gli uomini MS non si sono sbottonati... e chi
lo sa?
Ciao
Cinzia


Il futuro per ADP non è, a mio avviso, determinato dall'uso di msde che 
potrebbe essere anche sql server; bensì dalle difficoltà riscontrate nel 
porting delle tabelle access a tabelle sql, dal non poter più utilizzare le 
query nel modo così semplice a cui ci aveva abituato access e a tantissime 
altre cose che l'ottima Cinzia ha trattato alla CISA. Tutte queste 
difficoltà sono derivate proprio dall'uso negli ADP di sql. Un accessista ci 
perde moltissimo in termini di praticità e di RAD anche se guadagna molto in 
termini di conoscenza, di sicurezza e di scalabilità.
A mio avviso si può ottenere lo stesso ottimo risultato sfruttando sql via 
odbc senza rinunciare alle ottime possibilità di access.
Complicarsi la vita per ottenere lo stesso risultato non credo sia una 
strada da seguire...
Ciao, Carlo 

 ha scritto nel
messaggio news:EhCpe.997728$b5.43...@news3.tin.it...

Ciao Carlo,
le "presunte" difficoltà a esportare le tabelle da Access a SQL le avresti
anche se poi tu decidessi di usare un MDB collegato via ODBC  al Db SQL.
Quello che ho fatto vedere fino all'inizio della demo della Biblioteca,  lo
dovresti fare sia se tu usassi un ADP sia se usassi un MDB collegato via
ODBC.
Alla fine i controlli preliminari non erano poi così tanti  e tutti in ogni
caso dipendevano dal fatto che  il db in Aceess potrebbe non essere
strutturato a regola d'arte,  (Access purtroppo o per fortuna , ti lascia
dei gradi  di libertà diciamo così "fuori standrd") poi credimi le
difficoltà conoscendole sono facilmente aggirabili,  e se ti abitui a creare
tabelle su Access come se fossi su SQL poi non devi più nemmeno fare i
controlli.
Mi spiace aver dato la sensazione che il processo di Porting sia difficile,
lo è nella misura in cui il database in Access è fatto in maniera non
ottimale e la cosa più difficile non è trasferire le tabelle, ma modificare
completamente la logica che usi nella tua applicazione, sfruttando in
maniera ottimale le possibilità offerte da un db veramente client -server.
Usando un MDB collegato via ODBC non hai il problema di adattare le query, e
le maschere ma ho la sensazione che così facendo useresti SQL come se fosse
Jet e correresti il rischio di fare un'applicazione che su SQL è più lenta
che su Access...
Comunque in generale dovendo fare una nuova applicazione su SQL, userei ADP,
dovendo  portarne una già esistente in MDB su SQL, se l'applicazione è molto
complessa, continuerei ad usare l'MDB +ODBC, cercando di cambiare un po' la
logica dove serve, avendo comunque la possibilità di farlo un po' alla
volta, se invece non è molto complessa penserei comunque all'ADP.
Saluti
Cinzia

[cut]
Ciao Cinzia,
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto è stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero più elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano è stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho più effettuato in questi mesi procedure di questo tipo, ma volevo
chiederti semplicemente se in questi mesi sono saltate fuori spiegazioni per
quanto riguarda l'insuccesso della procedura giudata in questi casi.
Se avessi partecipato alla CISA, te l'avrei chiesto in quella sede, dove
avrei sicuramente approfondito bene l'argomento.
Il database era sviluppato in A03 in formato 00 e io utilizzo MSDE.
Ciao.





Ciao Cinzia,
ti scrivo qua perchè la reply non parte se la faccio dal tuo post.


[cut]
Ciao Cinzia,


[cut]
[cut]
Ciao Cinzia,
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto č stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero piů elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano č stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho piů effettuato in questi mesi procedure di questo tipo, ma volevo


[cut]
Ciao Cinzia,
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto è stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero più elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano è stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho più effettuato in questi mesi procedure di questo tipo, ma volevo








[cut]
Ciao Cinzia,
provo a risponderti da questo post perchč dall'altro č un'ora che provo
invano !
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto č stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero piů elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano č stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho piů effettuato in questi mesi procedure di questo tipo, ma volevo


[cut]
Ciao Cinzia,
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto è stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero più elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano è stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho più effettuato in questi mesi procedure di questo tipo, ma volevo




 ha scritto nel messaggio
news:42a55b35$0$19531$5fc...@news.tiscali.it...

[cut]
Ciao Cinzia,
provo a risponderti da questo post perchè dall'altro è più un'ora che provo
invano ! Mi scuso con tutti per il quoting, ma stasera OL fa le bizze !


[cut]
Ciao Cinzia,
provo a risponderti da questo post perchè dall'altro è più un'ora che provo
invano !


[cut]
Ciao Cinzia,
provo a risponderti da questo post perchč dall'altro č un'ora che provo
invano !
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto č stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero piů elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano č stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho piů effettuato in questi mesi procedure di questo tipo, ma volevo


 ha scritto nel messaggio
news:42a55b35$0$19531$5fc...@news.tiscali.it...

[cut]
Ciao Cinzia,
provo a risponderti da questo post perchè dall'altro è un'ora che provo
invano ! Mi scuso con tutti per il quoting, ma stasera OL fa le bizze !
capperi, questo argomento mi interessa tantissimo !
Io ho una domanda da farti non per tanto per quanto riguarda l'upzise delle
tabelle di un MDB a un ADP, ma per quanto riguarda quello relativo alle
Forms e alle queries, e ai reports
Ti confesso che non ho moltissima esperienza in questa procedura, l'ho fatta
poche volte e su mdb che
erano stati preparati ad hoc - trovati in un CD di un libro di testo di un
MVP tra l'altro - non ho riscontrato problemi tutto è stato correttamente
"convertito".
Il problemi sono sorti quanto l'ho fatto su un mio mdb che conteneva il
numero più elevato tra forms, tebelle, queries.
Pure avendo rispettato, come da manuale, tutto quello che la dettagliata
procedura prevedeva ( un capitolo intero di qualche decina di pagine) per
l'upsize ( preparazione delle queries, delle origini dati delle combo nelle
forms => queries salvate, cancellazione delle queries a campi incrociati e
delle pass-trough che sono gestite in ADP come SP solamente, queries con
clausola where, la riscrittura del codice da DAO a ADO, e ce ne sono molte
altre te indico quelle che mi ricordo meglio), le forms i reports e le
queries non sono state "upgradate"
Se ti ricordi ne avevamo parlato anche su mpioa verso la fine dell'anno
scorso: l'esercizio di riscostruire tutto a mano è stato faticoso, ma
estramamente proficuo, mi e servito davvero tanto.
Non ho più effettuato in questi mesi procedure di questo tipo, ma volevo


 ha scritto nel messaggio
news:42a7041f$0$17106$5fc...@news.tiscali.it...

 Cinzia ha ragione, noi abbiamo migrato le tabelle di alcuni MDB via  (ODBC)
abbastanza complessi su SQL2000
e dopo l'applicazione risultava più lenta rispetto ad  ACCESS; per cui
abbiamo dovuto rivedere la logica di programmazione
per cui possiamo confermare che se devi sviluppare ex novo conviene usare
ADP e comunque la migrazione non è quasi mai indolore.
Bye David & Enrico


Cerchiamo di non ragionare per ASSOLUTI.
Togli il 'SOLO' dalla tua frase perchè l'applicativo che ho mostrato al
CISA1 si interfacciava con MSDE in DAO!
:-)
Ciao.
--
Simplex2
www.mdenittis.it

 ODBC non è contemplato dalla Direzione a cui appartengo...
:-O !!!!
Devi dire all tua direzione (con la 'd' minuscola, perchè minuscola è
l'ampiezza di vedute o di budget) che vi siete autocavati un testicolo col
cucchiaio!
:-D :-D :-D
Ciao.
--
Simplex2
www.mdenittis.it