Newsgroup: it.comp.lang.vo-clipper
Titolo: VO e MySql

Rientrato dalla vacanza ho visto che vi è un certo interesse all'argomento.
La cosa mi fa piacere, parliamone.
Il lavoro di Fabrice Foray è una buona base di partenza, ma attenzione usa
alcune funzioni della API vecchie che sono conservate solo per
compatibilità, (le nuove sono più veloci perchè alla VO si direbbe che sono
Strong Typing anche se ovviamente proprio per questo richiedono più
parametri e quindi sono più scomode da usare) quindi se volete crearvi una
vostra classe di accesso diretto tiratevi dentro ed usate le funzioni
nuove.(mi riferisco a quelle dal nome mysql_real_?), non gestisce poi la
caduta della connessione ed un suo automatico rispristino, che può avvenire
in maniera trasparente all'operatore.
Il lavoro che ho fatto non è solo mirato all'accesso diretto a Mysql, ma
pone rimedio ad un limite di MySql, cioè alla mancanza della gestione delle
transazioni, creando di fatto una bufferizzazione nativa del database.Ho poi
creato delle classi compatibili con la SqlTable di VO per conservare
inalterato l'uso dell'Ide di Vo per creare tabelle e finestre.
Chi è interessato all'argomanto è invitato alla conversazione.
Per prove fatte personalmente sconsiglio un accesso via ODBC, troppo lento,
ma non per colpa di Mysql ma per come sono fatte le classi SQLTable, e
SQLSelect di Vo, le cose vanno meglio con ClassMate, ma molto meglio.
L'accesso diretto rimane comunque la strada migliore, a meno che
l'applicazione non debba lavorare qui con Mysql, là con SqlServer, da un
altro utente con Oracle, etc.. allora ODBC è obbligatorio.
L'accesso diretto evita poi il problema di settare gli ODBC su ogni macchina
utente, vi pare poco?
Danilo Giuliani
www.softdevo.com
in...@softdevo.com
sup...@softdevo.com

 ha scritto nel messaggio
news:3d61685a...@news.tin.it...

I programmatori di MySql asseriscono di aver voluto scrivere MySql tenendo
come obbiettivo primario la velocità, per cui non hanno, e pare che non
abbiano intenzione di implementare in futuro tutto quello che può
comprometterla.
I triggers, le views, ed  il rollback vengono considerati elementi
rallentanti.
Nel mio approccio ho voluto tenere fede a questa scelta filosofica, ho
quindi preferito affidare questi compiti al programma che gira su Pc locale,
lasciando il motore (sul server) pulito come dicono loro.
Ho fatto bene ? non so, io ho fatto questa scelta e ti posso assicurare che
la velocità (ho fatto prove comparative con SQLServer 7.0 ed Oracle 8 che
per altri motivi devo usare in modo intenso) se il programma è scritto bene,
non si mette in discussione.
Per quanto rigiarda la robustezza, fino ad ora (tabelle con circa 700.000
record e una trentina di utenti connessi ed operanti) non ho avuto problemi.


 ha scritto nel messaggio
news:Fzm89.234251$Jj7.5...@news1.tin.it...


 ha scritto nel messaggio
news:YQc89.909$xi1....@news2.tin.it...


 suggerimento?
Non a caso mi sono fatto un bel mazzo a scrivere la DevoXMysql, proprio per
evitare gli ODBC. Rimane il problema delle stampe, ma quello è un discorso a
parte che se decidi di percorrere la strada MySql ti spiegherò a parte.
(Report Pro 32 risolve benissimo con l'uso di una utility che distribuiamo
con la DLL full).


 API di MySql.
La versione 2.5.8 era una versione di studio, ha quindi ancora molti
problemini che ora sono stati risolti, inoltre molte parti sono di gran
lunga semplificate e migliorate, comunque utilizzava le API corrette.
