Newsgroup: it.comp.lang.visual-basic
Titolo: Perchè XML?

Ciao a tutti,
ho cercato un po' con google su vari metodi per aggiornare i record di una
tabelle fra due database differenti.
Dato che la mia problematica è semplice allora vengono esportati i dati su
un file di testo in un formato, che poi una routine di importazione
rileggerà.
Ma come mai spesso leggo dell'uso di file XML? Quali vantaggi portano in
questo ambito? Premetto che non gli ho mai utilizzati.
Grazie
-- 
DBMS Firebird
VB6 + Ado

A< 

 ricorrere a <CDATA![]> per ovviare... e non e' bene.
L'XML ha anche un altro svantaggio: e' immensamente piu' lento da 
leggere/scrivere.

 (totale: 6 byte).
Beh bisogna che cominci a guardarmelo un po' questo formato :)
Per ora esportavo su un file delle righe con separatore.
Il primo carattere identificava il tipo di record.
Il primo rigo contiene i nomi dei campi della tabella
I righi successivi contengono i dati relativi alla tabella, già formattati
per come li vuole il DB.
A|IDTABELLA|DESCRIZIONE
B|'1'|'Rigo Numero 1'
B|'2'|'Rigo Numero 2'


 Il sistema e' poi estremamente rigoroso e, teoricamente, a prova di errore.
Ad esempio, con un Recordset ADO puoi realizzare il file XML in un 
unico passaggio, e puoi poi ripristinare il Recordset da XML in un 
unico passaggio.
Se i dati vengono passati su file, immagino ci sia una qualche 
procedura che preleva i dati da un db (e quindi ottiene un Recordset), 
poi scrive il file (e con XML è un'istruzione), poi un'altra procedura 
carica il file in un recordset (e da XML a ADO è un'istruzione), e poi 
in qualche modo ciclerà su questi dati per fare, che so, Insert/Update 
su un altro db.
Ciao
Nikkei

 Premetto che non gli ho mai utilizzati.
Io pochissimo, ma tutto ciň che si puň fare con l'xml nel 99% dei casi lo si 
piů fare con altri sistemi in modo piů efficiente.
E' un casino da leggere e scrivere, non č uno standard (solo la sintassi č 
standard) quindi ognuno si inventa la sua struttura.
Ciao 

A< 

 questo non puo' accadere.
Sė, pių o meno.
Ciao 

 su un altro db.
Esatto.
Da filtro messo dall'utente esce un recordset.
Da recorset scrivo un file prima i nomi dei campi e poi i dati.
In ricezione
Leggo il file e da qui so la tabella ed i nomi dei campi.
Mi costruisco le INSERT (in questo caso non ci sono Update)
Dovrò vedermelo questo XML :)


 Leggo il file e da qui so la tabella ed i nomi dei campi.
Recordset2.Open "c:\pippo.xml", "Provider=MSPersist"
Ciao
Alberto
-- 
seguiam la scia
se un meganoide ci spia

 Recordset2.Open "c:\pippo.xml", "Provider=MSPersist"
Resta il "problema" di costruirsi le Insert da buttare sulla tabella.
Cioè ciclarlo tutto, a seconda di RecSet.Type formattare i dati (uno si
crea una function) e poi costruirsi la insert.
Non credo si possa (o sia consigliabile) riagganciarlo direttamente ad una
tabella.
Tnx


 tabella.
mmm... perchč no?
Io proverei.
Ciao 

 tabella.
Non credo si possa, e se si potesse comunque non mi fiderei.


 Non credo si possa, e se si potesse comunque non mi fiderei.
Nemmeno io infatti :)


 Le insert le fai con i parametri cosě non devi nemmeno controllare niente.
Parli di StoredProcedure? O Command con parametri?
Il problema č che in quel modo se aggiungo un campo alla tabella devo
modificare il programma, per come ho fatto io non ce n'č bisogno almeno che
non ci sia una gestione particolare.
O per farglielo fare dovrei mettere mano pesantemente al funzionamento
interno :)


 interno :)
ma vaaaaa :)
sarà bella la via del select case sul tipo...
Ciao 

 tabella.
E' previsto, si puo' ed e' consigliabile visto che, gia' che sei li' che 
lavori con record persistenti, tanto vale tu continui ad usarli fino in 
fondo: in questo caso UpdateBatch e' tuo amico.
Ovviamente fai prima qualche prova, io l'usato tantissimo anni fa e non 
ricordo piu' esattamente tutti comportamenti del comando. (se non ricordo 
male aggiunge i record nuovi e quelli gia' esistenti li aggiorna, pari pari 
come fa di solito. Ma potrei anche ricordare male.)

 E' previsto, si puo'
Sul consigliabile non discutiamo, perchè andremmo incontro a prese di 
posizione estreme.
Ma che si potesse, non lo sapevo e mi potrebbe (non si sa mai) 
interessare.
Come si fa ad agganciare ad una tabella di un db un recordset che 
deriva da tutt'altra origine, ed arrivare anche ad aggiornare la 
stessa?


 da tutt'altra origine, ed arrivare anche ad aggiornare la stessa?
Crea il recordset.
Riempilo.
Aggancialo.
UpdateBatch.
Poi, oh, se peschi un recordset dalla tabella Auto e cerchi di riattaccarlo 
alla tabella Mattonelle...ADO fa quello che puo', ma non arriva a tanto :-D

 UpdateBatch.
