-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian collegarsi a DB remoto da app Android
- Thread starter fapic
- Start date
- Similar Threads Similar Threads
C'è molto materiale su questo argomento, nel sito. Basta fare una ricerca col "Search" in alto a destra.
Immagino che tu debba usare RDC.
Personalmente non me ne sono occupato, perché di norma si ha a disposizione MySql+PHP; infatti, ti faccio una contro-domanda: mi dici qualcosa circa il tuo sito? Cioè, dove è "ospitato", cosa ti mettono a disposizione (a meno che non sia su una tua macchina, ovvio)... etc?
Immagino che tu debba usare RDC.
Personalmente non me ne sono occupato, perché di norma si ha a disposizione MySql+PHP; infatti, ti faccio una contro-domanda: mi dici qualcosa circa il tuo sito? Cioè, dove è "ospitato", cosa ti mettono a disposizione (a meno che non sia su una tua macchina, ovvio)... etc?
Io utilizzo proprio come te, Aruba e la cartella mdb-database con un database Access, ma ASP 3.0.
Le info le ho trovate qui
http://www.b4x.com/android/forum/th...assic-asp-iis-5-1-and-msaccess.20433/#content
Le info le ho trovate qui
http://www.b4x.com/android/forum/th...assic-asp-iis-5-1-and-msaccess.20433/#content
Grazie AlpiVir
, ma funziona anche con ASPnet o solo con ASP?
Non conosco ASPnet e quindi non so cosa dirti. Io proverei a seguire le indicazioni della soluzione proposta e poi, se ti soddisfa, trasformare il codice classic ASP in ASPnet; il codice lato B4A dovrebbe essere identico.
Confermo che a me funziona, con le caratteristiche già enunciate.
Confermo che a me funziona, con le caratteristiche già enunciate.
Anche a me interessa interfacciare l'applicazione con un db access remoto. Ho visto questo script e mi chiedo se una volta compilata l'app non sia possibile decompilarla e vedere in chiaro nome del database, userid e password, perchè in questo modo chiunque potrebbe eccedere ai dati contenuti nel database e clonare facilmente l'applicazione. O sbaglio?
Purtroppo, tutto si può decompilare.
Come sai, un minimo di protezione la ottieni compilando usando "Realease obfuscated".
Poi, considera che gli hacker più sono esperti, più tendono ad attaccare "cose" importanti (sia siti che sw).
(sto rileggendo... ma riuscite ad utilizzare Access come fosse un server db ?!?!?!... meglio che rilegga bene)
Come sai, un minimo di protezione la ottieni compilando usando "Realease obfuscated".
Poi, considera che gli hacker più sono esperti, più tendono ad attaccare "cose" importanti (sia siti che sw).
(sto rileggendo... ma riuscite ad utilizzare Access come fosse un server db ?!?!?!... meglio che rilegga bene
)
@vL4d
Direi che le preoccupazioni sono infondate in quanto dal lato B4A c'è un semplice richiamo ad una pagina ASP con i relativi parametri (del tipo http://www.nomeserver.com/pagina.asp?nome=pinco&cognome=pallino) in cui si passano alla pagina pagina.asp due valori (pinco e pallino).
UserID e password del database (oltrechè il suo nome) sono scritti nella pagina ASP e quindi protetti per definizione.
Tuttavia, ripensandoci bene, qualche danno un birichino lo può fare ugualmente, ad esempio richiamando la stessa pagina pagina.asp non attraverso l'app ma con altri mezzi e con dei parametri non desiderati dall'autore dell'app. Forse non sono stato chiaro in quest'ultimo paragrafo ma ... è meglio così.
@LucaMs
Bene compilare con la modalità suggerita ma consiglierei, prima di distribuire l'app, di verificare attentamente con un editor esadecimale, ciò che si va a pubblicare, in modo da non comunicare inavvertitamente informazioni indesiderate (valori di variabili, password, ecc).
Inoltre credo che sia sconsigliabile dare alle variabili un nome con un "underscore" (esempio Altezza_sci"); meglio usare AltezzaSci. Su quest'ultimo fatto non ho certezze.
Direi che le preoccupazioni sono infondate in quanto dal lato B4A c'è un semplice richiamo ad una pagina ASP con i relativi parametri (del tipo http://www.nomeserver.com/pagina.asp?nome=pinco&cognome=pallino) in cui si passano alla pagina pagina.asp due valori (pinco e pallino).
UserID e password del database (oltrechè il suo nome) sono scritti nella pagina ASP e quindi protetti per definizione.
Tuttavia, ripensandoci bene, qualche danno un birichino lo può fare ugualmente, ad esempio richiamando la stessa pagina pagina.asp non attraverso l'app ma con altri mezzi e con dei parametri non desiderati dall'autore dell'app. Forse non sono stato chiaro in quest'ultimo paragrafo ma ... è meglio così.
@LucaMs
Bene compilare con la modalità suggerita ma consiglierei, prima di distribuire l'app, di verificare attentamente con un editor esadecimale, ciò che si va a pubblicare, in modo da non comunicare inavvertitamente informazioni indesiderate (valori di variabili, password, ecc).
Inoltre credo che sia sconsigliabile dare alle variabili un nome con un "underscore" (esempio Altezza_sci"); meglio usare AltezzaSci. Su quest'ultimo fatto non ho certezze.
Grazie a LucaMs e AlpVir, non sapevo nè della compilazione offuscata nè del "bug" dovuto all'underscore.
Qualche anno fa ho sviluppato alcune grosse applicazioni Access che aggiorno in locale e di cui trasferisco una parte del database su diversi siti web. Successivamente ho provato a cambiare tipo di database ma servirebbero anni per riscrivere e riprogettare tutto, dalle applicazioni locali, ai db, ai siti internet. Devo dire che se hai un server veloce, non esageri con la dimensione dell'mdb, non estrai un numero eccessivo di record per pagina e chiudi correttamente la connessione, anche un db Access gestisce tranquillamente migliaia di accessi al giorno.
(sto rileggendo... ma riuscite ad utilizzare Access come fosse un server db ?!?!?!... meglio che rilegga bene
Qualche anno fa ho sviluppato alcune grosse applicazioni Access che aggiorno in locale e di cui trasferisco una parte del database su diversi siti web. Successivamente ho provato a cambiare tipo di database ma servirebbero anni per riscrivere e riprogettare tutto, dalle applicazioni locali, ai db, ai siti internet. Devo dire che se hai un server veloce, non esageri con la dimensione dell'mdb, non estrai un numero eccessivo di record per pagina e chiudi correttamente la connessione, anche un db Access gestisce tranquillamente migliaia di accessi al giorno.
A mio parere dipende soprattutto dal server, dal numero di siti ospitati e da traffico complessivo. Su server condiviso Aruba (quello da 25-30 euro, con un totale di 3-4.000 siti a bordo) 25 mb potrebbero essere un peso eccessivo, mentre su server semicondiviso e dedicato no, ma ovviamente ogni situazione fa storia a se. Se non hai problemi con 25 mb non c'è bisogno di cambiare.
Vorrei sapere come invii il nuovo database on line, io non ho trovato soluzione migliore che modificarne il nome, inviarlo sul server, modificare la stringa di connessione ed eliminare il vecchio db (tutto con uno script), perchè se lascio lo stesso nome della vecchia versione del db, IIS restituisce errori random.
Ho scritto che lavoro con MDB locali di 50 MB e 25 MB sul web ma sono 2 situazioni del tutto indipendenti, slegate.
I 50 MB sono gestititi da un programma Windows in VB6 che tratta una certa problematica (analisi mediche) e i 25 MB rappresentano uno degli archivi del mio sito www.lalpinistavirtuale.it, tutt'altra cosa. Il primo ignora l'altro e viceversa.
La tua modalità di aggiornamento del db, se pur lenta e non in tempo reale, credo che sia valida nè saprei trovarne una migliore. Gli errori lamentati potrebbero dipendere dal fatto che tu togli a IIS da sotto il naso uno dei componenenti su cui esso lavora, e lui si arrabbia.
E' la medesima problematica che si ha quando si realizza un programma che aggiorna se stesso: non si può fare. Prima bisogna chiuderlo e poi fare operazioni di delete e rename.
I 50 MB sono gestititi da un programma Windows in VB6 che tratta una certa problematica (analisi mediche) e i 25 MB rappresentano uno degli archivi del mio sito www.lalpinistavirtuale.it, tutt'altra cosa. Il primo ignora l'altro e viceversa.
La tua modalità di aggiornamento del db, se pur lenta e non in tempo reale, credo che sia valida nè saprei trovarne una migliore. Gli errori lamentati potrebbero dipendere dal fatto che tu togli a IIS da sotto il naso uno dei componenenti su cui esso lavora, e lui si arrabbia.
E' la medesima problematica che si ha quando si realizza un programma che aggiorna se stesso: non si può fare. Prima bisogna chiuderlo e poi fare operazioni di delete e rename.
Last edited:
Ciao a tutti,
dopo lungo tempo mi ricollego perchè ho un problema simile: devo collegarmi a un DB remoto MySQL, però sono in LAN e quindi posso fare le chiamate direttamente al DB senza avere nel mezzo un middleware.
E' possibile procedere in questo modo?
Grazie in anticipo
dex
dopo lungo tempo mi ricollego perchè ho un problema simile: devo collegarmi a un DB remoto MySQL, però sono in LAN e quindi posso fare le chiamate direttamente al DB senza avere nel mezzo un middleware.
E' possibile procedere in questo modo?
Grazie in anticipo
dex
Sul sito ci sono un paio di risposte utili per questo.
Connect directly Android to MySql
in cui Erel dice che non è possibile in quanto Android non dispone delle librerie adatte.
http://www.b4x.com/android/forum/threads/mysql-library.27269/page-2#post-263189
una libreria che sembra adatta allo scopo, ma sconsigliata da Erel perché la comunicazione avverrebe direttamente nel Main thread mentre secondo l'autore della libreria no.
Decidi tu, dex
Similar Threads
Italian
Mysql su Aruba
