Newsgroup: it.comp.lang.delphi
Titolo: TAdoConnection (e simili) e Connected a design-time

Mi sembrava che ne avessimo già discusso in passato, ma non riesco a 
trovare niente.
Quando lavoro con un db semi-embedded (per esempio su un mdb), 
generalmente lo tengo nella cartella dell'eseguibile, in modo da poter 
fare, nella creazione del DataModule,
const
   sConnStr: String = 'Provider=Microsoft.Jet.OLEDB.4.0;Data 
Source=%sdata.mdb;Persist Security Info=False';
...
   sAppPath := ExtractFilePath(ParamStr(0));
   if dbConn.Connected then dbConn.Connected := False;
   dbConn.ConnectionString := Format(sConnStr, [sAppPath]);
   dbConn.Connected := True;
Il problema è che spesso e volentieri a design-time mi dimentico, prima 
di compilare per l'ultima volta, Connected = True sulla connessione (a 
onor del vero spesso ci sono alcuni componenti che la attivano 
automaticamente), con conseguente errore di file non trovato (e figura 
non proprio bella) quando eseguo il programma dal "cliente"... 
soluzioni, a parte cambiare cervello?
-- 
Jax

 soluzioni, a parte cambiare cervello?
Purtroppo non me ne viene in mente un'altra oltre a quella di accertarsi 
che la connessione sia chiusa a designtime; purtroppo, essendo la 
/ConnectionString/ così come la proprietà /Connected/ impostate in fase 
di caricamento dal modulo (con i valori prelevati dal DFM) non ci sono 
molte possibilità.
Sarebbe interessante avere una proprietà simile alla 
/AllowStreamedConnection/ dei componenti *IBX*, che impedisca di 
prendere in considerazione il valore della proprietà /Connected/ durante 
lo streaming del DFM con il suo caricamento.
Eventualmente, potresti valutare la creazione di un discendente del 
componente *TDatabase*, *TADOConnection*, *TXXXConnection* che stai 
utilizzado prevedendo, se possibile, questa funzionalità, e adottare il 
tuo componente per instaurare la connessione al DB.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 [...]soluzioni, a parte cambiare cervello?
A parte cambiare il cervello la vedo dura, ma potresti sempre compilare a
riga di comando, mediante file batch, anteponendo alla chiamata a dcc32
l'esecuzione di un programmino di sostituzione di tutti i "Connected =
True" nei .dfm in "Connected = False" ;-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 lo streaming del DFM con il suo caricamento.
Ancor più interessante sarebbe che i componenti venissero scritti
utilizzando come si deve la direttiva "stored" delle property ;-)


 utilizzando come si deve la direttiva "stored" delle property ;-)
Cosa c'è che non va nell'uso della direttiva *stored*?



Esistono gli eventi onBeforeConnect e onWillConnect: non vanno bene?
(Non posso provarli io direttamente, sorry)
Ciao
-- 
ACSH
[D4]
Chi fa da se', fatica il doppio 

 soluzioni, a parte cambiare cervello?
Molto semplice: unit ADODB, procedura PromptDataSource.
Ti si aprirà un mondo.
Ciao,
Andrea

 Ti si aprirà un mondo.
Io ho "scavicchiato"... non so se mi si è aperto o meno un mondo, ma non 
capisco dov'è la peculiarità... forse non ho guardato attentamente? :-|


 Esistono gli eventi onBeforeConnect e onWillConnect: non vanno bene?
This is THE solution.
procedure TdmData.dbConnWillConnect(Connection: TADOConnection;
   var ConnectionString, UserID, Password: WideString;
   var ConnectOptions: TConnectOption; var EventStatus: TEventStatus);
begin
   ConnectionString := Format(sConnStr, [ExtractFilePath(ParamStr(0))]);
end;
Grazie!!!!!
-- 
Jax

 Cosa c'è che non va nell'uso della direttiva *stored*?