Si, ecco.
Diciamo che ciò di cui si parlava era appunto questo.
Scrivo un po' di pseudocodice:
Dim RS as Adodb.recordset
Set RS = New Adodb.recordset
RS.Open "c:\pippo.xml", "Provider=MSPersist"
RS.MoveFirst
RS.Fields.Item("Cognome").Value="Rossi"
*<agganciare il recordset ad una tabella>*
RS.UpdateBatch
potresti, per cortesia, scrivermi un minimo di codice o pseudotale, 
sulla parte mancante del mio pseudocodice?
Poi proseguo io la messa a punto, ma giusto per partire...
Ciao


 Poi proseguo io la messa a punto, ma giusto per partire...
Spetta, credo che ci siamo "non capiti" sulla parte essenziale: stiamo 
parlando di portare in giro un recordset preso dalla tabella X su un db e 
poi trasferirlo sulla tabella X su un qualsiasi altro DB, con la tabella che 
ha la stessa identica struttura e nome!
E' implicito nell'ADO (e anche nel DAO o chi per lui), il limite di 
funzionamento: apri il recordset dalla tabella X e lo puoi rimettere SOLO 
nella tabella X. Non puoi fare
rec.open "Select * from Auto"
rec.TabellaACuiPuntare = "Auto2"
rec.update.
Ovvio, no?
Per cui, per
*<agganciare il recordset ad una tabella>*
Devi semplicemente agganciarlo al DB dove si trova la tabella:
RS.ActiveConnection = objConn
Pari pari come un recordset disconnesso. Quando lo riconnetti mica gli dici 
dov'e' la tabella, no?

 dov'e' la tabella, no?
No, certo, perchè è un recordset che deriva da una tabella, quindi sa 
esattamente dove trovarla (e prima di aprirlo gli ho anche detto, 
impostandone i vari cursorlocation, cursortype e locktype, di 
predisporre le strutture per il successivo riallineamento).
Ma se il recordset non deriva da una tabella, ma da chissà cos'altro, 
come fa a conoscere l'ID del db e della tabella?
Perchè a te viene visualizzato il nome della tabella, ma internamente 
ADO utilizza gli UniqueIdentifier del db e della tabella, e questi UID 
non consentono di riattaccarsi da un db ad un altro in modo 
'trasparente'.
Ad esempio:
Se tu crei un recordset ricavando i dati dalla tabella X, poi 
disconnetti il recordset, poi da un altro applicativo fai un Drop della 
tabella ed un Create *identica*, ma proprio *identica*, non credo mica 
che poi tu riesca a 'riagganciarlo'. Men che meno se il Rs arriva da un 
db e tu lo vuoi attaccare ad un altro.
Potrei anche sbagliarmi, ma prima di ricredermi ti chiedo: sono cose 
che hai provato, o idee tue?


 sarà bella la via del select case sul tipo...
Bhe in quel modo è tutto automatico, e poi volendo non c'è bisogno che
sfrutti l'adors.type ma posso leggere direttamente dalle tabelle di sistema
del database (e quelle non possono sbagliare).
Imho o uno automatizza tenendo meno sotto controllo, oppure uno fa tutto a
mano campo campo, ma se la manutenzione è poca ok, se ogni tanto si
cambiano i campi si impazzisce.


 hai provato, o idee tue?
Gia' scritto sopra, roba usata almeno 6 anni fa. Da una parte per aggiornare 
i db di alcune sedi rispetto al db principale, dall'altra per un esperimento 
di edit db via vb6 ed internet (un precedessore dell'attuale MS Remote, solo 
che il mio zippava i contenuti prima di mandarli in giro...fighissimo ;-D )
P.S.: ho gia' chiesto, ma ho sbagliato giorno e non m'ha risposto nessuno; 
come mi sostituisco a Explorer con la mia shell, su Win2k? Hai qualche link?

 attaccare ad un altro.
Sě, puoi.
Anzi, potrsti tirare su i dati da un db access e scriverli su un db 
sqlserver.
Il problema č che se non sbaglio vengono scritte solo le righe che risultano 
modificate o aggiunte (esattamente come fa .Net, solo che lui permette di 
modificare il RowState), quindi la domanda č: come risultano le righe del 
recordset anche dopo la lettura dell'xml?
Ciao 

 e poi diventano 21 perchè c'è un campo in più, no?
E le tua INSERT INTO no?
Come fai a modificarla se aggiungi un campo?
(ovviamente è una domanda retorica)
Ciao 

 come mi sostituisco a Explorer con la mia shell, su Win2k? Hai qualche link?
Adesso sono io che ti dico che l'ho fatto, qualche anno fa, ma non 
ricordo minimamente come.
Ricordo solo che era una cazzata, roba tipo una chiave di registry o 
giù di lì, ma proprio non mi sovviene...
Aspetta che guardo nella mia kb...
Nada.
Vediamo on-line....
Nada (cioè, ho trovato troppa roba, che a spulciarla ci metto un 
mese...).
Ciao


 (ovviamente è una domanda retorica)
Hai ragione, quella si automodifica.
Mi viene in mente di avere solo 2 parametri per la command:
INSERT INTO tabella (<paramcampi>) VALUES (<paramvalues>)
In questo modo è indipendente dalle modifiche alla tabella.
Non so se funzioni, mai usato command con parametri
