Capita però che la mia applicazione inspiegabilmente *distrugge* il
contenuto del database dopo 5 o 6 volte che gira.
cioè io faccio il run, va bene 5 o 6 volte e poi, zac ! tutti i dati
sono spariti. Cioè il ocntenuto del database, non il file.
Eppure il programma NON FA NIENTE : volevo solamente testare i tools
messi a disposizione di VB .NET per 'linkare' le varie voci delle
tabelle alla GUI : quindi NON C'È CODICE SCRITTO DA ME. Solo quello
generato automaticamente dal compilatore. Uso il .NET 4.0
Ora, dato che un problema simile esula dal puro e semplice linguaggio di
programmazione usato (magari in C# è la stessa cosa), la mia domanda è :
si puo' rischiare di lavorare professionalmente in un ambiente simile ??
Cosa mi succede se dopo che il programma è operazionale, quello mi
distrugge tutti i dati di un ospedale ??
La questione è troppo seria e vorrei risolverla.
Dato che la mia poca pazienza e tolleranza è universalmente nota, io
propenderei per dimenticare totalmente il Framework .NET e Access.
(AL momento il file .mdb contiene i dati di 4700 pazienti di una clinica
unbiversitaria).
Per il futuro io direi di cambiare piattaforma. magari usando Oracle.
Alla piattaforma non ci ho ancora pensato.
Ho ragione o sono troppo radicale ?
Grazie dei feedback.
Se non è una trollata, hai fatto benissimo a domandare.
Non usare Access in quell'ambiente.
Usa un qualche db che abbia opzioni high availability, ove sia
possibile sia ridondanza che failover, possibilmente automatica (scusa
l'Inglese, ma non ricordo i termini in Italiano, se esistono). Ne
esistono sia proprietari che open.
> Eppure il programma NON FA NIENTE : volevo solamente testare i tools
> messi a disposizione di VB .NET per 'linkare' le varie voci delle
> tabelle alla GUI : quindi NON C'È CODICE SCRITTO DA ME. Solo quello
> generato automaticamente dal compilatore. Uso il .NET 4.0
Chissa' che minchiata c'e', nel programma...
--
Ciao!
Luca
>
> Non usare Access in quell'ambiente.
>
Il fatto è che Access e l'ambiente Windows sono ancora molto diffusi in
ambito ospedaliero.
Preciso: non usare Access come database principale di un ospedale
(i.e. per tenerci i dati di 4700 pazienti). Puoi usare Access (ma
perchè?) per fare elaborazioni, reportistica, POS, ..., ma i dati
vanno tenuti da qualche altra parte (glieli puoi fare arrivare tramite
ETL, link read only, ...).
>
> Preciso: non usare Access come database principale di un ospedale
> (i.e. per tenerci i dati di 4700 pazienti). Puoi usare Access (ma
> perch�?) per fare elaborazioni, reportistica, POS, ..., ma i dati
> vanno tenuti da qualche altra parte (glieli puoi fare arrivare tramite
> ETL, link read only, ...).
>
proprio quello sto facendo (una tesi). Eppure il problema io lo vedo
cos� grave che a me sembra determinante per decidere SI/NO per un
ambiente di sviluppo.
Non � possibile, dico io, mettersi a 'smanettare' SOLAMENTE con i tools
messi a disposizione dall'environment, senza aggiungere codice proprio,
(per test ovviamente) ed avere un prodotto che ti distrugge il contenuto
di un database.
Non esiste proprio.
Ciao.
John.
Provare per credere.
1) crei un database 'PIPPO.mdb' con Access, con una Tabella 'Anagrafica'
in cui tu metti quattro colonne :
ID_paziente
Cognome
Nome
Codice Fiscale.
2) riempi la tabella con contenuto a caso, battendo sulla tastiera
Metti quatro righe.
2) Crea una GUI così fatta :
- quattro TextBox (ID Paziente, Cognome, Nome, Codice Fiscale)
- Un dataGridView
3) sulle proprietà del Textbox clicca 'Binding' e allaccia ogni Textbox
con la corrispondente colonna della tabella Anagrafica (Cognome, nome, etc.)
4) la IDE avrà generato di suo un AnagraficaBindingSource.
5) Adesso linka il dataGridView con la stessa sorgente, specificando in
'DataSource' la AnagraficaBindingSource creata dal sistema.
Fai girare il programma.
Per 5 o 6 volte appaiono i dati correttamente. Poi al prossimo run tutto
é sparito. Cioé anche accedendo al database con Access si nota che IL
CONTENUTO E' STATO DISTRUTTO.
Anche se io avessi fatto delle minchiate, (senzaltro possibile, le
minchiate le facciamo tutti, a turno) un Developing Environment NON PUO'
PERMETTERSI di generar ca§§ate di questo tipo, considerando anche che la
stragrande maggioranza che usa quell'environment non sono esperti ma
beginners o 'mezzi-esperti'.
Questo ad un Developing Environment non glielo concedo. Mi dispiace.
Un Environment deve essere FOOL PROOF.
E apparentemente la combinazione VB .NET + Access NON LO E'.
Forse sbaglio in questo mio giudizio drastico, ed è per questo che lo
propongo qui.
(Sono proprio curioso, alla fine, di vedere qual'è la causa di un simile
comportamento).
John.
risposta lunga: se il database viene azzerato non e' "colpa di
access", e' sicuramente qualcosa di sbagliato che hai fatto tu.. ma
comunque non consiglierei Access come strumento per una soluzione che
vada al di la' di un piccolo tool da ufficio monoutente. Visto che non
si tratta di un' applicazione di dimensioni mostruose non credo sia
nemmeno il caso di scomodare Oracle ( o SQL Server full) che tra l'
altro comporterebbero mostruosi costi di licenza. Il linguaggio non e'
un problema, C# e VB.NET sono due grammatiche leggermente diverse per
la stessa sostanza.. Se sei abituato a lavorare con MS ti consiglierei
VB.NET + SQL Server Express: questa sarebbe una piattaforma di
sviluppo del tutto rispettabile e scalabile. Se non ti piace lavorare
con MS un' alternativa potrebbe essere Java + PostgreSQL MySQL o
anche Oracle Express. Se non ci sono particolari requisiti alla fine
e' anche molto una questione di quale tecnologia ti e' piu' familiare
o quale ti interessa di piu' approfondire..
come i batteri pericolosi, ma non e' una buona ragione per
tollerarli :)
Accetto pure questo. Ma un environment 'fool proof' non dovrebbe
permettere ad un 'fool' (cioè io) di smanettare liberamente, provando
qui e là o tools che mette a disposizione SENZA SCRIVERE SOURCE CODE DA
PARTE MIA, ed azzerare un database. Questo non posso permetterglielo.
Perchè se in fase di 'Evaluation' già ottengo questi risultati, chi è
che rischia di comprare un prodotto simile per una applicazione molto
sensibile (in questo caso sono dati ospedalieri, ma potrebbe essere
anche qualcosaltro).
> comunque non consiglierei Access come strumento per una soluzione che
> vada al di la' di un piccolo tool da ufficio monoutente.
Il fatto non è così semplice come sembra : infatti, proprio in questi
casi, si ha un database 'generale, ospedaliero' magari fatto con Oracle
magari residente su *NIX, e migliaia di piccole applicazioni
periferiche, ognuna per ogni istituto, CHE CONTENGONO GLI STESSI DATI
(per lo meno anagrafici). Cioé esiste una forte ridondanza di dati che,
IMHO non ha senso che esista.
E questi database 'locali' sono tutti in Access.
Visto che non
> si tratta di un' applicazione di dimensioni mostruose non credo sia
> nemmeno il caso di scomodare Oracle ( o SQL Server full) che tra l'
> altro comporterebbero mostruosi costi di licenza. Il linguaggio non e'
> un problema, C# e VB.NET sono due grammatiche leggermente diverse per
> la stessa sostanza.. Se sei abituato a lavorare con MS ti consiglierei
> VB.NET + SQL Server Express: questa sarebbe una piattaforma di
> sviluppo del tutto rispettabile e scalabile.
Con i database Access bisogna usare l' OLEDB, non SQL Server.
Se non ti piace lavorare
> con MS un' alternativa potrebbe essere Java + PostgreSQL MySQL o
> anche Oracle Express. Se non ci sono particolari requisiti alla fine
> e' anche molto una questione di quale tecnologia ti e' piu' familiare
> o quale ti interessa di piu' approfondire..
>
L'ambiente in cui mi muovo, anche in ambiente Universitario, è
fortemente orientato a Microsoft Visual Studio, ASP, .NET etc.
Perché non hai risposto direttamente a John?
> Per il futuro io direi di cambiare piattaforma. magari usando Oracle.
> Alla piattaforma non ci ho ancora pensato.
>
> Ho ragione o sono troppo radicale ?
per come la vedo io sei fin troppo blando. al di là della solidità del
database su cui si può anche discutere, ma i dati dei pazienti su un
file mdb... non trovo parole per commentare. a me pare un problema molto
più grosso.
> Accetto pure questo. Ma un environment 'fool proof' non dovrebbe
> permettere ad un 'fool' (cio io) di smanettare liberamente, provando
> qui e l o tools che mette a disposizione SENZA SCRIVERE SOURCE CODE DA
> PARTE MIA, ed azzerare un database. Questo non posso permetterglielo.
perdona, ma se MS ti offre dei tool per eseguire auutomaticamente
operazioni su db senza farti scrivere codice, beh non mi sembra il
caso di inalberarsi se quando gli chiedi di fare drop o delete dal tuo
db questi tool eseguano i tuoi ordini..cosa vorresti.. che il codice
autogenerato da VS ti tirasse su una finestrella di conferma ogni
volta che fai una delete? :)
> Il fatto non cos semplice come sembra : infatti, proprio in questi
> casi, si ha un database 'generale, ospedaliero' magari fatto con Oracle
> magari residente su *NIX, e migliaia di piccole applicazioni
> periferiche, ognuna per ogni istituto, CHE CONTENGONO GLI STESSI DATI
> (per lo meno anagrafici). Cio esiste una forte ridondanza di dati che,
> IMHO non ha senso che esista.
beh , parte del tuo lavoro come consulente e' far loro capire l'
orrore della situazione...se non e' possibile allora magari adeguati,
ma in maniera un pelo piu' intelligente usando sql server o oracle in
version express
> Con i database Access bisogna usare l' OLEDB, non SQL Server.
Calma. OLEDB e' una tecnica di connessione, sql server e' un DBMS :)
Quello che vuoi dire e' che al momento stai usando OleDbProvider per
connettere la tua applicazione VB con il database.
Non e' un problema, se passi da access a sql server basta cambiare il
provider (lo fai visualmente quando crei una connessione in Visual
Studio..). O se proprio vuoi potresti continuare ad usare OLEDB pure
con Sql Server anche se non vedo perche' dovresti farlo..
Di fatto volendo fare il fico ADO.NET ti da' anche la possibilita' di
programmare per interfacce e cambiare il providere addirittura a
runtime modificando poco o zero codice.. un po' come fa Java con
JDBC.. ma questa e' un ' altra storia... :)
> Se non ti piace lavorare
>
> > con MS un' alternativa potrebbe essere Java + PostgreSQL MySQL o
> > anche Oracle Express. Se non ci sono particolari requisiti alla fine
> > e' anche molto una questione di quale tecnologia ti e' piu' familiare
> > o quale ti interessa di piu' approfondire..
>
> L'ambiente in cui mi muovo, anche in ambiente Universitario,
> fortemente orientato a Microsoft Visual Studio, ASP, .NET etc.
e allora vai con VB.NET + SQL Server Express.
Ma non andare cosi' a tentativi, o piglierai solo sonore facciate.
Un libro come questo potrebbe esserti utile
http://www.amazon.com/Murachs-ADO-NET-Database-Programming-2010/dp/1890774626/
Oppure ci sono i video tutorial di AppDev che sono grandiosi. Putroppo
costano pure un fottio...
Io non lo farei mai perche' e' illegale ;P ma ci sono molti siti
dove puoi trovare i loro tutorial su .NET, SQL Server, ADO.NET, ASP o
WPF ....
>
>> Accetto pure questo. Ma un environment 'fool proof' non dovrebbe
>> permettere ad un 'fool' (cio io) di smanettare liberamente, provando
>> qui e l o tools che mette a disposizione SENZA SCRIVERE SOURCE CODE DA
>> PARTE MIA, ed azzerare un database. Questo non posso permetterglielo.
>
> perdona, ma se MS ti offre dei tool per eseguire auutomaticamente
> operazioni su db senza farti scrivere codice, beh non mi sembra il
> caso di inalberarsi se quando gli chiedi di fare drop o delete dal tuo
> db questi tool eseguano i tuoi ordini..cosa vorresti.. che il codice
> autogenerato da VS ti tirasse su una finestrella di conferma ogni
> volta che fai una delete? :)
E' proprio questo il fatto. Io non ho fatto nulla di simile.
Leggi la mia risposta a Luca menegotto. Quello č tutto quello che ho fatto.
>
> beh , parte del tuo lavoro come consulente e' far loro capire l'
> orrore della situazione...se non e' possibile allora magari adeguati,
> ma in maniera un pelo piu' intelligente usando sql server o oracle in
> version express
>
Vabbč, ma nella situazione attuale, quello che faccio č per la mia tesi.
Non ho veste di consulente. Se quando ho finito la tesi, mi vorranno
come consulente, lo farň senzaltro.
> > L'ambiente in cui mi muovo, anche in ambiente Universitario,
>> fortemente orientato a Microsoft Visual Studio, ASP, .NET etc.
>
> e allora vai con VB.NET + SQL Server Express.
> Ma non andare cosi' a tentativi, o piglierai solo sonore facciate.
> Un libro come questo potrebbe esserti utile
> http://www.amazon.com/Murachs-ADO-NET-Database-Programming-2010/dp/1890774626/
> Oppure ci sono i video tutorial di AppDev che sono grandiosi. Putroppo
> costano pure un fottio...
> Io non lo farei mai perche' e' illegale ;P ma ci sono molti siti
> dove puoi trovare i loro tutorial su .NET, SQL Server, ADO.NET, ASP o
> WPF ....
<hehehehe> neanch'io lo farei mai, perchč č illegale....
(Ma soprattutto perchč dopo due o tre mesi ti accorgi di avere un
viretto che ti obbliga a reinstallare il sistema.... :-((((( )
>
> per come la vedo io sei fin troppo blando. al di là della solidità del
> database su cui si può anche discutere, ma i dati dei pazienti su un
> file mdb... non trovo parole per commentare. a me pare un problema molto
> più grosso.
>
Per fortuna non sono io il colpevole.
Io uso solo quello che passa il convento.... :-)))
volevo, ogni tanto sbaglio persino io :P
ad essere sinceri mi preoccuperebbe anche il fatto che qualcuno mi
potrebbe un giorno accusare di essermelo copiato.
ma anche quello che ti è successo... si può consegnare un programma
sapendo che ha i privilegi per asfaltare il database di produzione? al
di la della pura questione tecnica che profuma di cazzatella da un
kilometro (non conosco gli strumenti ma questi "misteri" si risolvono
tutti così, garantito) resta il fatto che è suonato un campanello
d'allarme e forse è meglio ascoltarlo che zittirlo.
Non ci ho mai piu' voluto aver a che fare ... :-)
ciao
fm
>
> ad essere sinceri mi preoccuperebbe anche il fatto che qualcuno mi
> potrebbe un giorno accusare di essermelo copiato.
> ma anche quello che ti è successo... si può consegnare un programma
> sapendo che ha i privilegi per asfaltare il database di produzione? al
> di la della pura questione tecnica che profuma di cazzatella da un
> kilometro (non conosco gli strumenti ma questi "misteri" si risolvono
> tutti così, garantito) resta il fatto che è suonato un campanello
> d'allarme e forse è meglio ascoltarlo che zittirlo.
Che esiste una causa specifica per tutto quello che accade in un
computer, ci credo anch'io. Anch'io nella mia lunga esperienza di
software developer mi sono rotto le corna con centinaia di 'misteri' che
poi alla fine si sono risolti.
Ma quante 'cazzate' si possono fare creando un codice solo usando un mouse ?
Cioè tu lanci l'IDE del VB Express 2010 e cominci a cliccare qua là,
SENZA SCRIVERE CODICE TUO. Alla fine fau 'run' e quello gira quattro o
cinque volte e poi ti sparisce il contenuto del database.
Tu pensi ad un errore di link, avrai fatto qualche cazzata cliccando e
che non sei connesso propriamente al database.
E invece scopri alla fine che quello che vedi è proprio quello CHE C'È ?
Cioè il contenuto è stato cancellato.
Eppure non ho usato nessun 'button' che contenga codice 'delete' o
'insert' o qualche altra cosa.
E' questo che mi ha colpito maggiormente.
Quello che fa il softwrae è solamente quello cche l'IDE stessa ha creato.
Incluso il data.adapter.Fill (datatable) messo automaticamente sul
Form.Load.
A questo punto credo nei fantasmi, in Babbo natale e negli UFO.
In alternativa, sono obbligato a credere che l'IDE del VB .NET (oppure
Access ???) non siano FOOL PROOF.
Toh, un altro che ha scoperto che per fare il programmatore non basta
il point e click !
ps: access non è certo la scelta adatta per un DB ospedaliero, ma che
tu non riesca a salvarci un record da vb.net fa ride...
>Se non è una trollata, hai fatto benissimo a domandare.
Temo che lo sia :-)
>Non usare Access in quell'ambiente.
Questo è ragionevole ma ci sono applicazioni .NET + Jet Engine che girano da
anni e non distruggono i DB dopo 10 minuti.
>Usa un qualche db che abbia opzioni high availability, ove sia
>possibile sia ridondanza che failover, possibilmente automatica (scusa
>l'Inglese, ma non ricordo i termini in Italiano, se esistono). Ne
>esistono sia proprietari che open.
Non so se ti rendi conto di quanto costi mettere su e mantenere una
infrastruttura simile. Credo che non sia economicamente possibile per la
realtà che deve affrontare il buon John :-)
Probabilmente un sano SQLServer Express sarebbe più che sufficiente.
>Per 5 o 6 volte appaiono i dati correttamente. Poi al prossimo run tutto é
>sparito. Cioé anche accedendo al database con Access si nota che IL
>CONTENUTO E' STATO DISTRUTTO.
Non è che selezioni tutte le righe della Gridview e poi premi delete?
Cosa intendi per "DISTRUTTO"?
>
>> Se non è una trollata, hai fatto benissimo a domandare.
> Temo che lo sia :-)
>
Per quanto uno possa essere un troll, distruggere un database solamente
usando un mouse per costruire una GUI, ce ne vuole di sfiga...
>> Non usare Access in quell'ambiente.
> Questo è ragionevole ma ci sono applicazioni .NET + Jet Engine che
> girano da anni e non distruggono i DB dopo 10 minuti.
>
Una tesi fatta nel 2006 per il Carlo Mondino di Pavia (Ospedale
Universitario di Ricerca) lavorava su un database Access.
E' detto tutto.
Quindi mi meraviglio io stesso di questo evento.
Io segnalo solo il fatto.
<hahahaha> ottima battuta.
>
> ps: access non č certo la scelta adatta per un DB ospedaliero, ma che
> tu non riesca a salvarci un record da vb.net fa ride...
Ti sei perso qualcosa ? Io non stavo tentando di 'salvare' o 'updatare'
niente. Stavo solo 'leggendo'.
sono tonto ma non fino a quel punto :-)))
In ogni modo, ho messo l'attributo 'Read only' sulla Data Grid View.
> E questi database 'locali' sono tutti in Access.
>
Ma lo scenario è in crucconia o qui da noi?
In ogni caso butta Access e usa SQL Server, almeno li quando non capisci che
succede il profiler ti aiuta e di certo il contenuto delle tabelle non
sparisce per motivi mistici.
> Usato A-cess una volta, credo nel 1996 per un mini-progetto,
> mio giudizio : pessimo prodotto.
>
Dipende per cosa lo hai usato.
Sapendo come funziona e i workaroud giusti (!!!???) non è niente male, fosse
altro per le capacità di reportistica.
None. Qui in Italia.
> In ogni caso butta Access e usa SQL Server, almeno li quando non capisci
> che succede il profiler ti aiuta e di certo il contenuto delle tabelle
> non sparisce per motivi mistici.
>
Cioè fammi capire, l'anello debole del sistema in questo caso sarebbe
allora l'OleDB ?
Comunque, se ti consola, ho replicato le azioni che hai descritto nel post
precedete e non si distrugge niente.
Ne desumo che tu abbia problemi diversi nel tuo sistema che portano alla
corruzione del DB.
Potresti mettere a disposizione su qualcosa tipo Skydrive il programma (sia
sorgente che compilato) ed il db di test. Cosi magari si può dargli
un'occhiata.
None. Qui in Italia.
Probabilmente non hai ancora capito cosa sia OleDB. OleDB è una interfaccia
di accesso generica ad un motore
di gestione dati. E' fondamentalmente composto da due livelli: il consumer
OleDB (Ado, Ado.NET lo sono) ed il provider OleDB, ovvero l'intefaccia verso
il motore di gestione dati.
Prima dei client nativi .NET per SQLServer si usava (e si usa) il provider
OleDB per SQLServer.
Quello che tu chiami OleDB è JetEngine, sarebbe a dire il motore di gestione
dati usato da Access.
> Potresti mettere a disposizione su qualcosa tipo Skydrive il programma
> (sia sorgente che compilato) ed il db di test. Cosi magari si può dargli
> un'occhiata.
Il source è tutto qui sotto. Non ne esiste altro.
Il database lo si puo' creare a piacere. Io l'ho creato con Access.
source :
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
'TODO: This line of code loads data into the
'PippoDataSet.Anagrafica' table. You can move, or remove it, as needed.
Me.AnagraficaTableAdapter.Fill(Me.PippoDataSet.Anagrafica)
End Sub
End Class
peggio mi sento.
Mi pari il muratore che da la colpa alla cazzuola se il muro è storto.
PS: neppure la tua identificazione del capro espiatorio è giusta, al
limite se ci fosse un bug sarebbe di visual studio non di vb.net.
Ma proprio al limite è.. ma tanto al limite.. talmente tanto al limite
che secondo me hai messo il DB nel progetto invece che nella cartella
dati e quello quando compili giustamente te lo sovrascrive o qualcosa
di simile.
Dai retta, passa a java, quello va su tutte le piattaforme, usa Java
dai retta.
Okay. io sono un muratore sccemo. Ma un muratore scemo deve avere tanta
di quella forza per abbattere un muro già ben consolidato.
Io avevo creatoun 'robusto' (lmeno spero) database di test con Access.
Un database scemo, fatto solo di 'kjhg' 'eqwkjewrhg' 'hsajkL' cioè
battendo a caso sulla tastiera. e meno male.
Pensa se ero così scemo da usare il database originale dei pazienti.
> PS: neppure la tua identificazione del capro espiatorio è giusta, al
> limite se ci fosse un bug sarebbe di visual studio non di vb.net.
>
Qui posso ammettere la mia ignoranza nel distinguere il 'colpevole' tra
Visual Studio (che non uso, ma magari la versione Express lo usa in
qualche forma) o VB .NET.
Io sto usando il VB Express 2010. su Framework .NET 4.0.
(La tesi la faccio a casa e anche se potrei scaricarmi gratis il Visual
Studio per Studenti, all'università, preferisco lavorare coi miei tools
privati).
> Ma proprio al limite è.. ma tanto al limite.. talmente tanto al limite
> che secondo me hai messo il DB nel progetto invece che nella cartella
> dati e quello quando compili giustamente te lo sovrascrive o qualcosa
> di simile.
>
Sì. Ho messo il database nella cartella del progetto (/bin/debug).
Li metto sempre là i dati 'fissi' che devo leggere, ma non ho MAI avuto
questo problema. Altrimenti me ne sarei giá accorto da un anno.
> Dai retta, passa a java, quello va su tutte le piattaforme, usa Java
> dai retta.
>
Non ho niente contro java, ma ho un professore che è innamorato
dell'ambiente
Visual Studio, ASP, .NET, VB et similia e non mi sognerò mai di
consigliarli su che piattaforma
fare la mia tesi. Voglio un 30 e lode...e non voglio rischiare.
:-))))
te l'ho detto, vai molto molto più tranquillo con java, fossi in te
non metterei a rischio la tesi e passerei subito a quell'ambiente di
sviluppo !
Ma scherzi ?
Metti che sviluppi il progetto e poi in fase di discussione della tesi
sul monitor esce un coniglio ??
No, no. Passa a Java subito subito, Eclipse poi è gratis e comunque
anch'esso si collega ad access.
Si però questa volta lo hai messo anche nel progetto vero ? E' solo
una delle possibilità ma io scommetterei che di database ne hai uno
nel progetto vuoto ed uno in bin che popoli...
Certo potrebbe anche essere mille altre cose, ma tutte,
indiscutibilmente, senza alcun dubbio e certamente sono COLPA TUA,
questo potrebbe essere un buon inizio per una carriera di lavoro.
> Dai retta, passa a java, quello va su tutte le piattaforme, usa Java
> dai retta.
>
Ueh, hai paura della concorrenza??? :-)
Errori di run-time spesso e volentieri e soprattutto incomprensibili crash
del database....
qualche volta si risolveva, col tool di ricostruzione....altre no. Ovvero
perdita di tutti i dati.
Gia' il fatto che il produttore avesse aggiunto un tool di ricostruzione
la dice lunga ...
Poi, il fatto che fosse compatibile con quel SUPER cesso che era Windows 95
la dice
ancor piu' lunga....
ciao
fm
>
>> Ma proprio al limite č.. ma tanto al limite.. talmente tanto al limite
>> che secondo me hai messo il DB nel progetto invece che nella cartella
>> dati e quello quando compili giustamente te lo sovrascrive o qualcosa
>> di simile.
>>
>
Guarda qui :
estratto da
http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(VS.DATA.LOCALCONNECTIONCONVERTER)%3bk(TargetFrameworkMoniker-%22.NET
FRAMEWORK%2cVERSION%3dV4.0%22)&rd=true
--------
Copy to Output Directory setting
Behavior
Copy if newer (default for .sdf files)
The database file is copied from the project directory to the bin
directory the first time the project is built. Every subsequent time you
build the project, the Date Modified property of the files is compared.
If the file in the project folder is newer, it is copied to the bin
folder, replacing the file that is currently there. If the file in the
bin folder is newer, no files are copied. This setting persists any
changes made to the data during run time, meaning that every time you
run your application and save changes to the data, those changes are
visible the next time you run your application.
*****
Caution This option is not recommended for .mdb or .mdf files.
*******
The database file can change even when no changes are made to the
data. Simply opening a connection (for example, expanding the Tables
node in Server Explorer) on a data file can mark it as newer. Because of
this unpredictable behavior, we recommended that you do not use this
option for .mdb or .mdf files.
-----------
Quindi molto probabilmente sono incappato in questa 'trappola'.
Ma purtropppo, mi dispiace, ma PERCHE' uno deve andarsi a leggere tutta
la letteratura mondiale, prima di poter azzardare una semplice lettura
di un database, altrimenti rischia di cancellarlo ??
VI sembra normale ?
Io non so cosa pensate voi, ma una ambiente che si comporta cosě, non č
assolutamente FOOL PROOF.
Mi dispiace. in una commissione per decidere su una piattaforma, non ha
il mio voto !
John.
ssshhhhh.... zitto zitto che lo convinco...
WOW, allora avrei 500 e lode. :-))
> No, no. Passa a Java subito subito, Eclipse poi è gratis e comunque
> anch'esso si collega ad access.
Ne parlerò col prof. Ma penso che lui insista nel voler usare Visual
Studio o similare.
> Errori di run-time spesso e volentieri
E vabbe', ma se non metti la gestione degli errori mica è colpa di Access...
:-)
> e soprattutto incomprensibili crash del database....
> qualche volta si risolveva, col tool di ricostruzione....altre no. Ovvero
> perdita di tutti i dati.
>
Se il db era in rete e magari condiviso, anni fa c'era una marca di schede
di rete che per motivi mai chiariti era capace appunto di rovinare spesso
gli mdb.
Ma appunto, sapendolo, si risolve... :-)
> Gia' il fatto che il produttore avesse aggiunto un tool di ricostruzione
> la dice lunga ...
>
Vabbe', l'equivalente del recupera & compatta di Access lo trovi anche su
SQL Server & C se per quello, certo che la frequenza di utilizzo non è
minimanente paragonabile, ma per dire che per principio non è un'opzione
così assurda.
Il problema di Access è la condivisione dei dati su enne postazioni quando
il "servizio" di rdbms è postazione per postazione e non solo sui dati
condivisi, e il supporto nullo alle transazioni, compreso il log.
Ma se lo inizi ad usare solo come front-end e reportistica con la parte dati
attaccata magari a SQL, escono fuori anche belle applicazioni, non di moda,
ma comunque robuste e ben funzionanti.
> Certo potrebbe anche essere mille altre cose, ma tutte,
> indiscutibilmente, senza alcun dubbio e certamente sono COLPA TUA,
> questo potrebbe essere un buon inizio per una carriera di lavoro.
>
Senzaltro l'unico 'agente' di tutto sono io. non c'è dubbio.
Il fatto però sta *quale grado di scemenza* puo' permettermi un sistema
di sviluppo senza cancellarmi un database.
Grazie ad un link (di RMX su Visual-Basic NG) ho letto sulla ISDN la
'trappola' in ci sono probabilmente incappato.
Ebbene. questo non dovrebbe succedere in un ambiente di sviluppo 'sicuro
al 100%'.
Non si deve forzatamente leggere tutta la letteratura mondiale per poter
fare un programma (tra l'altro senza scrivere codice, ma solo usando i
tools dell'IDE cliccando sul mouse) che non rischia di cancellare un
database.
E' come pretendere che un medico, prima di poter andare a curare i
malati, debba sapere TUTTO quello che scrive la letteratura mondiale, e
l'ultima versione updatata.
Stai fresco. Saremmo senza medici.
Guardati il capitolo su cui appare questa 'proprietà'
E' UNACOSA SCONSIGLIATA PER I DATABASE ACCESS (.mdb che sono poi la
maggioranza) E LA METTONO DI DEFAULT ??? ma siamo matti ???
No. Io rimango della mia opinione : VB .NET + Access
non è una combinazione 'Fool Proof'. Sorry.
> Ma purtropppo, mi dispiace, ma PERCHE' uno deve andarsi a leggere tutta
> la letteratura mondiale, prima di poter azzardare una semplice lettura
> di un database, altrimenti rischia di cancellarlo ??
> VI sembra normale ?
>
per lo stesso motivo di cui al tuo post precedente, se un medico non si
informa sulle nuove e sicure procedure di intervento e cura del
paziente, non puň certo dire che lui sia un BRAVO medico, al massimo puň
vantarsi di essere un MEDIOCRE con la laurea di medico.
da quel che leggo sei un universitario alle prese con una tesi, mbe qui
ci sono professionisti con anni di esperienza che continuano a studiare,
il nostro settore č in continua evoluzione e NOI TUTTI si continua a
studiare SEMPRE.
se vuoi fare questo lavoro sappi che starai sempre con un computer e un
libro (magari ebook) in mano.
> Io non so cosa pensate voi, ma una ambiente che si comporta cosě, non č
> assolutamente FOOL PROOF.
>
nessuna cosa e FOOL PROOF, se qualcuno ti ha detto ciň, o č in mala fede
o non sa nulla del settore e ha solo una conoscenza teorica.
> Mi dispiace. in una commissione per decidere su una piattaforma, non ha
> il mio voto !
>
perň quando ti č stato suggerito di passare ad altro (java) hai
obbiettato che il "tuo prof" non sia d'accordo, ora mi chiedo quanto
vale il TUO voto :)
> John.
>
non voglio fare il saccente e se ho dato quest'impressione me ne scuso,
ma mi sembra di vedere ME qualche anno fa (la colpa č sempre NON mia),
quando invece di solito la colpa č data dalla poca esperienza e saccenza.
Ciao
Sě, anche mie :)
> Non so se ti rendi conto di quanto costi mettere su e mantenere una
> infrastruttura simile.
Sě, perfettamente, ed č quello che mi aspetti un ospedale faccia per gestire
i dati dei pazienti!
Se leggi il messaggio successivo, poi ho chiarito che se serve per fare
elaborazioni, reportistica e quant'altro, replicando/duplicando in locale o
anche in dipartimento dati comunque gestiti altrove, Access puň anche
andare.
> Probabilmente un sano SQLServer Express sarebbe piů che sufficiente.
Sě, ma ovviamente nello scenario in cui potrebbe anche usare Access (o
comunque abbastanza simile).
--
ale
http://ale.riolo.co.uk
>
>> comunque non consiglierei Access come strumento per una soluzione che
>> vada al di la' di un piccolo tool da ufficio monoutente.
>
> Il fatto non è così semplice come sembra : infatti, proprio in questi
> casi, si ha un database 'generale, ospedaliero' magari fatto con Oracle
> magari residente su *NIX, e migliaia di piccole applicazioni
> periferiche, ognuna per ogni istituto, CHE CONTENGONO GLI STESSI DATI
> (per lo meno anagrafici). Cioé esiste una forte ridondanza di dati che,
> IMHO non ha senso che esista.
>
vero, ma potrebbe avere un senso se l'ospedale che è organizzato in
suddetta maniera, non ha una gestione IT centralizzata (il 90% dei casi
aime), oppure non necessariamente, i vari reparti (che ricordo posssono
essere AUTONOMI nella gestione) hanno la necessità di condividere gli
archivi DB (esempio pratico privacy, o dati sensibili) oppure gestione
differenti dei dati, per esempio un reparto di pediatria ha necessità
magari di conoscere la storia medica dei genitori del paziente (il
figlio), anche se questi ultimi non hanno nulla a che fare come pazienti
(loro stessi) con l'ospedale, oppure richiedere dati che poco hanno a
che fare con l'organizzazione ospedialiera come viaggi in paesi a
rischio (reparto infettivo/vaccinazioni), ferite da armi (pronto
soccorso/chirurgia), stato penale della persona(pronto
soccorso/chirurgia) ecc.
> E questi database 'locali' sono tutti in Access.
>
quando si dice che di caciottari ne è pieno il mondo (scusa se ho
utilizzato il tuo marchio di fabbrica john smith :) )
> Visto che non
>> si tratta di un' applicazione di dimensioni mostruose non credo sia
>> nemmeno il caso di scomodare Oracle ( o SQL Server full) che tra l'
>> altro comporterebbero mostruosi costi di licenza. Il linguaggio non e'
>> un problema, C# e VB.NET sono due grammatiche leggermente diverse per
>> la stessa sostanza.. Se sei abituato a lavorare con MS ti consiglierei
>> VB.NET + SQL Server Express: questa sarebbe una piattaforma di
>> sviluppo del tutto rispettabile e scalabile.
>
> Con i database Access bisogna usare l' OLEDB, non SQL Server.
>
ma anche no (in parte), tempo fa mi sono occupato di un progetto simile
al tuo, con un file access e inorridito mi sono espressamente rifiutato
di utilizzarlo, ma per andare avanti ho utilizzato un dbms MySql con
link al file access.
il software accedeva a MySql il quale LUI (tramite OleDB) si occupava di
intrattenere i rapporti con Access.
> Se non ti piace lavorare
>> con MS un' alternativa potrebbe essere Java + PostgreSQL MySQL o
>> anche Oracle Express. Se non ci sono particolari requisiti alla fine
>> e' anche molto una questione di quale tecnologia ti e' piu' familiare
>> o quale ti interessa di piu' approfondire..
>>
>
> L'ambiente in cui mi muovo, anche in ambiente Universitario, è
> fortemente orientato a Microsoft Visual Studio, ASP, .NET etc.
>
CAMBIA
di solito ne basta una :P
scherzi a parte, lo strumento non lo conosco quindi non sono in grado
nemmeno di fare ipotesi. magari chissà, essendo un database su file
anche uno stupido bug sul driver lo può corrompere. prova ad andarci con
un altro sistema.
Ma trappola di che ?
il link è esattamente il problema che ti ho descritto pochi post sopra
(How to: Manage Local Data Files in Your Project).
Scusami tanto ma se non sai neppure dove mettere i tuoi file di DB e
con che proprietà forse è meglio che i tuoi form li fai con ACCESS.
Access, usa Access da solo, quello si è "Fool Proof" ed è anche molto
più veloce nello sviluppo e ci puoi fare tutto anche le stampe,
funziona sempre, non c'è installazione, ci puoi mettere i bottoni
anche quelli grossi e se cambi il DB lui se ne accorge da solo.
Secondo me le scelte sono due, o access o java con Eclipse, ma in ogni
caso STAI LONTANO DA VISUAL STUDIO, è assolutamente controproducente.
No, Access non può andare se sopra ci sono i nomi dei pazienti. In
Italia ci sono delle leggi sulla privacy abbastanza stringenti ed un
db che può essere copiato ed incollato e a cui le macchine client
devono accedere fisicamente, senza logo degli accessi ecc.. non può
essere usato in un ospedale.
> però quando ti è stato suggerito di passare ad altro (java) hai
> obbiettato che il "tuo prof" non sia d'accordo, ora mi chiedo quanto
> vale il TUO voto :)
>
Nulla. Ma io non sono il rettore dell'università o il direttore
dell'istituto.
Comunque io rimango della mia opinione che un ambiente di sviluppo che
si rispetti, aperto a TUTTI, anche ai principianti, che quindi
'smanettano' per imparare, per conoscerlo, per familiarizzare, e che
possano distruggere un database SENZA SCRIVERE UNA LINEA DI CODICE, ma
solamente smanettando col mouse, solamente perchè l'hanno messo nel
directory di svilupppo invece che in un altro directory,
ha una 'security standard' che fa ridere i polli.
Poi ognuno è libero delle sue opinioni.
>
> Secondo me le scelte sono due, o access o java con Eclipse, ma in ogni
> caso STAI LONTANO DA VISUAL STUDIO, è assolutamente controproducente.
>
Perchè dovrebbe essere così ?
Visual Studio lo insegnano all'Università, quindi con studenti
programmatori 'in erba' che 'smanettano' e sperimentano per conoscerlo.
Perchè dovrebbe essere uno strumento 'da usare con cautela' come un
farmaco pericoloso ?
Ma SCHERZI ?! Visual studio è pericolosissimo, tu pensa che bastano
poche righe di codice ed è in grado di distruggerti anche il sistema
operativo.
Dovresti assolutamente abbandonarlo e passare a strumenti più sicuri
come JAVA, che ha un editor molto bello, si chiama www.eclipse.org ed
è simile a visual studio, si connette ad access e fa tutto tutto come
vb.net.
Poi è multipiattaforma e gratis anche in versione professionale !!
>> e soprattutto incomprensibili crash del database....
>> qualche volta si risolveva, col tool di ricostruzione....altre no. Ovvero
>> perdita di tutti i dati.
>>
>
> Se il db era in rete e magari condiviso, anni fa c'era una marca di schede
> di rete che per motivi mai chiariti era capace appunto di rovinare spesso
> gli mdb.
> Ma appunto, sapendolo, si risolve... :-)
>
Certo che si risolve.....un database che perde tutti i dati si getta nel
cestino dell'immondizia!
Esattamente quello che ho fatto.
>> Gia' il fatto che il produttore avesse aggiunto un tool di ricostruzione
>> la dice lunga ...
>>
>
> Vabbe', l'equivalente del recupera & compatta di Access lo trovi anche su
> SQL Server & C se per quello, certo che la frequenza di utilizzo non �
> minimanente paragonabile, ma per dire che per principio non � un'opzione
> cos� assurda.
Ho alcune applicazioni in funzione con sql server dal 2004, 24h al di',.
non e' mai stata necessaria ALCUNA ricostruzione.
Con il DB2 di Ibm vedi un errore ogni morte di papa ...
ed intendo proprio dire ogni venti o trenta anni.
> Il problema di Access � la condivisione dei dati su enne postazioni
era un'applicazione per postazione singola, anno 1996.
.
> il "servizio" di rdbms � postazione per postazione e non solo sui dati
> condivisi, e il supporto nullo alle transazioni, compreso il log.
> Ma se lo inizi ad usare solo come front-end e reportistica con la parte
> dati attaccata magari a SQL,
Con a Sql Server esistono svariate soluzioni di reportistica ...
> escono fuori anche belle applicazioni, non di moda, ma comunque robuste e
> ben funzionanti.
>
robuste e funzionanti con A-cess?
ROTFL
ciao
fm
"Non esiste macchina abbastanza intelligente per essere adoperata da uno
sciocco"
Moltissimi anni fa io ed un amico stavamo installando un server,
l'operazione era di quelle che all'epoca duravano diverse ORE.
Ad un certo punto arriva un altro amico, si mette a chiacchierare, racconta
varie stupidaggini e ... .inavvertitamente COL GOMITO preme il tasto di
riavvio della macchina !
Ma vaff ....
ciao
fm
>
>
> si puo' rischiare di lavorare professionalmente in un ambiente simile ??
I bug nativi esistono, ma questo mi sembra un elefante più che una
cimice.
Un lavoro professionale esige che uno si studi bene i tool che sceglie
*prima* di usarli.
> Calma. OLEDB e' una tecnica di connessione, sql server e' un DBMS :)
> Quello che vuoi dire e' che al momento stai usando OleDbProvider per
> connettere la tua applicazione VB con il database.
> Non e' un problema, se passi da access a sql server basta cambiare il
> provider (lo fai visualmente quando crei una connessione in Visual
> Studio..). O se proprio vuoi potresti continuare ad usare OLEDB pure
> con Sql Server anche se non vedo perche' dovresti farlo..
> Di fatto volendo fare il fico ADO.NET ti da' anche la possibilita' di
> programmare per interfacce e cambiare il providere addirittura a
> runtime modificando poco o zero codice.. un po' come fa Java con
> JDBC.. ma questa e' un ' altra storia... :)
Esiste e prospera pure ODBC, c'è n'è perfino una versione per Unix/
Linux.
> > Se non ti piace lavorare
>
> > > con MS un' alternativa potrebbe essere Java + PostgreSQL MySQL o
> > > anche Oracle Express. Se non ci sono particolari requisiti alla fine
> > > e' anche molto una questione di quale tecnologia ti e' piu' familiare
> > > o quale ti interessa di piu' approfondire..
>
> > L'ambiente in cui mi muovo, anche in ambiente Universitario,
> > fortemente orientato a Microsoft Visual Studio, ASP, .NET etc.
>
> e allora vai con VB.NET + SQL Server Express.
> Ma non andare cosi' a tentativi, o piglierai solo sonore facciate.
> Un libro come questo potrebbe esserti utilehttp://www.amazon.com/Murachs-ADO-NET-Database-Programming-2010/dp/18...
> Oppure ci sono i video tutorial di AppDev che sono grandiosi. Putroppo
> costano pure un fottio...
> Io non lo farei mai perche' e' illegale ;P ma ci sono molti siti
> dove puoi trovare i loro tutorial su .NET, SQL Server, ADO.NET, ASP o
> WPF ....
> Ma SCHERZI ?! Visual studio è pericolosissimo, tu pensa che bastano
> poche righe di codice ed è in grado di distruggerti anche il sistema
> operativo.
>
> Dovresti assolutamente abbandonarlo e passare a strumenti più sicuri
> come JAVA, che ha un editor molto bello, si chiama www.eclipse.org ed
> è simile a visual studio, si connette ad access e fa tutto tutto come
> vb.net.
>
> Poi è multipiattaforma e gratis anche in versione professionale !!
>
Bene. Tutte queste cose valle a raccontare al docente di Informatica
Medica.
Io non posso cambiare le cose :-)))
La quasi totalità dei software per ambienti medici usa JetEngine :-)
Dipende. Se io faccio una lezione di 'computer' ai principianti, e
spiego Windows, la prima cosa che faccio è di stare attenti a non
premere mai il tasto 'cancella' della tastiera, oppure di puntare su un
file e cliccare sulla voce 'delete'. MAI se non dopo averci pensato
dieci volte.
Ma se un principiante, volendo conoscere più a fondo l'ambiente di
sviluppo, SENZA SCRIVERE CODICE PROPRIO, si mette a scegliere i vari
tools nella Toolbox e li mette sulla GUI, e poi, vuole generare
semplicemente un link tra una tabella Access e una DataGridView, e
questo funziona per due o tre volte e poi alla quarta vede che il
contenuto del file è stato distrutto, cosa deve fare ?
Puoi dire ad un principiante di andarsi a leggete tutta la biblioteca
MSDN, dove poi magari scopre che il file è meglio che non lo metta nel
directory di sviluppo, altrimenti rischia una cosa simile ?
Ma scherziamo ?
Dove sta il limite della 'ragionevolezza' ??
Questo è proprio quello che comunemente si chama 'robustezza' di un
sistema (Fool Proof).
> Dipende. Se io faccio una lezione di 'computer' ai principianti, e
Però hai scritto in riferimento ad un uso "professionale". La
differenza col principiante è abissale.
> Puoi dire ad un principiante di andarsi a leggete tutta la biblioteca
> MSDN, dove poi magari scopre che il file è meglio che non lo metta nel
> directory di sviluppo, altrimenti rischia una cosa simile ?
> Ma scherziamo ?
Se il principiante non vuol più essere tale, ebbene, sì, prima o poi
dovrà leggersi tanti bei simpatici libroni, od help file, o pdf. E
dovrà fare tanta esperienza di risoluzione di problemi pratici,
proprio come questo.
> Dove sta il limite della 'ragionevolezza' ??
Sta nel fatto che se incappi in un problema come questo, al 99% dovuto
ad un uso incorretto del/dei tool, senza offesa "te la pigli in
saccoccia" e non imprechi sul tool :-)
(PS: ma hai provato anche su un altro pc? Magari è un bug legato a
quel particolare hardware ed ai drivers correlati).
> Questo è proprio quello che comunemente si chama 'robustezza' di un
> sistema (Fool Proof).
Su questo posso essere d'accordo, ma questi sono tools che cercano di
fronteggiare e di offrire di tutto e di più. Ci manca solo che
facciano il caffè. Che nella realtà siano totalmente "fool proof" è
molto improbabile.
Tra l'altro l'opzione "killer" potrebbe essere benissimo definita
dentro al db Access, o potrebbe dipendere dal colloquio della
particolare versione di VS, Net, drivers, Access, Windows.
Non mi scorderò mai la porta seriale che funzionava usando l'apposito
cavo originale Asus da sk. madre Asus a connettore, ma non funzionava
usando un cavo+connettore apparentemente del tutto identici ma non
originali Asus ....
>
> Per� hai scritto in riferimento ad un uso "professionale". La
> differenza col principiante � abissale.
>
quella era una domanda conseguente. Cio� "stando cos� le cose, voi
consigliereste..etc. etc."
> Se il principiante non vuol pi� essere tale, ebbene, s�, prima o poi
> dovr� leggersi tanti bei simpatici libroni, od help file, o pdf. E
> dovr� fare tanta esperienza di risoluzione di problemi pratici,
> proprio come questo.
>
'Poi' mi va bene. Ma se uno un giorno una mattina si sveglia e dice
'toh, andiamo a vedere se anche un principiante coglione come me riesce,
senza a scrivere codice, a fare un link tra una GUI ed un database
Access', e corre al computer e, smanettando, gli riesce col semplice
wizard di ottenere ci� che voleva, e lui saltella felice come una
pasqua, e fa girare il programma due, tre, quattro volte, e poi alla
quinta vede il database vuoto, e lui si guarda intorno come un ebete,
cosa fai ? gli vai a dire 'Vai a leggerti il MSDN, pirla ? '
Ma il VB .NEt nonera il famoso ambiente intuitivo che tutti quanti
possono osare a smanettare ed imparare ?
Allora il coglione principiante si chiedera con ragione 'ma in
quell'ospedale usano VB .NET, tutta l'universit� usa il VB.NEt e Access,
e allora ? se questo succede l� dentro e u ngiorno mi sparisce tutto il
database coi 4700 pazienti, che faccio ???
Ecco. Questo era il suco ddel discorso. Era un topic che volevo portare
a discussione. Non voleva essere una condanna 'a priori' di un environment.
>
> Non mi scorder� mai la porta seriale che funzionava usando l'apposito
> cavo originale Asus da sk. madre Asus a connettore, ma non funzionava
> usando un cavo+connettore apparentemente del tutto identici ma non
> originali Asus ....
>
Beato te che sei giovane e non ti ricordi i tempi in cui le RAM
Mitsubishi non andavano se erano inserite assieme ad altre RAM Texas
Instruments.... Tutto poteva essere mischiato come si voleva, ma le
Mitsubishi sopportavano solo Mitsubishi come 'compagne' di slot.
Eh si... giovinezza giovinezza....
> > Io non lo farei mai perche' e' illegale ;P ma ci sono molti siti
> > dove puoi trovare i loro tutorial su .NET, SQL Server, ADO.NET, ASP o
> > WPF ....
>
> <hehehehe> neanch'io lo farei mai, perchè è illegale....
>
> (Ma soprattutto perchè dopo due o tre mesi ti accorgi di avere un
> viretto che ti obbliga a reinstallare il sistema.... :-((((( )
se scarichi e usi solo zip file che contengono movies non vedo come
potresti prendere virus..
da un' occhiata qui
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev+learning+program
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev+visual+studio
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev+sql+server
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev+wpf
http://www.heroturko.com/index.php?do=search&subaction=search&story=appdev+asp
Tornando al tuo problema: sbagli quando ti ostini a dare la colpa a
Visual Studio. Visual Studio ha dei tool di generazione di codice
pensati per pemettere a chi sa cosa sta facendo di farlo piu'
velocemente, non per facilitare la vita a chi vuole arraffazzonare
una tesi senza sbattersi piu' di tanto e senza capire una beneamata
fava di quello che sta facendo. Non e' uno strumento per niubbi, e' un
IDE altamente sofisticata pensata per essere usata da programmatori
preparati che sanno quello stanno facendo. Come tutti gli strumenti
poi, puo' essere abusato. Mi ricordo del caso di un "programmatore"
che era addirittura certificato su MS ASP cacciato miseramente perche'
era solo abile nel maneggiare Visual Studio, ma senza capire quasi
nulla di quello che faceva, e senza uno straccio di basi di
programmazione ad oggetti. Faceva tutto " a scimmietta".
Se poi sei un niubbo non e' proibito utilizzarlo ovviamente, ci puoi
giocare, ci puoi sperimentare mentre impari, ma sinceramente e'
ridicolo incazzarsi perche' non fa quello che vuoi tu solo perche'
"non ho scritto codice, ha fatto tutto lui", o perche' non so dove
mettere i file che utilizzo nel progetto.
Lascia stare i "consigli" di quel poveretto.. Visual Studio e .NET
va benissimo, come va benissimo Eclipse e Java.
Tra l' altro sono ambienti e stili di programmazione molto simili. La
scelta e' dettata da altre considerazioni, come ti ho gia' detto...
tipo con quale tecnologia sei piu' familiare, o in che ambiente (lunux/
unix, multipiattaforma, o win only)
O i costi di licenza. Oppure il fatto che con VS hai un "workflow"
piu' "streamlined" (una volta che sai quello che stai facendo) che
con Java, ma con Java hai la possibilita' di controllare un po' piu'
in profondita' quello che fai.
Come ultima cosa ci sono i "motivi idelogici". .NET e' proprieta di
una mega corporation come MS, cosa che decisamente puo' non piacere.
Java fino a poco tempo fa , nonostante appartenesse a Sun, era piu'
"community driven".. quasi un progetto open source... ora pero' che
appartiene a Oracle le cose cambiano parecchio...
>
> Tornando al tuo problema: sbagli quando ti ostini a dare la colpa a
> Visual Studio.
Io non *do' la colpa*. Ho semplicemente portato un topic in discussione.
Mi sono fatto una domanda e dato che io da solo non trovavo la risposta
l'ho proposta qui dentro.
Tutto qui.
Poi certe cose si scoprono discutendo.
> Visual Studio ha dei tool di generazione di codice
> pensati per pemettere a chi sa cosa sta facendo di farlo piu'
> velocemente, non per facilitare la vita a chi vuole arraffazzonare
> una tesi senza sbattersi piu' di tanto e senza capire una beneamata
> fava di quello che sta facendo.Non e' uno strumento per niubbi, e' un
> IDE altamente sofisticata pensata per essere usata da programmatori
> preparati che sanno quello stanno facendo.
No. Qui mi oppongo. Un tool che da una parte ti permette con quattro
clic di collegare un database access a una GUI e CI RIESCI al primo
tentativo, non puo' poi distruggermi il contenuto del database dopo
quattro o cinque run per un evento oscuro, ignoto, che si scopre
solamente leggendo l'ISDN.
Questo non lo accetto.
Ognuno puo' avere la sua opinione su questo punto. Ma deve essere chiaro
dall'inizio il grado di complessità alla quale vai incontro.
E' come in Texas dove le pistole si possono comprare al supermercato,
e poi ci si lamenta che un diciottenne va ascuola e spara contro i
professori.
O le cose si rendono facili fino in fondo o si fanno complicate fin
dall'inizio. Così uno si sa regolare e si mette a studiare tutti i
manuali prima di azzardarsi a 'smanettarte'.
>Ma il VB .NEt nonera il famoso ambiente intuitivo che tutti quanti possono
>osare a smanettare ed imparare ?
Guarda che Visual Studio ti ha pure avvertito della cosa con una message
dialog con su scritto:
"The connection you selected uses a local data file that is not in the
current project. Would you like to copy the file to your project and
modify the connection?
If you copy the data file to your project, it will be copied to the
project's output directory each time you run the application. Press F1
for information on controlling this behavior".
Se tu non leggi non è colpa sua :-)
>> Un lavoro professionale esige che uno si studi bene i tool che
>> sceglie *prima* di usarli.
Quoto, non si puo' pensare di programmare *per lavoro* usando un tool
sconosciuto e pretendendo che il tool ci faccia tutto e tutto giusto.
quell'approccio va bene per farsi il database dei propri libri o DVD *a
casa*
> Ma se un principiante, volendo conoscere più a fondo l'ambiente di
> sviluppo, SENZA SCRIVERE CODICE PROPRIO, si mette a scegliere i vari
> tools nella Toolbox e li mette sulla GUI, e poi, vuole generare
> semplicemente un link tra una tabella Access e una DataGridView, e
> questo funziona per due o tre volte e poi alla quarta vede che il
> contenuto del file è stato distrutto, cosa deve fare ?
Due opzioni:
1) Visto che si parla di *lavoro*, farsi il mazzo per imparare a scrivere da
se il codice, in modo da poterlo controllare davvero, perche' se anche ti
fosse andata bene al primo colpo poteva benissimo capitare che in futuro ti
cheidessero di modificare qualcosa, e tu non sai neanche che cosa ci gira
sotto a quella form e quei dati.
2) Continuare a fare il principiante, ergo con quel tool ci fai cose tue per
hobby.
> Puoi dire ad un principiante di andarsi a leggete tutta la biblioteca
> MSDN, dove poi magari scopre che il file è meglio che non lo metta nel
> directory di sviluppo, altrimenti rischia una cosa simile ?
> Ma scherziamo ?
>
> Dove sta il limite della 'ragionevolezza' ??
>
> Questo è proprio quello che comunemente si chama 'robustezza' di un
> sistema (Fool Proof).
--
ViLco
Let the liquor do the thinking
Non so a chi ti riferisci, se parli della pubblicità non ci conterei
troppo :-)
> Beato te che sei giovane e non ti ricordi i tempi in cui le RAM
> Mitsubishi non andavano se erano inserite assieme ad altre RAM Texas
> Instruments.... Tutto poteva essere mischiato come si voleva, ma le
> Mitsubishi sopportavano solo Mitsubishi come 'compagne' di slot.
>
> Eh si... giovinezza giovinezza....
Grazie del giovane, visto che ho passato il mezzo secolo :-)
ok, qualche chiarimento :
- visual studio tratta tutti i file alla stessa maniera, se li metti
nel project lui li rilascia nella bin. Non è che devi leggere MSDN,
devi leggere l'introduzione.
- I DB vanno in una cartella "data" che puoi aggiungere con il tasto
destro, non devi leggere niente, basta guardare i filmatini su asp.net
"come collegarsi ad access" e stanno sull'introduzione di qualunque
manuale
- Non devi mettere niente in bin, questo è semplice chiaro, sempre
scritto nell'introduzione di cui sopra, è la directory di compilazione
e rilascio, ce li mette lui i file o devi sapere cosa stai facendo
- siccome esistono un sacco di programmatori che aprono, cliccano e
poi parlano anche va ricordato che VS non ha un comportamento strano
che fa ogni tanto, no, fa proprio così sempre ogni volta.
- Se non lo sai e in fase di sviluppo ti sovrascrive un file... PACE,
OK, IMPARA, NON E' SUCCESSO NIENTE, perché appunto siamo in un
ambiente di sviluppo e saranno copie o o file di test.
- In produzione non si usa Visual Studio, non si compila, si rilascia
il programma, non potrà mai succedere niente.
- Il fatto che tu clicchi o non clicchi o ti fai comporre del codice è
indifferente, se fai un progetto anche che non fa niente, lui
sovrascriverà il file, è fatto così.
SE NON SAI COSA è LA DIRECTORY BIN, COME SI USA, E PERCHE' ESISTE VUOL
DIRE CHE NON HAI LETTO NEPPURE UN LIBRETTO DELLA JACKSON, NEPPURE I
VIDEO INTRODUTTIVI, NON HAI STUDIATO NIENTE, NON SAI COSA FA QUANDO
COMPILA, NIENTE DI NIENTE.
Spero tu abbia ragione (non bazzico la RI per lavoro da molti anni ormai),
ma hai notizia di qualcuno che sia finito in tribunale per aver violato tale
leggi?
Ad ogni modo, John se non sbaglio dovrebbe essere in Germania ...
--
ale
http://ale.riolo.co.uk
No. John è ancora vivo e vegeto (grazie al cielo) e già da due anni e
mezzo in Italia e sta facendo una tesi in ambiente
ospedaliero/Universitario.
E' verissimo che i dati ospedalieri sono molto curati e protetti, sia
che risiedano su Accewss o qualche altro database.
Non si puo' accedere facilmente ad essi. Bisogna avere dei permessi
speciali.
Infatti il database che mi è sparito non era affatto di pazienti veri,
ma un database che avevo costruito io, per test, con dati verosimili, ma
inventati.
Questo tuttavia non diminuisce la mia incazzatura riguardo al
comportamento del Visual Studio.
Spero comunque di finire presto la tesi e dedicare il mio tempo a
divertirmi con altre cose.
> Spero tu abbia ragione (non bazzico la RI per lavoro da molti anni
> ormai), ma hai notizia di qualcuno che sia finito in tribunale per aver
> violato tale leggi?
per la violazione della privacy si procede per querela di parte e casi
di infermieri/medici denunciati per aver rivelato notizie sulla salute
di pazienti a persone non autorizzate ce ne sono.
> No. Qui mi oppongo. Un tool che da una parte ti permette con quattro
> clic di collegare un database access a una GUI e CI RIESCI al primo
> tentativo, non puo' poi distruggermi il contenuto del database dopo
> quattro o cinque run per un evento oscuro, ignoto, che si scopre
> solamente leggendo l'ISDN.
> Questo non lo accetto.
Appunto, dai la colpa a VS della tua niubbaggine.
> Ognuno puo' avere la sua opinione su questo punto. Ma deve essere chiaro
> dall'inizio il grado di complessità alla quale vai incontro.
Il grado di complessita' non puo' essere "chiaro a priori". E' chiaro
una volta che ti sei preso la briga di studiare il funzionamento degli
strumenti che utilizzi.
> E' come in Texas dove le pistole si possono comprare al supermercato,
> e poi ci si lamenta che un diciottenne va ascuola e spara contro i
> professori.
In effetti strumenti come VS danno la possibilita' di realizzare
codice funzionante anche ad un totale sprovveduto.
Ma se lo sprovveduto si fulmina il db (senza nemmeno averne fatto una
copia) peggio per lui e per chi lo fa lavorare :)
> O le cose si rendono facili fino in fondo o si fanno complicate fin
> dall'inizio. Così uno si sa regolare e si mette a studiare tutti i
> manuali prima di azzardarsi a 'smanettarte'.
Tu confondi facile con "veloce". VS non e' pensato per rendere
"facile" la programmazione. Non come lo intendi tu (schiacciando tasti
alla rinfusa per vedere che effetto fa..) E' pensato per togliere al
programmatore la menata di scrivere la parte di codice che e'
"boilerplate", cioe' quella parte ripetitiva di framework che uno si
dovrebbe noiosamente riscrivere ogni volta uguale o molto simile. E
non bisogna studiarsi "tutti i manuali", basta un libro ben scritto
sulla tecnologia che vai ad utilizzare. Infine nulla proibisce di
smanettare, ma proprio perche' sai che stai smanettando se hai un
minimo di buon senso ti fai un bel backup dei dati che sai ti potresti
fulminare da un momento all' altro.
> E' verissimo che i dati ospedalieri sono molto curati e protetti, sia
> che risiedano su Accewss o qualche altro database.
> Non si puo' accedere facilmente ad essi. Bisogna avere dei permessi
> speciali.
non è questo il punto.
la gestione dei dati sensibili richiede come minimo che le credenziali
di accesso siano personali e gli accessi siano tracciati. un database
access non lo permette, tutto qua.
> Ma se lo inizi ad usare solo come front-end e reportistica con la
> parte dati attaccata magari a SQL, escono fuori anche belle
> applicazioni, non di moda, ma comunque robuste e ben funzionanti.
concordo. come front-end (magari i dati stanno su SQLserver) e' ottimo.
Vuol dire che la legge prescrive che il prodotto database vero e
proprio deve avere queste caratteristiche, o piuttosto fa riferimento
al prodotto software nel suo complesso (db+altro)?
Non penso sia molto difficile aggiungere quelle caratteristiche
esternamente ad Access.
E poi db come SQL server express o Oracle express le hanno? Ho qualche
dubbio.
credo che sia discretamente difficile invece.
il responsabile della gestione dei dati personali deve garantire che la
gestione sia adeguata, per questo non � che si pu� mettere ad
"inventare" di fantasia. la microsoft indica determinate sue soluzioni,
la oracle idem, se si vuole restare nell'ambito della legalit� si adotta
una di queste.
> E poi db come SQL server express o Oracle express le hanno? Ho qualche
> dubbio.
sql server express, ad esempio, mi risulta supporti a pieno
l'autenticazione windows, in ogni caso se ti servono caratteristiche
della versione enterprise vuol dire che devi prendere la versione
enterprise.
> la gestione dei dati sensibili richiede come minimo che le credenziali di
> accesso siano personali e gli accessi siano tracciati. un database access
> non lo permette, tutto qua.
>
Anche in Access � possibile profilare le login per l'accesso ai dati, e
aggiungere anche l'audit � facile.
Non credo che questo aspetto sia bloccante quindi.
Scusa come fai a dire ad access di loggare tutti gli accessi, eventi e
tentativi di accesso non autorizzato ?
Oltretutto il problema è che il DB è sostanzialmente un file fisico
esposto in sharing ai client.. come fai a sapere se uno di quei client
ti scarica l'intero mdb ? O se un amministratore di rete te lo scarica
o se uno sviluppatore lo fa.
Non metto in dubbio che "si potrebbe fare" anche con Access, ma io un
documento programmatico non te lo firmerei se l'applicazione usa
Access, non mi prenderei mai la responsabilità (e considera che siamo
nel mio campo, non parlo per sentito dire).
>> la gestione dei dati sensibili richiede come minimo che le credenziali
>> di accesso siano personali e gli accessi siano tracciati. un database
>> access non lo permette, tutto qua.
>>
> Anche in Access è possibile profilare le login per l'accesso ai dati, e
> aggiungere anche l'audit è facile.
> Non credo che questo aspetto sia bloccante quindi.
l'aspetto bloccante è che all'utente tu devi dare *comunque* permessi di
accesso al file mdb su file system, cosa che espone al rischio evidente
che l'utente se lo possa prelevare e/o armeggiare a piacimento aggirando
le policy. senza parlare poi della crittografia.
> l'aspetto bloccante � che all'utente tu devi dare *comunque* permessi di
> accesso al file mdb su file system, cosa che espone al rischio evidente
> che l'utente se lo possa prelevare e/o armeggiare a piacimento aggirando
> le policy. senza parlare poi della crittografia.
>
Vero, a questo non ci avevo pensato.
Ma se metti la soluzione su un terminal server hai risolto... :-)
> Scusa come fai a dire ad access di loggare tutti gli accessi, eventi e
> tentativi di accesso non autorizzato ?
>
Mascherina con codice dietro fatta sopra un gruppo di lavoro?
--
I fatti mi cosano
La soluzione tirata per i capelli si trova sempre, ma io non te lo
firmerei. Anche perché poi lo voglio vedere quel perito del giudice
quando legge che i dati erano salvati in un file Access che relazione
fa.
E' sempre il vecchio detto, non succede mai niente, ma se succede devi
dimostrare di aver preso tutte le contromisure per prevenire la fuga
di dati, allora perché sbattersi di più se c'è sqlserver ?
> Premesso che penso che usare Access in campo di dati sensibili sia
> quantomeno abberrante come idea, non si può risolvere la cosa esportando
> Access tramite sorgenti odbc?
> Quando nel protozoico lavoravo nel campo assicurativo mi pare avessimo
> risolto così un problema simile.
> M
>
Allora, giusto martedì di avrò una riunione con i rappresentanti dei
servizi informatici di ospedale. I quali sono in conflitto coi servizi
informatici di università (le cose non dovrebbero essere così ma non le
ho inventate io). Per cui di da al caso che i medici abbiano due
computer sul desk, uno collegato alla rete di ospedale, l'altro alla
rete universitaria.
Succede normalmente che per delle piccole statistiche gli istituti si
creano database propri (in Access) e fanno le statistiche su quelli.
Però facendo così c'è una enorme ridondanza di dati, se tutti gli
istituti del dipartimento fanno i cazzi propri, ed hanno dati che sono
moltissimo correlati tra loro, specialmente se si vuole studiare
l'andamento di certe patologie, che sono connesse tra loro.
Se si vuole fare del 'data mining' serio per ricerca scientifica,
secondo me si taglierebbe la testa al toro ottenendo delle copie dai
servizi informatici di ospedale copiando/esportando i database (oppure i
risultati SQL) che risiedono su sistemi professionali enormi, già
collaudati e contengono tutto il percorso clinico del paziente,
dall'ammissione al pronto soccorso fino alla dimissione) e
'anonimizzandoli' cioè oscurando magari con XXXXXX,, YYYYY etc. i campi
dei dati anagrafici (nome cognome, codice fiscale).
A quel punto si possono fare tutte le ricerche che si vuole senza problemi.
Nella prossima riunione proporrò proprio questo.
> Anche in Access possibile profilare le login per l'accesso ai dati, e
> aggiungere anche l'audit facile.
> Non credo che questo aspetto sia bloccante quindi.
>Non metto in dubbio che "si potrebbe fare" anche con Access, ma io un
>documento programmatico non te lo firmerei se l'applicazione usa
>Access, non mi prenderei mai la responsabilità (e considera che siamo
>nel mio campo, non parlo per sentito dire).
Considerando che la quasi totalità degli applicativi medici che gestiscono
dati sensibili usano JetEngine pare che le tue preoccupazioni risultino
infondate :-)
>l'aspetto bloccante č che all'utente tu devi dare *comunque* permessi di
>accesso al file mdb su file system, cosa che espone al rischio evidente che
>l'utente se lo possa prelevare e/o armeggiare a piacimento aggirando le
>policy. senza parlare poi della crittografia.
Quanti applicativi che girano RDBMS acclamati come Oracle, SQLServer o DB2
che conosci usano i livelli di permission offerti dai rispettivi RDBMS? :-)
> Premesso che penso che usare Access in campo di dati sensibili sia
> quantomeno abberrante come idea,
Ok, ma era per parlare... :-)
> non si può risolvere la cosa esportando Access tramite sorgenti odbc?
> Quando nel protozoico lavoravo nel campo assicurativo mi pare avessimo
> risolto così un problema simile.
>
Che tradotto immagino vuol dire mettere le tabelle su SQL Server e tenere in
Access le tabelle collegate.
Cosa appunto fatto da vari sw che per l'appunto usano Access alla fine solo
come front-end e reportistica.
E funziona fra l'altro!
> E' sempre il vecchio detto, non succede mai niente, ma se succede devi
> dimostrare di aver preso tutte le contromisure per prevenire la fuga
> di dati, allora perch� sbattersi di pi� se c'� sqlserver ?
>
Si si per carit� era per parlare, uso sql server ad anni ormai e non
tornerei mai indietro, sia come robustezza sui dati, sia come godibilit�
nello sviluppo e tuning della parte che ci gira sopra.
Si, è anche pieno di gente che non paga le tasse, ruba o si fa i suoi
affaracci sulle spalle dei poveracci. Io però cerco di lavorare dove
si rispetta la legge ed a mia volta cerco di farlo, sarà per quello
che raramente ho avuto problemi con i clienti.
PS: tutti possono fare tutto, ma quando poi ti fanno un assessment sul
software o c'è una contestazione o un auditing a seguito di una lite o
perché vuole entrare un'altro fornitore la figura da peracottaro ce la
fai te, e io voglio avere il culo coperto visto che culo e faccia sono
i miei.
Quando invece sono i tuoi puoi fare quel che preferisci, puoi usare
anche i file di testo in webdav pubblico per me...
>PS: tutti possono fare tutto, ma quando poi ti fanno un assessment sul
>software o c'è una contestazione o un auditing a seguito di una lite o
>perché vuole entrare un'altro fornitore la figura da peracottaro ce la
>fai te, e io voglio avere il culo coperto visto che culo e faccia sono
>i miei.
Quindi immagino che le tue appliazioni facciano estensivo uso dei meccanismi
di security e permission offerti da SQLServer. Te lo chiedo perchè nella mia
quasi esperienza (per la cronaca ho fatto tutte la beta di SQLServer dalla
4.2 a Denali) le applicazioni sviluppate in Italia che ne fanno uso (della
security intendo) non ne ho viste molte. La maggior parte non usa manco
l'autenticazione integrata e tantissime usano un solo utente, sa.
Mai usato sa per gli applicativi (che hanno diversi livelli di
security, di DB, di SO, applicativa, di framework ..), la pwd di SA ce
l'ha l'SA che la cambia periodicamente, gli sviluppatori quella di
sviluppo, l'applicativo che fa stampe è in sola lettura senza exec
ecc. Solitamente faccio applicativi web quindi uso un utente solo per
connettermi da applicativo e poi filtro i dati e le funzioni a livello
applicativo ma l'utente in questione ha i diritti giusti e sulle
tabelle giuste non di più.
Se devi esporre i dati direttamente la mappatura fine sugli oggetti si
realizza bene con activedirectory (ex i fogli excel che si connettono
direttamente a sql e scaricano dati ) ed ovviamente hanno grant solo
sulle tabelle (disaccoppianti) e le stored che devono vedere.
con diverse modalità e diversi pattern direi tutti.
Ad ogni modo se io fossi l'OP opterei quantomeno per un RDBMS vero come
ad es postgresql per metterlo in comunicazione con VB$qualcosa tramite
ODBC.
Se parte da zero e le sorgenti dati sono cmq così tanto frammentarie
male non gliene fa. Inoltre dubito che Access in qualche modo riesca sul
serio a velocizzargli il lavoro.
> la gestione dei dati sensibili richiede come minimo che le credenziali
> di accesso siano personali e gli accessi siano tracciati. un database
> access non lo permette, tutto qua.
No, non è così semplice. La legge richiede l'esistenza di UN sistema
di autenticazione e autorizzazione, non che ce ne sia uno per ogni
applicativo esistente. In pratica, in ogni rete informatica dove c'e'
un AD dal punto di vista dei requisiti di legge minimi sei già a
posto, puoi usare access o quello che ti pare. Se poi sia *opportuno*
usarlo è tutto un altro paio di maniche...
bye!
La legge da delle indicazioni minime, ma prescrive che tu abbia fatto
tutto il necessario per prevenire il furto dei dati, per proteggerli.
In caso di contestazione cosa pensi che scriverà il perito del giudice
di un sistema dove il database (oltretutto sconsigliato per quel
genere di utilizzo) è accessibile su cartella condivisa da tutti i
client ?
beh è quello che più o meno dico io, non ho detto che ogni applicativo
debba avere il proprio sistema di autenticazione/autorizzazione.
diciamo che io mi spingo un po' oltre nella valutazione e più che
parlare di opportunità parlo di applicabilità. cioè il fatto che ci
sia un sistema di autenticazione/autorizzazione nella rete ma non sia
nella pratica applicabile ad un determinato repository di dati
sensibili a mio avviso pone il problema di rispetto dei requisiti di
legge.
Già, ma... vedi sotto.
> > E poi db come SQL server express o Oracle express le hanno? Ho qualche
> > dubbio.
>
> sql server express, ad esempio, mi risulta supporti a pieno
> l'autenticazione windows, in ogni caso se ti servono caratteristiche
> della versione enterprise vuol dire che devi prendere la versione
> enterprise.
Appunto. Alla fine risulta che, se si vuole ottemperare alle norme, è
necessario adottare prodotti "enterprise" dal costo di svariati
migliaia di euro, come minimo.
Questo volendo evitarsi i "mal di testa" di implementare da soli le
caratteristiche mancanti, usando prodotti gratuiti tipo versioni
express di Oracle e Sql server, Firebird (forse pure Postgresql e
Mysql).
Mi sembra un aspetto da sottolineare, con la matita rossa.
Se non sbaglio è pari pari la stessa cosa per Sql server, Oracle non
ricordo.