Nella scrittura dei componenti di questo tipo, la proprietà Connected
dovrebbe avere "stored False" (stored è a True per default) in modo da non
essere memorizzata nel dfm, nonostante l'impostazione True a runtime.


 end;
Se la prendessi da file di configurazione, sarebbe ancora meglio ;-)


>[...] a runtime.
Errata corrige: a design-time.


 essere memorizzata nel dfm, nonostante l'impostazione True a runtime.
Non so, può darsi... per quanto mi riguarda, spesso mi ha fatto comodo, 
per questioni dimostrative o in altri casi meno problematici di quello 
presentato avere una connessione a *True*.
Secondo me, la soluzione del parametro /AllowStreamedConnection/ degli 
IBX, magari con un default a False, è quella più aperta e libera e che 
preferisco.
Ciao,
   Marco.


 Se la prendessi da file di configurazione, sarebbe ancora meglio ;-)
La stringa di connessione? Uhm...... si sa mai che vanno a 
paciugarmela... vai di hardcoded, che almeno so che se non funziona č 
colpa mia :)
-- 
Jax

 capisco dov'è la peculiarità... forse non ho guardato attentamente? :-|
Nel fatto che, in quel modo, problemi legati alla configurazione non
esistono più, perché la si può fare alla prima installazione,
salvarla su file di configurazione ed amen, problema risolto.
Certo, non è comodo come avere la connessione live a design time,
però ti risolve un mare di problemi in un modo molto, molto, molto
semplice e facilmente configurabile.
Ciao,
Andrea

 paciugarmela... 
Non sono d'accordo, se usi una password binaria(=non caratteri
alfanumerici) *SERIA* puoi decriptarla(tenendola in memoria e
fare un dump non è da tutti) come ti serve senza grosse
complicazioni.
Usando poi PromptDataSource, il tuo datasource può essere ndò te
pare, basta poco che ce vò? :D
Andrea

 presentato avere una connessione a *True*.
Per quella che è la mia esperienza, nella pratica, il fatto di avere per
default un Connected a True ha sempre e solo creato problemi.  Credo anche
per ragioni di principio, che una connessione vada esplicitamente
impostata a run-time.  E' escluso, ovviamente, che stia parlando di
progetti giocattolo o dimostrativi, ambito nel quale molte delle regole
che valgono normalmente decadono.


 paciugarmela... vai di hardcoded,
L'hardcoded va sempre evitato e comunque nel file di configurazione vanno
impostati i parametri della stringa di connessione.  La composizione della
stringa di connessione è sempre affidata all'applicazione.
Evitare che l'utente pasticci con la configurazione di un'applicazione,
d'altronde, è impossibile.


 Andrea
Ciao, Antò.

 Ciao, Antņ.
Ariciao, Antņ.

 d'altronde, č impossibile.
Beh, l'amputazione delle mani del cliente dopo che ha "giocato"
con i file dell'applicazione mandando tutto in malora,
potrebbe dare ottimi risultati!
:-)
IMO, hai ragione: un bel file INI (ancora di piů del Registro),
magari nascosto, č la soluzione piů versatile per questo tipo
di problematiche.
Ciao
ACSH


 potrebbe dare ottimi risultati!
Bah... ci si pone un problema inesistente (o perlomeno improbabile): molto
spesso il cliente non sa neanche che esiste un file di configurazione e
non avrebbe reale motivo di giocarci, mentre il file esterno è utile, nel
caso si voglia configurare un accesso particolare, in certe condizioni,
senza ricompilare il programma.  Insomma, il vantaggio di non avere roba
hard coded è evidente ed è uno dei concetti base che si impara dopo
qualche mese di seria programmazione ;)


 non proprio bella) quando eseguo il programma dal "cliente"... 
Riquoto questo messaggio solamente per segnalare che ho trovato un 
"entry" in Quality Central che tratta esattamente questo problema; per 
chi eventualmente è afflitto dal problema, interessato a proporre 
soluzioni o desideroso di "spendere" un voto, il link è questo:
http://qc.borland.com/wc/qcmain.aspx?d=30550


 "entry" in Quality Central che tratta esattamente questo problema;
