Newsgroup: it.comp.lang.visual-basic
Titolo: Piccola idea, ma non ho la soluzione

Mi balenava in testa l'idea di rendere autoinstallante una serie
di script msde, quindi puri comandi sql.
Ok, oggetti sql server, dll e connessioni varie, apri il dts e
fai le tue belle chiamte. Su questo non ci sono dubbi, ma volevo
fare una cosina del tipo, ci associo un file, e il mio bel programmino
legge e passa le istruzioni al programmino che si preoccpa
di eseguirle sul db di turno.
Il punto č che ... un bel file in chiaro non avrebbe un gran che senso
se devo andare a fare in modo che il codice delle procedure e
dei trigger sia nascosto ... quindi il dilemma č ... come fare.
Se compilo un file di testo dentro all'eseguibile, mi tocca ogni
volta ricompilare se modifico.
Se cripto il file da fuori ... non sono sicuro che nell'uncripting
qualcosa vada a puttane ... senza contare il maggior tempo
di esecuzione.
L'unica soluzione decente che mi veniva in mente era quella di
zippare il file e proteggerlo con password. A quel punto il
file dentro č in chiaro e quanto unzipparlo ed eseguire le istruzioni.
Francamente non mi viene in mente altro e l'ultima soluzione mi
pare anche la piů pulita, ma magari a voi ne vengono in mente
altre.
-- 
Saluti
Andrea Moro

dei trigger sia nascosto ... quindi il dilemma è ... come fare.
Francamente, se io fossi il proprietario dei dati mi incazzerei
non poco se tu cercassi di nascondermi gli oggetti del database.
-- 
ciao, hal

 ha scritto nel messaggio
news:5597kvch43p7r2p8b...@4ax.com


Credo che hai frainteso il fine ultimo del mio task.
Invece ho capito benissimo. La mia osservazione forse dipende dal
fatto che lavoro con clienti ai quali documento tutto e ai quali
lascio quasi sempre i sorgenti e, anzi, quasi mai sono dba, quindi
ha accesso ai dati molto meglio il cliente di me.
-- 
ciao, hal

Mmmmm ... i sorgenti non li lascio per il semplice fatto che
non sono stati pagati. Hanno voluto il prodotto e stop.
Il trigger o le procedure si, trattano i dati, ma chiaramente
si limitano a trattarli secondo quando concordato nelle
specifiche tecniche di realizzazione.
Quindi se vuoi sapere come li tratto paghi ... il perchè li
tratto lo sai già ....
Se ti colleghi come dba, vero puoi sapere tutto a patto che
non hai usato la formula with encryption durante la creazione
dei tuoi oggetti.
In tal caso se tenti di editare un qualsiasi oggetto vedi tanti
bei caratteri a cacchio, ma non lo script.
Vero che sembrerebbe qualcuno sia riuscito a decriptare
gli script ... ma sempre del lavoro in più che eventualmente
andrebbe fatto ... e se lo fai ... problemi tuoi.
E poi scusa, lo stesso problema non ti si pone con i sorgenti
vb? Lasci anche quelli ai tuoi clienti??? Tutti sono così
generosi da pagarti per lo meno il triplo del costo del programma
stesso?
Se fai un conto con il mio ... 7.000 euro ... * 3 ... uhmmm non
penso che gli sarebbe piaciuta la cosa.
-- 
Saluti
Andrea Moro

penso che gli sarebbe piaciuta la cosa.
Il valore del software e' relativo, dipende da come funziona e da cosa
risolve, a volte consegni un eseguibilino da 45 KB e lo fai pagare
(non io, ma l'azienda per cui lavoro, io sono solo un povero travet)
2500 euro ;-)
-- 
ciao, hal

non era meglio cercare di dare una soluzione al problema senza
filosofeggiare sul perchè lo debba fare? saranno c***i suoi se
vuole/deve criptare/nascondere script, trigger e quant'altro??? io sono
convinto di sì
personalmente ho avuto questa necessità, le prestazioni non vengono
granchè penalizzati, dipende dal sistema di encription.... volendo te lo
puoi fare anche tu
cmq io ho usato dei file criptati alla creazione e decriptati
all'occorrenza on-the-fly.... l'algo è sempre quello ....
ciao
Mirko Parisi
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

convinto di sě
Ripeto, se io fossi il padrone dei dati col cavolo che mi cripterebbe
l'sql: cambierei fornitore (gia' successo ;-).
-- 
ciao, hal

 l'sql: cambierei fornitore (gia' successo ;-).
Beh, dai...
Le stored procedure possono essere considerate delle estensioni del codice
VB.
Anzichč eseguire x cose da applicativo client, il client chiama una SP sul
server. Per questioni di performance, supponiamo.
Beh, a questo punto, se il cliente non ti ha pagato i sorgenti, non vedo
perchč tu sia tenuto a dargli le SP.
O, meglio, sarebbe corretto dargliele se sono, ad esempio, schedulate o
attivate da trigger, perchč in questo caso sono parte integrante della base
dati, e devono quindi essere manutenute dal system administrator.
Ma se sono parte della logica applicativa, ad esempio se esegui un insert
usando una sp anzichč un insert complicato da VB, a questo punto io le
considero parte integrante del codice dell'applicativo. E, cosě come compilo
l'applicativo e non fornisco i sorgenti, cosě uso il with encryption e
cripto le SP.
Tre anni fa ho sviluppato un applicativo in cui tutta la parte di
elaborazione vera e propria avveniva da SP. Diciamo che il client era una
semplice consolle di inserimento dati e parametri. Poi partiva una serie di
SP di dimensioni spropositate, che sostanzialmente risolvevano un classico
Travelling Salesman Problem applicato alla produzione industriale.
Praticamente il 90% del lavoro era stato lě.
Il cliente non mi aveva pagato il codice, e io le SP le ho criptate, altro
che.
Ciao
Alberto

 2500 euro ;-)
