Newsgroup: it.comp.lang.delphi
Titolo: Problema connessione Mysql - Firedac - TFDConnection - XE5

Salve!
Ho appena provato a connettermi ad un mio db che risiede su una macchina 
della mia lan, utilizzando firedac (win32 al momento...poi passo su 
android...)
Semplice form vuota....metto TFDConnection, i parametri CORRETTI e mi 
sputa fuori questo messaggio quando provo a connettermi al db:
 
  [FireDAC][Phys][MySql]-314 Cannot load vendor library [libmysql.dll 
libmysqld.dll]. Impossibile trovare il file specificato.
Hint: Check it is in the PATH or application EXE directories.
 
 
Qualcuno può provare? magari è un baco....(o nel componente o 
nell'installer che non mi ha messo la roba nel posto giusto...?)
 
Ovviamente con altri programmi mi connetto al volo al db ed i parametri 
son giusti....
 
 
Grazie!!!

 son giusti....
 
..quali "altri programmi"? Hai provato con dbx? Se si, hai lo stesso problema?
 
A.


 
1) Altri programmi per connettermi al db sulla macchina remota (eg mysql 
workbench ed altri)
2) non ho mai usato dbx :(    (lo so uccidetemi...)
3) ho provato a copiare la dll mancante nella cartella 
dell'eseguibile,ma il problema persiste...strano...
 
Indago e vi tengo aggiornati!
 


come al solito le soluzioni arrivato dopo aver appena postato...
 
ho copiato la dll in nella cartella windows ed è filato tutto liscio...
 


 
non è supportato per android....
 
alternative free ?
 
