Newsgroup: it.comp.lang.delphi
Titolo: [OT]Procedure Firebird

Ciao a tutti,
sono passato da SQlServer a Firebird con D7, volevo chiedere una cosa
abbastanza banale :
Ma in Firebird non č possibile criptare le procedure ?
Cioč se scrivo delle Stored Procedure e qualcuno si frega l' FDB chiunque
puň
vederele, copiarle o modificarle ?
Se č cosě non č proprio il massimo.
Ciao

 Ma in Firebird non è possibile criptare le procedure ?
So che in Firebird è possibile far "compilare" le procedure in BLR ed
eliminare il codice sorgente.  Chi ti frega l'FDB non può quindi vederle.
Non chiedermi però come si faccia, non lo conosco abbastanza bene.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Ciao
La procedura di eliminazione del sorgente dal DB permette di lasciare nel
medesimo solo il compilato.
La procedura non è esente da rischi!
Non credo però che chi freghi un FDB se ne faccia molto, soprattutto se
l'applicazione è molto complessa. In questo caso le business rules non
dovrebebro essere nel database....
Le stored in fin dei conti sono solo delle sequenze batch di comandi o
delle complesse query (SP di tipo select)
Assieme a trigger ed eccezioni possono aiutare nella gestione
dell'applicazione, ma il cuore dovrebbe poi essere in un eseguibile....
Andrea

 ha scritto nel messaggio
news:hw4n4wyymjcv$.jwi3m336xnsi.dlg@40tude.net...


 dovrebebro essere nel database....
Dissento in toto.
-- 
Ciao
Marco Kregar
marco....@FirebirdSQL.it
www.FirebirdSQL.it
"over the bench the goat sings, under the bench the goat dies"

Per eliminare il sorgente delle procedure:
update rdb$procedures r
set r.rdb$procedure_source=''
E' cmq possibile fare un backup/restore anche senza il sorgente
delle procedure.
Ovviamente conservati una copia del database con le procedure... :-)


 ha scritto nel messaggio
news:41f97d1f$0$8207$5fc...@news.tiscali.it...


 
-- 
Alberto Salvati
A NEAPOLITAN Delphi Developer who is studying c# and .net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso"

> imho, dipende dal modello. Se sviluppa su modello MDA... :)
credo che MDA tenda a separare la business logic e la application
logic dalla sottostante piattaforma tecnologica, ma continui fermamente
a sostenere che esiste una business logic ed una application logic,
se ci riferiamo ad una applciazione client/server o two tier, di cui
in sostanza tratta questo thread, allora considero una scelta migliore
porre la business logic quanto piu' possibile all'interno del database,
ma certo di idee rivoluzionarie e rivoluzionanti, ne saltano fuori
almeno un paio all'anno e purtroppo o per fortuna nel nostro mestiere
i profeti sono pochini....
-- 
Ciao!


 i profeti sono pochini....
pardon, non so interpretare il tono di questo paragrafo.
Che ogni giorno spunti un profeta sbandierando metodologie nuove e 
mettendo alla gogna il preesistente non è una novità.
Quello che ci tocca è essere abbastanza svegli da discernere, abbastanza 
ecclettici da prendere il meglio da cio che tentano di propinarci e 
abbastanza lungimiranti dal capire quale metodologia potrebbe essere la 
+ adatta a seconda di cio che ci tocca fare.
A tal proposito ma ha molto colpito una cosa letta qui:
http://www.amazon.com/exec/obidos/ASIN/0201616416/qid=1107005348/sr=2-1/ref=pd_ka_b_2_1/102-3300031-1285730
scritta da un tal Mohammad B. Abdulfata
