Newsgroup: it.comp.lang.visual-basic
Titolo: campi blob

Qualcuno ha mai provato a fare una insert (o update) in un campo Blob di un
database Oracle con VB??
Grazie e ciao!

database Oracle con VB??
Yes!
-- 
ciao, hal
ma cos'e', un sondaggio?

 Grazie e ciao!
Prego!
ciao anche a te...   ;-P
ciao
ugo
p.s.
Se ne č parlato un paio di volte:
http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&safe=off&q=blob+orac
le+hal&meta=group%3Dit.comp.lang.visual-basic


comq, se dai retta a "zio", ti tieni i documenti dove stanno, cioč
sul database fornito dal file system del sistema operativo, e nel
database oracle (o qualunque altro) ci tieni solo i link...
ciao
ugo

database oracle (o qualunque altro) ci tieni solo i link...
Mi sento di dissentire :-PPP
Talvolta puo' essere _molto_ meglio inserire i file nel db
perche' cosi' si evita di dover gestire accessi inutili
e potenzialmente dannosi al filesystem (dato che, se si sta
usando oracle, i documenti in questione saranno su qualche server).
-- 
ciao, hal.setSecurity(HIGH);

 ha scritto nel messaggio
news:vi35sucto0v4k5of2...@4ax.com...

salve,
e poi vai contro i principi classici di Oracle che al posto di UDA (unified
data access o simili) metterebbe tutto dentro il DB, magari l'OS stesso =;-)
premetto che comunque sono piu' vicino alla filosofia Ms e UDA mi sta bene e
che solitamente uso il principio di Ugo, ma solitamente la gestione dei file
cosi' esterni la valuto di volta in volta... e talvolta il metodo di Hal
vince..
saluti
Andrea Montanari
montanar...@virgilio.it
http://utenti.lycos.it/asql/index.html
(my vb6+sql-dmo little try to provide MS MSDE 1.0 a visual interface) ver
0.0.46
--------- remove DMO to reply

cosi' esterni la valuto di volta in volta... 
Ovviamente ci sono casi e casi, su questo non c'e' dubbio.
-- 
ciao, hal

 dimostrazione :-)
Avete già detto tutto voi!
Ovviamente c'è caso e caso, ma la filosofia del "tutto nel db" proprio non
mi va giù.
ciao
ugo

mi va giù.
Non e' questione di filosofia, ma imho di praticita'
e sicurezza (specie se si tratta di documenti importanti
e non di immaginine decorative dell' applicazione).
Se lasciare i file fuori dal db significa dover gestire
delle share aggiuntive (e relativi permessi) puo' essere
molto piu' conveniente far gestire tutto al db, soprattutto
se si parla di veri db client-server.
In questo modo si possono acquisire documenti forniti
dall' utente e/o consentirgli la visualizzazione e/o
la modifica nello stesso modo di come si faccia
con gli altri tipi di dato.
Non si scomoda l' amministratore di rete e si gestisce
la sicurezza di tali informazioni a livello di database
(non dimentichiamo che stiamo parlando di quello che
e', imho, il miglior database, per lo meno in ambiente
Windows).
Se il di db e' basato su file (come Microsoft Access), e'
ovvio che chi accede a tale database abbia comunque gia'
diritti di lettura e forse anche di scrittura sulla
share. In questo caso puo' avere piu' senso memorizzare 
il percorso del documento piuttosto che il documento 
stesso.
Sempre che non arrivi qualcun altro a modificare, spostare, 
rinominare o cancellare il documento salvato all' esterno.
-- 
ciao, hal

 rinominare o cancellare il documento salvato all' esterno.
Appunto:
Nella stragrande maggioranza dei casi, la disponibilità dei documenti
è slegata dal-dai-dalle procedure gestionali disponibili in azienda:
le share generalmente già ci sono e la distribuzione dei documenti
è già regolamentata da procedure aziendali.
Il database "gestionale" generalmente deve fornire solo il link
alle informazioni, distribuite/distribuibili anche attraverso logiche
diverse.
Diverso il caso di un applicativo dedicato alla gestione e archiviazione
documentale, diverso il caso di un applicativo nato "in azienda" e a
"misura d'azienda", diverso il caso della strutturazione ex-novo delle
procedure (_tutte_) di gestione e condivisione delle informazioni, diverso
ancora il caso di un'azienda dotata di intranet basata su web services...
etc
ma, appunto, diverso da caso a caso:
non ne farei una regola e, se proprio devo farla, preferisco la regola
dei "dati nel database e documenti nel filesys"...
... ma è "filosofia"...
ciao
ugo

 ... ma è "filosofia"...
concordo.
da caso a caso.
anche solo per un piccolo motivo, di cui si parlava sul ng in questi
giorni:
BACKUP
io devo/dovro' linkare fra le 10k e le 500k immagini entro breve,
ognuna dai 50 agli 800k.
faccio il bkp di un db da 15-30 gb (ottimizzando e comprimendo e e
blobbando il possibile), quando i dati reali sarebbero 500-5000k ?
non so da voi, da me a passare 30gb da disco a disco inginocchio i
server e ci mette pure un bel po'...
ciao, j.