Usare FileMaker Pro come front-end per un database SQL
Sì, ma perché dovrei?
Ricordate l’ineffabile risposta del progettista consultato da Jack Ryan in Caccia a Ottobre
Rosso, riguardo alla possibilità di utilizzare una camera di lancio orizzontale per i missili
nucleari?
Il concetto non è poi tanto distante: visto che FileMaker dispone già di un motore database
interno, perché prendersi il disturbo di usarlo come mero front-end?
I motivi sono tanti.
Uno dei più validi è che, fintantoché la fantomatica e attesissima nuova versione del database
più amato dal popolo mac non uscirà allo scoperto mostrandosi in tutto il suo splendore, lo
sviluppatore FileMaker dovrà continuare a convivere con una limitazione che molto spesso
costringe a veri e propri equilibrismi in fase di progettazione e di sviluppo: l’integrazione di
dati e struttura in un unico file.
Questo approccio, legato all’antico bacino d’utenza del programma (l’utente hobbista) oggi
appare francamente inadeguato: FileMaker Pro è uno strumento che consente di sviluppare
soluzioni che, in molti campi, possono tranquillamente competere o superare i diretti
concorrenti.
Ciononostante, il peso di questa limitazione lo si può constatare esaminando l’offerta di
software pacchettizzato: FileMaker, che come strumento di sviluppo rapido ha ben pochi rivali
e che può contare su una nutrita schiera di sviluppatori, è rappresentato da pochi, benché
validi, prodotti.
Ma che c’entra la mancanza di offerta con la struttura dei file prodotti con FileMaker?
C’entra, eccome: il mero rilascio di una versione aggiornata è un processo banale se i dati
sono distinti dalla struttura, ma diventa un’operazione piuttosto complicata quando si adotta
l’approccio di FileMaker.
In questo campo, gli sviluppatori hanno adottato soluzioni fantasiose, ardite e spesso brillanti:
esportazioni in cloni poi rinominati automaticamente, costruzioni di tabelle dedicate a
contenere i soli dati e interrogate tramite un sofisticato sistema di relazioni (un esempio
eccellente di questo sistema lo trovate su www.ecorganizer.com) e via dicendo.
In questo articolo propongo invece un approccio diverso: utilizzare FileMaker per realizzare
uno strumento di interrogazione ed immissione verso una base dati costituita da un database
SQL.
Gli strumenti
In questa circostanza, ho optato per MySQL come database, dal momento che è gratuito, si
installa con relativa facilità sotto OSX, è estremamente diffuso e sono disponibili sulla rete
moltissimi tutorial relativi al suo utilizzo.
Tuttavia, con pochi ritocchi ritengo sia possibile utilizzare i procedimenti qui indicati anche con
altri prodotti come PostgreSQL, Oracle, Informix ecc.
Come strumento di connessione, invece di affidarmi all’ODBC ho pensato di servirmi
dell’ottimo ed economico SQL Plugin di ProfData (potete scaricarne un demo funzionante a
questo indirizzo http://www.profdata.nl).
Infine, non dimenticate di installare i driver jdbc per MySQL, prelevabili gratuitamente da
internet: per funzionare con il plugin, il file .jar andrà copiato in Library/Java/Extensions.
Il progetto
Trattandosi di un esercizio, conviene non complicarsi troppo la vita. Costruiamo quindi un
semplicissimo archivio anagrafico in Filemaker (CLIENTI.FP5) dotato dei seguenti campi:
IDCliente (numero)
Ragione_Sociale (testo)
Status (globale, testo)
QuerySQL (globale, testo)
gResult (globale, testo)
Creiamo quindi una seconda tabella (INDIRIZZI.FP5) che andrà a contenere le sedi dei nostri
clienti (ricordiamoci che, se decidiamo di adottare un database SQL come base dati, dovremo
cercare di essere quanto più’ rispettosi possibile nei confronti delle regole di normalizzazione
dei dati: in questo caso, se avessimo inserito i campi relativi all’indirizzo nella tabella clienti,
avremmo potuto incontrare problemi nel caso di società con più di un indirizzo).
I campi della tabella INDIRIZZI saranno
IDIndirizzo (numero)
IDCliente (numero)
Indirizzo (testo)
CAP (numero)
Comune (testo)
Prov (testo)
gResult (globale, testo)
QuerySQL (globale, testo)
A questo punto, creiamo una relazione basata su IDCliente tra Clienti e Indirizzi, disegniamo
un portale nella maschera di immissione di Clienti e inseriamo i campi Indirizzo, CAP, Comune
e Prov.
La base dati
Ora che la struttura di Filemaker è stata impostata, creiamo un database (diciamo, Macity)
contenente due semplici tabelle in MySQL (che chiameremo, ma guarda un po’, Clienti e
Indirizzi) con i seguenti campi:
CLIENTI
ClientiID (int, primary key)
RagSoc (varchar)
INDIRIZZI
IndirID (Int, primary key)
ClientiID (int)
Indirizzo (varchar)
Comune (varchar)
RagSoc (varchar)
CAP (int)
Prov (varchar)
Metteteci dentro un po’ di dati, dopodiché tornate a FileMaker (lasciando aperto MySQL,
naturalmente).
Assicuratevi che il plugin sia attivo, controllando le preferenze dell’applicazione. Poi, come
prima cosa, andrà creato uno script che apre la connessione tra FileMaker e il back-end:
i passaggi sono:
Set Field [ Status, External("SQL-enableReporting"; 1) ]
Set Field [ Status, External("SQL-setDriver"; "org.gjt.mm.mysql.Driver") ]
If [ Status = "OK" ]
Set Field [ Status, External("SQL-setURL"; "jdbc:mysql://") ]
If [ Status = "OK" ]
Set Field [ Status, External("SQL-open";
"localhost/nomedeldatabase|nomeutente|password") ]
If [ not Status = "OK" ]
Set Field [ Status, "Error in connectstring :" & Status ]
End If
Else
Set Field [ Status, "Error in URL :" & Status ]
End If
Else
Set Field [ Status, "Error in drivername :" & Status ]
End If
Refresh Window
Se vi apparirà un rassicurante OK nel campo status potrete cominciare ad interrogare il
database; in caso contrario, c’è qualcosa che non va nelle impostazioni del plugin, del
percorso al database o dei driver jdbc.
Al lavoro
Prima di partire, un’importante precisazione: sebbene questo metodo, se ben progettato, dia
notevoli soddisfazioni, è bene sapere che FileMaker non supporta delle vere e proprie
connessioni ‘live’ con il backend: dopo un’interrogazione SQL, i dati vengono copiati (a velocità
notevolissima, a dire il vero) in FileMaker. Se, nel frattempo, un altro utente modifica i dati in
mysql, noi non ce ne accorgeremo, a meno di prevedere una serie di procedure di verifica e
sincronizzazione piuttosto sofisticate.
Detto questo, vediamo come “tirar giù” l’elenco dei nostri clienti da mysql:
Creiamo un primo script (TROVA TUTTI E ORDINA) che si occuperà di effettuare una query che
selezionerà tutti i clienti e li ordinerà:
Set Field [ QuerySQL, "SELECT * FROM Clienti ORDER BY RagSoc" ]
Set Field [ gResult, External("SQL-execQuery"; QuerySQL) ]
Ora che abbiamo disponibili tutti i nostri clienti, importiamoli in Filemaker.
SQL Plugin ci mette a disposizione numerosi strumenti per raggiungere il nostro scopo: ad es.,
potremmo creare un loop e assegnare i valori di ogni colonna ai corrispettivi campi di
Filemaker.
In questo esercizio, però, ci serviremo di una funzione che garantisce un’elevatissima velocità
di esecuzione: la creazione di un file di testo temporaneo da cui verranno importati i dati.
Lo script “Riazzera e importa tutti” sarà
Show All Records
Delete All Records
[ No dialog ]
Perform Script [ “Trova tutti e ordina” ] //è lo script illustrato sopra
[ Sub-scripts ]
Set Field [ gResult, External("SQL-exportRows"; "clienti.tab") ]
Import Records [ Filename: “clienti.tab”; [ Restore import order, No dialog ]
Go to Layout [ original layout ]
Se, per caso, le impostazioni di importazione dovessero rivelarsi errate a causa di una
mancata corrispondenza tra i campi, utilizzate il file clienti.tab per reimpostare i criteri di
importazione; dopodiché aprite lo script e salvate le nuove impostazioni.
Ora aggiungiamo un passaggio dopo IMPORT RECORDS per aumentare il livello di riservatezza
dei dati, eliminando il file di testo temporaneo. Il passaggio da aggiungere è:
Set Field [ gResult, External("SQL-deleteFile"; "clienti.tab") ]
A questo punto, lanciando lo script dovremmo ritrovarci tutti i clienti dell’omonima tabella di
MySQL nel nostro file di FileMaker.
Per finire...
E gli indirizzi?
La procedura per importare gli indirizzi è del tutto analoga (prima si crea la query con il trova
tutti, poi si importano i dati con il file temporaneo). Unica avvertenza, per aggianciarli
correttamente ai clienti correlati, dobbiamo assicurarci di importare correttamente la colonna
ClientiID nel campo IDCliente, per il resto valgono le istruzioni sopra riportate. Ecco lo script
IMPORTA INDIRIZZI:
Perform Script [ “Trova tutti indirizzi” ]
[ Sub-scripts ]
Set Field [ gResult, External("SQL-exportRows"; "indir.tab") ]
Import Records [ Filename: “indir.tab”; [ Restore import order, No dialog ]
Se l’ordine d’importazione è stato impostato correttamente, al termine dell’importazione gli
indirizzi dovranno apparire nel portale presente nell’archivio clienti.
Naturalmente, l’esempio preso in esame è estremamente basilare. Tuttavia, può aprirvi le
porte per una serie di applicazioni molto interessanti: realizzare un front-end che sfrutti la
facilità d’uso di FileMaker per interfacciarsi al database Oracle del reparto ordini, sfruttare la
velocità d’elaborazione del motore SQL per aiutare FileMaker nei calcoli che lo mettono in
difficoltà (come certi tipi di riassunto): le possibilità sono innumerevoli.
Per chi avesse voglia di cimentarsi con un esercizio più impegnativo, consiglio di realizzare un
sistema che aggiorna in MySQL i record modificati in FileMaker Pro...
Buon divertimento.