:(
 

> non è supportato per android....
 
 
Sei certo di questa cosa?
Ti faccio questa domanda xche mi sembra prp strano...
Android e Ios si portano dietro SqlLite.
E se dbx non funziona come kaz ti connetti ad un db LOCALE al device?
 
Hai errori o che altro?
 
A.

> non � supportato per android....

ho chiesto sul forum ufficial embarcadero...e mi � stato confermato (cmq 
da un'errore....adesso sono fuori casa e non ricordo).
C'� un'alternativa, ma � a pago...e costa troppo a paragone della 
minuscola app che devo fare....
L'alternativa � mydac...ma come detto � out of budget...
 
:�(
 

 alternative free ?
 
Ma tu stai cercando di connetterti a un database MySQL da Android?
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 


si
 
 
 
(pardon se mi sono spiegato male a priori)

 (pardon se mi sono spiegato male a priori)
 
Non so se collegarsi direttamente a un database da un dispositivo mobile sia sempre una buona idea: per la stessa natura del device, ci sono molte probabilità che una connessione cada, oltre al dover copiare librerie client magari voluminose sul dispositivo e rendere complessa la struttura dell'app stessa.
 
Secondo me, è meglio optare per una soluzione lato server che si colleghi al database usando tutti gli strumenti "tradizionali", con cui magari l'app sul device può colloquiare in modalità REST, senza connessioni permanenti, inviando comandi ridotti e semplificando in generale il sistema, che lato server può essere riutilizzato anche per lo sviluppo di client di diverso tipo.
 
A mio avviso, mettere la logica di connessione al DB nell'app ti spingerà a implementare al suo interno anche gran parte della logica di business che sarebbe meglio risiedesse altrove, lasciando che l'app faccia esclusivamente le operazioni minime per i compiti a cui è destinata.
 
Ciao!
  Marco.



Condivido per te, ma l'app che intendevo siluppare/testare/provare non 
fa uso intenivo del db, masimo 5 tabelle, da consultare ogni 4/5 ore, 
massimo 100 record di testo su 6 o 7 campi....

 massimo 100 record di testo su 6 o 7 campi....
 
Non ne facevo una questione di performance o di complessità, ma di architettura del sistema.
 
Ad ogni modo, il metodo preferenziale per collegarsi a database non presenti nativamente sul dispositivo è quello di costruire un "middle tier" tra i due attori, il DB e l'app.
 
Utilizzando ad esempio *DataSnap* è questione di pochi minuti, in fondo, e non cambia molto l'accedere a un origine dati DataSnap o MySQL dal punto di vista dei componenti e del codice, anzi...
 
E se un domani vuoi cambiare backend, DB o altro, puoi farlo sempre e comunque, senza preoccuparti della presenza o meno di un driver per Android, o per altri dispositivi da supportare.
 
Ciao,


..però se ti serve un db LOCALE al device puoi averlo.
Ho chiesto esplicitamente questa cosa a Daniele Teti e mi ha risposto "si".
Mea culpa, non ho pensato a chiedere della tecnologia di accesso ai dati da utilizzare.
Ovviamente (ma non per tutti) non è che mo uno installa teradata o db2 su uno smartphone..Ci sono db apposta. Daniela citava l'onnipresente SqlLite e Interbase.
Mo che ci penso, parlando di accesso ai dati sempre Daniele lanciò alla presentazione del 19 settembre a Milano un frase "...meglio Firedac...".
 
A.

 Mo che ci penso, parlando di accesso ai dati sempre Daniele lanciò alla presentazione del 19 settembre a Milano un frase "...meglio Firedac...".
 
Ri-esattamente. :)



dato che l'app non è urgentissima....aspetto qualche alternativa a 
mydac.... :°°°°°°°°°(((((((((((((((

 ato che l'app non è urgentissima....aspetto qualche alternativa a mydac....
 
Aspetta aspetta, alla fine non ne ricavi niente: l'osservazione di Marco
deve essere ascoltata, non ci si collega ad un database da mobile, per
questo ci sono i web services.
 
dopodiche, se ti vuoi tenere un piccolo db locale, fai pure, ma non sono
fatti per questo tipo di  utilizzi: in locale ti devi tenere le cose
tipo configurazione utente, log o una piccola cache.
 
Se fai una app per mobile che si collega direttamente al db, sbagli in
partenza. Una app è fatta per essere scaricata da moltissimi
dispositivi, migliaia, decinedi migliaia: cosa fai, una connessione per
ognuno di questi?
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 questo ci sono i web services.
 
Come web service? Non erano obsoleti, lenti, insomma, 'na chiavica?? 
Usiamo REST, e ke kaz! :-D
 
Accedere direttamente ad un db da uno smartphone potrebbe non essere una buona idea. Insisto molto sul "potrebbe" in quanto potrebbero esistere casi in cui questa cosa potrebbe aver senso o essere utile, magari un accesso da un tablet via WAN aziendale. Se poi esci e provia via gsm o altro, non entri.
 
Questo pero' non vuol dire che sul device NON PUOI AVERE UN DB utile ma solo un Db di comodo. Questa idea si basa su un presupposto che scontato non è: 
 
** avere SEMPRE UNA ACCESSO ALLA RETE **
 
Piu' in generale, ci sono cose che DEVONO funzionare, anche se in modo ridotto, se la rete, qualunque essa sia,  non è disponibile.
..e non mi dite che non riuscite a immaginare cosa.... :-D
 
Io posso citare 5 posti dove nell'ultimo anno ho personalmente riscontrato la mancanza di  copertura GSM o altro  A PRESCINDERE DALL'OPERATORE.
...no, non parlo di uno scoglio in mezzo al mediterraneo.
Questi posti sono tra Milano, Como, Monza e la provincia di Viterbo.
 
E se una app DEVE poter funzionare in uno di questi posti dici al tuo cliente di fottersi xche su smartphone il db non si mette?? :-|
 
Ovviamente (ma non per tutti) il fatto che PUOI avere un db locale al device non vuol dire che DEVI averlo. 
 
E se devi averlo, ovviamente (ma non per tutti) non è che sul device ci metti il database di sap di una multinazionale.
 
A.

 
 


 lo sviluppo su mobile si dà per scontata la presenza della rete.
 
 
A me interessa risolvere i problemi dei miei clienti.
E se per farlo, FERMO RESTANDO IL MAI SCONTATO BUON SENSO, devo mettere un db locale al device, lo faccio. 
 
A.


Ok,mi spiego meglio....
Sul db non ci si lavora con continuità...
L'utente apre l'app, si collega al db e ci lavora pochissimo 
(aggiornamento di qualche campo, niente di che),.
La connessione dura al max 3 o 4 minuti (il tempo di consultare qualche 
"memo", ed aggiungerci note).
I dispositivi sono al max 5 o 6.
Sul pc che tiene il db si lavora invece in modo assiduo (postazione 
fissa nella lan del db server)
E' sempre fuori luogo o no connettersi direttamente al db?
(sono ignorante.....è solo per capire se così va bene o no,niente 
polemica!!! ogni suggerimento è BEN ACCETTO!!!!)

> gestionale non ha alcun senso.
 
mica tanto, Zucchetti ha una gestione ordini su tablet con iOS, ma non 
e' la sola.
l'agente prende gli ordini e dopo per inviarli ?
- crea degli allegati in formato testo ed invia email automatiche 
all'azienda
- si collega in qualche modo ad un db per scaricare gli ordini
 
I Tablet si possono connettere ad internet (WiFi o InternetKey) ammesso
che si colleghino ad un Db tramite una applicazione tipo REST
 
- cosa mettono sul device mobile (solo eseguibile client ?)
- e sul server in azienda (un exe win32 da chiamare dal mobile, mi pare 
improbabile; forse dll)
 
Gli esempi di delphi per Android (FishAct su Interbase) non fanno 
proprio questo ?
 
Mi piacerebbe capire cosa farne di un Rest Server e Client una volta 
creati su Delphi, per provare nella realta' Tablet + Db su Server (in 
considerazione che molti server usano Linux, e che gli exe win32 non 
serviranno).
 
 

 E se per farlo, FERMO RESTANDO IL MAI SCONTATO BUON SENSO, devo mettere un db locale al device, lo faccio. 
 
Hai appena spiegato il motivo per il quale non seguiresti le best
practices.. cos'altro devo dirti per convincerti del contrario? :)
 
Ad esempio... e se un domani vogliono mettergli le schede GSM? Estendere
la app a nuove funzionalità con nuove interrogazioni e dati più
massicci? Aumentare l'utenza? Prima o poi dovrai mollare le connessioni
dirette al db, non credi?
 
Tanto sappiamo già che cosa deciderai di fare, no? ;-)


 E se per farlo, FERMO RESTANDO IL MAI SCONTATO BUON SENSO, devo mettere un db locale al device, lo faccio. 
 
Nessuno contesta questo. Però corri il rischio di dover risolvere anche altri problemi che magari non ti aspettavi, o dover gestire una architettura/installazione inutilmente più complessa.
 
Ciao,
  Marco.


 polemica!!! ogni suggerimento è BEN ACCETTO!!!!)
 
I motivi sono stati ampiamente discussi nel thread.
 
Non è fuori luogo, ma visto che le operazioni sono così semplici, dov'è il problema nel fare questo "micro server" DataSnap per servire espressamente le richieste della tua app mobile invece di insistere a volerti collegare a un DB dal dispositivo quando non c'è verso di trovare un driver per farlo? :)


Grazie, Marco.
 
Finalmente siamo arrivati a qualcosa di concreto che va oltre regole e cose scontate. Adesso ho capito e condivido.
 
Solo alcune precisazioni
 
1) Per l'esempio fatto da me conviene usare REST se non altro per non avere casini con la connessione al database che potrebbe essere instabile. 
 
2) se una app DEVE funzionare anche in assenza di rete, l'unica è avere un  db ANCHE (ma non solo) in locale.
Ovviamente, ma non per tutti, sarà un db leggero sia come mole di dati che come struttura.
 
3) scrivere una app venduta sui vari market che accede DIRETTAMENTE ad un database senza passare da REST o similari, è FOLLIA.
 
4) la lista dei caffe che ti devo si allunga
 
A.

 4) la lista dei caffe che ti devo si allunga
 
Per così poco... :D
 
In realtà, sono pure io in modalità esplorativa/documentativa/discutiva, sono riflessioni scritte di quello che sto leggendo in questo momento e poco altro, per cui potrei anche dire o riportare delle porcate. :)



 
Perchè sono alle prime armi :) ed il "microserver" gira su una nas con 
mysql.
Vedrò di aggirare il problema (visto il costo esoso di mydac) 
"ciucciando" un db sqlite dal server e risparandoglielo indietro 
modificato....(o qualcosa tipo xml....farò un server tcp che prende i 
dati....)
(le connessioni da parte dei clients non saranno mai concorrenti, c'è 
una probabilità su 1000000000....più facile fare 5+1!!!)
 
Grazie infinite!!!!
 

 dati....).
 
Ma questa soluzione è più facile di quella proposta? :-o


 Ma questa soluzione � pi� facile di quella proposta? :-o
 
Se DATASNAP non gira su arm...
Insomma tutto da ri-studiare
:)
 

 Insomma tutto da ri-studiare
 
Il *client* DataSnap va su ARM, mentre il *server* DataSnap va su Windows, o su Mac OSX.
 
Ciao,
  Marco.


 Per così poco... :D
 
Per dovere di cronaca, riporto questo link fresco fresco su Linkedin:
 
http://blogs.devart.com/dac/index.php/android-database-application-development-in-rad-studio-xe5.html#
!
 
 
A.


Grazie ancora per interessarvi ad un neofita :)