La soluzione a quanto chiesto in quel messaggio "allow all
dataset/connection type VCL components to optionally not stream/save their
active/connected properties" si risolve *esattamente* con la corretta
impostazione della direttiva "stored".


 impostazione della direttiva "stored".
Ma che stress con questa *stored*...... :-/


 Ma che stress con questa *stored*...... :-/
Marco, sei stressato forse all'idea di non conoscere il significato e
l'uso di quella direttiva?  Se qualcuno chiede che nella VCL sia
implementato un meccanismo per consentire che le property vengano salvate
o meno, la risposta a tale richiesta è che quel meccanismo c'è *GIA'* ed è
implementato, appunto, mediante la direttiva stored.  Cerca di
convincertene ;)


 convincertene ;)
Non c'è nulla di cui io mi debba convincere.
Per quanto mi riguarda, la memorizzazione della proprietà /Connected/ è 
utile in determinati casi e una sua mancata memorizzazione forzata 
attraverso la direttiva *stored* seguita da False non mi piace, poiché 
personalmente preferisco di gran lunga avere una seconda proprietà, così 
come è stata introdotta nei componenti IBX (/AllowStreamedConnection/) 
che permetta di mantenere persistente a designtime lo stato attivo della 
connessione al database quando apro il Form o il DataModule su cui è 
presente la connessione (vedendo magari da subito i dati associati in 
una DBGrid, senza andare ad aprirmi manualmente a designtime la suddetta 
connessione, perdendo ogni volta tempo durante la progettazione), cosa 
che non è possibile disabilitando in modo definitivo lo "storage" della 
proprietà nel DFM; attraverso la seconda proprietà, poi, si ha la 
possibilità di prevenire che il componente apra, ma solo a "runtime", la 
connessione al DB.
Concludendo, il mio problema non è che ignoro completamente il 
funzionamento della direttiva *stored*...so come funziona e proprio per 
questo motivo, nel caso in esame, non la userei, privilegiando 
l'adozione di un'ulteriore proprietà che, almeno per quanto mi riguarda, 
è la soluzione che mi consente maggiore libertà di decisione su come 
gestire la connessione, sia a runtime che a designtime.
Miii... che fatica! x-)
Ciao,
   Marco.


 questa direttiva *stored*.
Io non "punzecchio" proprio nessuno, ma ci tengo a far sapere a chi non
conosce quella direttiva, che il modo di fare certe cose esiste già.
Il resto è solo un tuo problema ;)
<snip su tutto il polpettone restante di cui NON condivido una sola parola


   Marco.
Andrea

 utilizzare stored, ma questa è un'altra storia :D).
No, la tecnica che piace a me non ha nulla a che fare con *stored*.
Si tratta banalmente di controllare il valore della proprietà 
/AllowStreamedConnection/ nel metodo /Loaded/, solo a runtime, e in base 
a tale valore prendere in considerazione o meno l'impostazione eventuale 
a True della proprietà /Connection/ prelevata dal DFM.
Non ho sottomano Delphi, ma suppongo che i componenti IBX facciano più o 
meno in questo modo, e mi sembra una buona soluzione che mantiene la 
compatibilità all'indietro, permette connessioni persistenti a 
designtime ma, allo stesso tempo, consente di impedire che a runtime la 
connessione avvenga automaticamente dal DFM quando non lo si desidera 
(mettendo a False la /AllowStreamedConnection/).
Quanto al sostenere che non è bene utilizzare *stored*, è una cosa che 
non ho mai detto, se inteso nel "senso assoluto" del termine.
Chiarisco: dico che non ne farei uso in questo caso per risolvere il 
problema specifico, ma questo non vuol dire che io ritenga, in generale, 
negativo o deplorevole l'uso della direttiva *stored*.
Semplicemente, non la userei in questo caso.
Spero di aver spiegato bene il mio punto di vista, evitando altri 
"minicorsi" sulla direttiva *stored*. ;-)
Bye!