Dipende dalla faccia da cXXo o da caXXo che uno si ritrova ;)
Io faccio pagare le ore di sviluppo.
Perň tanto il problema non č che lo abbiamo risolto. ..
Ciao
Andrea

Esattto ... stessa situazione ... cioč le procedure di gestione
di insert, delete, update e combinazioni varie le ho fatte su sp
per questioni di performance.
-- 
Saluti
Andrea Moro

 Se ti si blocca paghi il contratto di assistenza e io corro ... :)
non basta correre. devi letteralmente nuotare.
forse, se c'č abbastanza spazio per atterrare, potresti usare l'elicottero.
in alternativa puoi passare il resto della tua vita in crociera.
morale della favola: a volte č meglio che sia il cliente ad occuparsi
dell'assistenza.
Salutoni
Sergio

Dipende dalla faccia da cXXo o da caXXo che uno si ritrova ;)
LOL, non se ne ha mai abbastanza, credimi ;-)
-- 
ciao, hal

 dell'assistenza.
Si, se fosse un prodotto cotto e mangiato, laddove tu lo dai e finisce
la cosa perchè deve fare operazioni cretidiote tipo immagazzinamento
dati e stop. E chiaramente il programma è consolidato, ovvero non
potrà mai avere nulla e nessun aggiornamento aggiuntivo poichè allo
stato dell'arte per quel singolo problema.
Ma se come nel mio caso è un software in evoluzione, almeno per
il momento, perchè ricevo richieste continue da parte del cliente di
aggiornare e modificare cose e cosine, farlo fare a lui si mi risolverebbe
il problema e la rogna di doverci andare, ma contemporaneamente
potrebbe voler dire che se toppa qualche cosa devo sempre andare
e invece di fermarmi 10 minuti per l'aggiornamento mi fermo x ore
per soccombere allo sputtanamento.
Vedo meno rompiballs la prima soluzione.
Ciao
Andrea

Vedo meno rompiballs la prima soluzione.
Se cerchi di curare meglio che puoi le fasi di analisi, collaudo e
deployment, riesci a ridurre al minimo gli inconvenienti.
Poi, e' chiaro, gli imprevisti ci saranno sempre, dipende quanto ti
sei attrezzato per risolverli. Ad esempio, il poco software che ho
scritto e' predisposto per loggare su file tutto quello che fa, e
questo facilita molto la soluzione di eventuali anomalie.
Capisco che per avere i sorgenti il cliente deve pagare di piu', su
questo non dubito. Ma penso anche che il cliente abbia tutto
l'interesse a far toccare i sorgenti solo al fornitore, a parte le
emergenze, dove hai dieci minuti di tempo per far andare
un'applicazione bloccata e che *deve* andare.
-- 
ciao, hal

 un'applicazione bloccata e che *deve* andare.
Io la vedo diversamente. Il cliente ha sorgenti ... fantastico.
Il lavoro che hai sviluppato per lui è su commissione. Metti che
non hai fatto nessun tipo di contratto con il tizio, il quale a quel
punto con il sorgente ci fa quello che vuole ivi compresa la
possibilità di farlo vedere a terzi, rivenderselo e via dicendo.
Mica bella come prospettiva.
O peggio lo fa vedere al programmatore di turno che non
capisce una sega, ti cambia un paio di variabili e ti manda
a troie tutto quanto. Sai su un programma che oggi conta
55.000 righe di codice senza commenti è difficile ritrovare
poi la variabile aggiunta che ti incasina il tutto ...
Ma poi, perchè ci deve mettere le mani sopra un altro ...
magari l'altro è l'incompetente di turno che ti si mette pure
a criticare le tue scelte che non sà nemmeno perchè le hai
fatte - perchè non si legge i commenti - o perchè non ha
l'esperienza giusta per valutare il percome e il perchè di
tali tue scelte. ....
Tutta na catena ....

tali tue scelte. ....
Se il tuo programma rispetta le specifiche e funziona, mentre le sue
modifiche non vanno, allora puo' criticare quello che vuole ;-)
-- 
ciao, hal

 modifiche non vanno, allora puo' criticare quello che vuole ;-)
Si certo ... non era il dubbio sul ricevere la critica, più che altro
era dare del lavoro magari al pirla che scopiazzando qua e la
usufruiva di pappa pronta per altri suoi progetti magari ... la cosa
mi roderebbe non poco il chicchero.
Ciao
Andrea

mi roderebbe non poco il chicchero.
Quello e' inevitabile: prima o poi capita di mettere le mani in
software scritto da altri (a me, spessissimo), ma fa parte del
mestiere.
E poi...
perche' rispondi alle richieste di aiuto sul ng, allora? ;-) 
-- 
ciao, hal

 perche' rispondi alle richieste di aiuto sul ng, allora? ;-)
Controsenso lo so ... ma li il codice non mi è stato ciurlato ;)
Quindi sò che sto aiutando - forse- qualcuno a capirci più
di quanto può per poi un giorno diventare meno pirla :))
E' una catena .... un vortice ... chiamalo come ti pare ...
Ciao
Andrea

E' una catena .... un vortice ... chiamalo come ti pare ...
Se e' un trenino lascio a te la parte della locomotiva :-PPP
-- 
ciao, hal

Che fa, hai visto delle mie foto per caso ;))
-- 
Saluti
Andrea Moro