BASE DI DATI SEPARATA DA FILEMAKER
Moderatore: Moderatori
-
sierrapapa
- Messaggi: 114
- Iscritto il: sabato 8 maggio 2004, 2:00
- Località: PISTOIA
BASE DI DATI SEPARATA DA FILEMAKER
Approfitto dell'estremo spirito di collaborazione di cui ho appurato la presenza nella grande famiglia dei cultori di FM per sottoporre (all'anima gentile che vorrà aiutarmi) un nuovo problema.
A differenza di molti, sviluppo le mie applicazioni per un utilizzo orizzontale (uno per molti) ed uno dei problemi che mi si pone è quello degli aggiornamenti dei miei programmi. In pratica debbo creare dei file di testo di aiuto ed una serie di pulsanti che consentono agli utenti, non sempre dei mostri in materia, di trasferire i dati dalle vecchie versioni agli aggiornamenti.
Non è possibile, in qualche modo, separare i dati dal programma? Chiaramente le mie soluzioni vengono utilizzate con i runtime di FM developer. Ho sentito parlare di base di dati MYSQL ma non so, pur avendo scaricato il programma, da che parte rifarmi. AIUTO. Grazie. 8O
-
stregatto
- Messaggi: 9700
- Iscritto il: lunedì 1 dicembre 2003, 1:00
- Località: Roma
- Contatta:
benvenuto nel club. questa è una delle grandi questioni di FM.
per iniziare: Ha senso usare Fm come front-end di un DB SQL nel caso di rete e multiutenza, in quanto si evita l'acquisto di n licenze FM (basta un runtime per postazione) e le prestazioni e soprattutto la FLESSIBILITA di uso di mySQL sono superiori a quelle di FMserver.
Comunque, per usare Fm in relazione a SQL è necessaria una conoscenza della sintassi (esclusivamente testuale) di quest'ultimo ed un plug-in di interfaccia (che aveva il suo costo e di cui non ricordo il nome. una ricerca su google e ci sei). Anche perché è una complicazione: tu avresti DUE programmi (FM e SQL) in esecuzione sulla macchina al posto di uno… con (secondo me) uno scadimento delle prestazioni.
Detto questo, se progetti applicativi da usare in monopostazione (e solo partendo dalla versione 7 in su), l'unica possibilità che vedo è creare un file FM DATI separato dal file Interfaccia, che visualizzerà nei suoi formati i valori delle relative tabelle di DATI.
Il problema è che finchè effettui moficiche grafiche a livello di interfaccia, non hai problemi, ma se aggiungi campi, tabelle o scritp devi in ogni caso aggiornare il relativo file dati.
Una delle possibilità è creare un campo VERSIONE e inserire uno scrip
t iniziale che dica qualcosa come:
if(DATI::versione < xx)
fai questo, questo e questo,
else if (DATI::versione < zz)
fai questo e questo
else
fai solo questo.
end if
il problema è che - almeno così mi pare - non esiste la possibilità di creare tabelle e campi via script, quindi IN OGNI CASO dovresti aggiornare anche i dati.
la seconda possbilità è quella di creare uno script nel nuovo file che funzioni più o meno:
localizzare il file precedente
memorizzarne il percorso relativo in una variabile
importa tabella 1
importa tabella 2
…
importa tabella ultima
inconvenienti di questa soluzione sono
a) la lentezza (se io ho - putacaso - 100 tabelle con campi indicizzati con qualche milione di record in totale, ci mette una giornata) e
b) il atto che le modifiche degli utenti alle liste valori e alle password (a meno che tu non usi un metodo di archiviazione nello stesso file) vanno a farsi benedire.
se qualcuno trovasse qualche pecca nel ragionamento o avesse una soluzione diversa, parliamone… magari troviamo il bandolo della matassa.
.g.
per iniziare: Ha senso usare Fm come front-end di un DB SQL nel caso di rete e multiutenza, in quanto si evita l'acquisto di n licenze FM (basta un runtime per postazione) e le prestazioni e soprattutto la FLESSIBILITA di uso di mySQL sono superiori a quelle di FMserver.
Comunque, per usare Fm in relazione a SQL è necessaria una conoscenza della sintassi (esclusivamente testuale) di quest'ultimo ed un plug-in di interfaccia (che aveva il suo costo e di cui non ricordo il nome. una ricerca su google e ci sei). Anche perché è una complicazione: tu avresti DUE programmi (FM e SQL) in esecuzione sulla macchina al posto di uno… con (secondo me) uno scadimento delle prestazioni.
Detto questo, se progetti applicativi da usare in monopostazione (e solo partendo dalla versione 7 in su), l'unica possibilità che vedo è creare un file FM DATI separato dal file Interfaccia, che visualizzerà nei suoi formati i valori delle relative tabelle di DATI.
Il problema è che finchè effettui moficiche grafiche a livello di interfaccia, non hai problemi, ma se aggiungi campi, tabelle o scritp devi in ogni caso aggiornare il relativo file dati.
Una delle possibilità è creare un campo VERSIONE e inserire uno scrip
t iniziale che dica qualcosa come:
if(DATI::versione < xx)
fai questo, questo e questo,
else if (DATI::versione < zz)
fai questo e questo
else
fai solo questo.
end if
il problema è che - almeno così mi pare - non esiste la possibilità di creare tabelle e campi via script, quindi IN OGNI CASO dovresti aggiornare anche i dati.
la seconda possbilità è quella di creare uno script nel nuovo file che funzioni più o meno:
localizzare il file precedente
memorizzarne il percorso relativo in una variabile
importa tabella 1
importa tabella 2
…
importa tabella ultima
inconvenienti di questa soluzione sono
a) la lentezza (se io ho - putacaso - 100 tabelle con campi indicizzati con qualche milione di record in totale, ci mette una giornata) e
b) il atto che le modifiche degli utenti alle liste valori e alle password (a meno che tu non usi un metodo di archiviazione nello stesso file) vanno a farsi benedire.
se qualcuno trovasse qualche pecca nel ragionamento o avesse una soluzione diversa, parliamone… magari troviamo il bandolo della matassa.
.g.