Newsgroup: it.comp.lang.visual-basic
Titolo: Database OnLine

vorrei creare un database che possa essere aggiornato online.
premetto che nn possiedo uno spazio asp.
posso solamente accedere allo spazio via ftp in scrittura (immettendo
password e username).
sto cercando di scrivere (o se già qualcuno l'ha pronta è meglio... :-P )
una parte di codice che possa accedere via ftp al database e lo aggiorni.
una soluzione estrema ma non ottimale sarebbe quella di sostituire per
intero il database in quanto l'opearzione verrebbe eseguita solo un paio di
volte al giorno.
premetto inoltre che il database è di dimensioni estremamante ridotte (non
più di 50kB) ed è in formato Access.
Grazie x chiunque voglia aiutarmi.

 più di 50kB) ed è in formato Access.
? Io quando ne creo uno nuovo le dimensioni sono di 64k (Access2000) :)
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 ha scritto nel messaggio
news:Q9Fmb.4297$gA....@tornado.fastwebnet.it...

Soluzione ultima, in quanto l'opearzione verrebbe eseguita solo un paio di
volte al giorno.
Un file xml ?
Lo invii by posta elettronica,
il ricevente lo depone in una cartella
Apre l'applicazione, clic sopra il pulsante e i dati presenti nel file.xml
vengono inseriti nella tabella del db
Ave
giuseppeD

 ha scritto nel messaggio
news:KUMmb.353825$R32.11...@news2.tin.it...


 ftp.
Ad oggi non mi è capitato un'esigenza del genere, eseguito con ASP o 
ASP.NET
A meno di utilizzare uno script locale, ma i valori per eseguire la query
come li legge lo script ? Boh
Come li visualizzi a video ?
Prova anche con
it.comp.appl.access
Ave
giuseppeD

 file via ftp.
Via ftp e senza ASP non saprei proprio, ma io ho fatto così:
Prevedo su un server "comune" un archivio (Access) con tutti gli articoli
distinti per deposito/sede e, per ogni combinazione, il codice
dell'articolo, del deposito e le varie qtà. In tempo reale o in batch il
sistena, per ogni singolo movimento, agisce sugli archivi locali e _anche_
(con ASP+ADO) su quelli comuni remoti. In tal modo ho sempre (se ho
effettuato l'aggiornamento se questo non è previsto in tempo reale) la
possibilità di vedere tutto di ogni articolo: dati da archivi locali
(aggiornati in tempo reale), dati da archivi remoti (all'ultimo
aggiornamento, reale o batch), per uno o più depositi.


La tua soluzione non è male però vorrei che l'archivio sia residente solo in
locale.
Il server vorrei utilizzarlo solo per salvare gli indirizzi ip.
Un motivo è la sicurezza dei dati (che però possono essere crittati).
Un altro motivo (ed è il più importante) è che se un articolo viene venduto
in una sede ma in quel momento questa non è collegata ad internet, il
database comune non sarà aggiornato, con tutti i problemi che ne conseguono.

 problemi che ne conseguono.
Certo, ma se anche tu ipotizzavi che "1-le sedi si connetono ogni mattina ad
internet e si disconnettono la sera", che accade se la connessione cade
mentre gli operatori stanno lavorando? Succede che gli archivi locali di
quella sede si aggiornano, ma non quelli sul tuo server (anche fosse una
macchina locale in un deposito). E' un problema che dovrai comunque
prevedere e risolvere, magari, se lo si ritiene eccezionale, con una routine
di azzeramento e riaggiornamento completo...
In aggiunta a quel che dicevo, potrei suggerirti anche questo (ipotizzando
una connessione always-on, ma valido, se leggi fra le righe, anche per un
aggiornamento batch):
Il movimento registrato dall'applicativo lavora istantaneamente sugli
archivi locali, ma non immediatamente su quelli remoti. Deposita cioè una
riga su un database "di log" (anch'esso locale) che contiene tutte le
informazioni necessarie e un segnale di "aggiornato" posto a False. Una
routine (che può partire subito oppure a intervalli regolari o, ancora,
esplicitamente da parte dell'operatore per aggiornamenti batch) analizza
solo il database "di log" e solo le righe non aggiornate e avvia, per ogni
riga non già aggiornata, l'aggiornamento della stessa. Se questo va a buon
fine segna la riga come aggiornata, viceversa la riprenderà in
considerazione la volta successiva.

 ha scritto nel messaggio
news:bnggms$1084gr$1...@ID-174464.news.uni-berlin.de...


 un pò fastidioso, non credi?
Sì, ma tu potresti esporre un messaggio che dice "C'è stato il blackout, un
operatore è inciampato sui cavi di rete mentre guardava una scodinzolante
collega, la tributaria sta bussando alla porta e tutti scappano anche dalle
finestre, l'uragano ha sradicato la sede, un topolino ha fatto pipì
sull'alimentatore del server, oppure quelli là hanno la sagra e non hanno
appicciato nulla. Mi spiace, ma quell'articolo è così." ;-)
Nicola, tutto può accadere (e secondo la legge du Murphy sicuramente
accadrà).
Ora una fatto: Se il deposito A ha venduto l'articolo e aggiornato sul
server, il deposito B vedrà la nuova disponibilità. Bene, ma dimmi, qual è
la differenza sostanziale fra non aver aggiornato in tempo reale e il fatto
che l'operatore del deposito A esegua la registrazione dopo un tranquillo
caffè? Capitomihai?

 ha scritto nel messaggio
news:bnghvh$10k4sm$1...@ID-174464.news.uni-berlin.de...



Scusa non puoi utilizzare delle e-mail?
per mandare questi messaggi e aprirle?
                        danilo

 ha scritto nel messaggio
news:jsPmb.4738$gA....@tornado.fastwebnet.it...


 ha scritto nel messaggio
news:coZmb.70009$e6.25...@twister2.libero.it...
