Insert file e continuo aumento di dimensioni del database

Ciao,

ho risolto mettendo un timer di un paio di secondi sullo script step che importa il file ”mobile” aggiornato nel campo container del file ”centrale”.

Ora i 2 files (quello salvato nel file system e quello importato come external storage) sono uguali ed entrambi vuoti.

Il motivo continua ad essere per me un mistero, comunque…

Saluti.

premesso che se dovessi scegliere io probabilmente penserei a un aggiornamento dati via xml, proviamo a simulare un esercizio per cui serve un file FM.

secondo me ti serve:
corpo centrale:
– file originale
– un file in locale da inviare ai dispositivi remoti
– una procedura automatizzata che importi i dati nel file
– una procedura che crei una copia del file nel formato più adatto alla migrazione e lo inserisca nel posto giusto
client:
un file  start che si connetta al server e verifichi gli aggiornamenti. A questo punto ci sono due casi:
– non ci sono aggiornamenti: apre il file locale
– ci sono aggiornamenti: scarica l’aggiornamento (magari in formato b64), lo convalida, elimina il file vecchio, salva e apre il file nuovo.

.g.

Ciao,

innanzitutto ti ringrazio per la risposta.

L’obiettivo che vorrei raggiungere é – credo – quello che tu scrivi nella seconda parte del messaggio, ovvero mettere a punto una procedura per la sostituzione del file iOS ”vecchio” il più possibile ”automatizzata” (senza interazione da parte degli utenti, ovvero niente iTunes, allegati mail ecc…). Con la differenza che, al posto di utilizzare un file di solo aggiornamento, lo vorrei fare utilizzando il file centrale, che é già aperto. Così ho un file in meno da gestire (aprire, chiudere, aggiornare ecc…).

Avrei anche raggiunto il risultato che volevo, se non fosse per quel problema di differenza dei 2 files (quello nel file system e quello nel campo container) di cui scrivevo nell’ultimo messaggio e che non riesco a capire… che ne pensi ?

Saluti.

certo, se lo salvi come external storage non hai problemi di crescita db, anche se poi qualche rogna su iOS ce la puoi avere (il riferimento rimane). Tuttavia, continuo a essere del parere che secondo me è proprio il metodo che non può evolversi oltre un certo limite: puoi inventarti tutte le macumbe che vuoi, ma comunque prima o poi troverai un muro di mattoni che ti blocca e dovrai cambiare metodo radicalmente.
Se vuoi mantenere questo approccio allora è più semplice avere una versione in locale che aggiorni via script e che mandi in giro, o con download manuale o con un file di solo aggiornamento su iOS che si occupa del download e della sostituzione del file vecchio con il nuovo.

.g.

Sorry, per qualche motivo non mi ha preso l’elenco numerato … era:

1) ”Save copy as”

2) ”Open URL”

3) ”OnFirstWindowOpen”

4) ”Insert File”

Addirittura iOS 1… beh, il ”vintage” ritorna sempre di moda, prima o poi…  

Nel frattempo ho ”forse” fatto un passo avanti: se imposto il campo container come ”External storage” e in ”Insert File” uso l’opzione ”Insert” (non ”Reference”), l’esportazione su iOS riesce -> OK

Ho però il seguente problema, di cui non riesco a capire la causa.

I passi principali che compio nell’ordine sono:

1. ”Save copy as” del file centrale
2. ”Open URL” del file salvato
3. trigger ”OnFirstWindowOpen” -> lo script cancella i dati, imposta il flag di cancellazione avvenuta e chiude il file
4. ”Insert File” nel campo container (External storage)

Il problema é il seguente: se al termine della procedura apro il file salvato al il punto (1), vedo che i records sono cancellati ed il flag di cancellazione é settato correttamente.

Se invece apro il file inserito al punto (4) nel campo container (che é quello salvato al punto 1 e ’svuotato’ al punto (3) …), vedo che i records non sono cancellati ed il flag di cancellazione non é impostato.

Ho pensato ci fosse una specie di ritardo tra la scrittura del file nel file system e l’aggiornamento per l’inserimento nel campo container, dunque ho provato ad inserire uno step ”Pause/resume script” di 2 secondi tra i punti (1) e (4) ma il risultato che ottengo é esattamente l’opposto (in questo caso anche nel file salvato al punto (1) i records che prima risultano cancellati adesso sono ancora presenti…).

Hai qualche idea sul possibile motivo di questo per me incomprensibile comportamento ?

Ti ringrazio.

oltretutto, finché sono pochi dati/tabelle ok. ma se la complessità cresce, diventa sempre più difficile da gestire, mentre un approccio di aggiornamento dati è ipso facto scalabile, se impostato con intelligenza (Magari usando un approccio web-service-like)

.g.

beh, non è il massimo dell’efficienza, secondo me. e preclude qualunque tipo di approccio ”sincronizzato”… un pò iOs 1

Beh la domanda é pertinente, diciamo che l’idea era di gestire con un unico sistema entrambe le casistiche (ovvero sia la modifica di dati che eventuali future modifiche della struttura del db).

Mi sembrava peraltro più semplice mantenere il processo di scambio dati ”monodirezionale” senza dovermi imbarcare nella necessità di tener traccia di tutto ciò che é stato aggiunto e/o modificato… sbaglio ?

mah. diciamo che se con cambia la struttura ma solo i dati io creerei un procedura di download da parte dei dispositivi mobili via xml o al limite farei esportare al server una versione su un repository (tipo dropbox) che i device mobili possano scaricare.nel senso: se comunque il mobile si connette che senso ha fare scaricare tutto e non solo i dati che servono?

.g.

Ciao,

in poche parole:

– quando nel file centrale vengono aggiunti dei records di ”configurazione” (es: nuovi clienti o incarichi) parte un trigger che segnala che il database é stato aggiornato (impostando un flag) e genera una nuova versione del file mobile

-quando il file remoto si collega al centrale per l’update dei dati acquisiti, vede il flag e scarica la versione aggiornata del file mobile (o meglio: il file centrale ”pusha” sul file mobile l’aggiornamento

Grazie per l’interessamento e se hai bisogno di altre info chiedi pure.

Buonasera, Marco.

giusto per capire, ma qual’è lo scopo del tutto?

.g.