Newsgroup: it.comp.lang.delphi
Titolo: componenti dbExpress e Interbase insieme su Firebird 2.1.5

Buongiorno,
 
su una applicazione esistente, realizzata con D.2010 e Firebird 2.1
mediante componenti dbExpress / Provider / ClientDataSet,
avrei la necessità di ricevere gli eventi su alcune tabelle.
 
Ho risolto con i componenti Interbase, ma vorrei ricevere conferma di aver operato nel modo corretto.
 
Ho fatto così:
nel TModule (dove ci sono gli altri componenti dbExpress) ho messo anche:
- 1 IBDatabase
- 1 IBTransaction
- 1 IBEvents
 
Quando applico gli aggiornamenti faccio così:
ClientDataSet.ApplyUpdates(0);
IBTransaction1.CommitRetaining;
 
.. e ottengo giustamente l'evento atteso.
 
 
Il dubbio è: in locale tutto bene, ma in rete LAN con altri 25 Client, sarà lo stesso?
 
ringrazio per l'attenzione.
---
Giovanni Fantuzzi
 
 
 
 

 sarà lo stesso?
 
Ma tu lo hai provato?
 
 
A.

 Ma tu lo hai provato?
sulla rete aziendale no, prima di fare casini anche involontari ci penso 100 volte.
 
---
Giovanni

In alternativa, se il metodo sopra dovesse creare problemi, pensavo di creare sul server Firebird un trigger che invece di postare un evento, mi recupera gli utenti e per ciascuno mi riempie una tabella ad hoc con la notifica del caso.
 
Lato client, periodicamente andrei a cercare eventuali notifiche, mostrando un avviso all'utente e dopo "spuntandole" come lette.
 
Tuttavia in questo caso non saprei come recuperare gli utenti registrati dal server di Database.
 
---
Giovanni

Se hai una TSqlConnection ed una TIBConnection hai 2 diverse connessioni al database. 
Questo vuol dire che ogni utente usa 2 diverse connessioni. Ergo, se hai 100 utenti, avrai un server con 200 connessioni. 
Questa cosa potrebbe non essere un problema per FB, ma meglio precisarla.
Se si trattasse di un db a pagamento tipo Oracle o db2, questa tua soluzione sarbbe inapplicabile, visto che i prezzi delle licenze di prodotti del genere si basano anche (ma non solo) sul numero di connessioni attive in contemporanea.
 
Poi, molto dipende dalla ovvia (ma non per tutti) domanda:
a cosa ti serve sapere che qualcosa e' cambiato sul database?
 
Infine, riguardo il tuo "non-tentativo", non vedo xche altri dovrebbero rischiare di "incasinare" i loro sistemi per verificare se la soluzione al TUO problema funziona senza fare danni. 
L'intenzione non e' ovviamente fare il test su un database di produzione...
 
Presumo e spero che tu abbia un ambiente di test o quanto meno un database firebird per delle prove veloci da usare con qualche applicazione di test giusto per vedere cosa succede.
 
A.
 
 
 
 

 Presumo e spero che tu abbia un ambiente di test o quanto meno un database firebird per delle prove veloci da usare con qualche applicazione di test giusto per vedere cosa succede.
 
il mio ambiente di test è un portatile. Non è molto, lo so, ma finora è stato sufficente.
 
Ti ringrazio per l'attenzione.
---
Giovanni
 

 il mio ambiente di test è un portatile. 
 
Un solo pc, per una qualsiasi app multiutente NON E' UN AMBIENTE DI TEST.
 
Tornando al tuo problema, la butto li, ma tieni conto che e' lunedi...:
 
 
1) le tabelle coinvolte hanno dei trigger
 
2) i trigger alimentano una tabella di notifiche che va un testo, un id, data e ora, un campo" tipo notifica" ed un campo di stato (-1=indefinito 0=da processare 1=processato). 
Nel db esiste una tabella che mette in relazione i tipi di notifica con gli utenti (user4notifytpe). Questa tabella include un campo per un indirizzo email. 
 
3) hai una service application che ogni n unita di tempo configurabili e non cablate fa una query sulla tabella delle notifiche leggendo M record aventi il flag di stato pari a zero, con M configurabile e non cablato. Per ogni notifica ne legge il tipo e per ogni tipo interroga user4notifytpe per leggere la lista degli utenti coinvolti. Per ogni utente coinvolto prepara un testo al quale viene accodato almeno il testo della notifica che sta processando.
 
6) Etichetti la notifica come processata
 
7) Alla fine del ciclo avrai X testi, dove x e' il numero di utenti coinvolti nelle notifiche che sono state processate. Questi testo li salvi in un apposita tabella che oltre al relativo campo avra ovviamente (ma non per tutti) un ID, il nome dell'utente destinatario, i della notifica ed un flag (-1=indefinito 0=da inviare 1=inviato). 
 
A questo punto, interrogando questa tabella puoi far inviare alla stessa service application una mail ad ogni utente. A fronte dell'invio della mail etichetti il record con stato pari a 1 = (inviato). Trattandosi di un testo che potrebbe essere non breve, Il popup lo eviterei: ci pensa il client di posta a fare beep o altro per far capire che e' arrivata una email.
Per semplicita', l'invio puo farlo la stessa service application.
 
La service application all'avvio legge SOLO i parametri di connessione al db, i tempi di polling e i numeri max di record da processare.
 
Invece, gli utenti da notificare li legge ad ogni operazione e non all'avvio. Il perche' di questa cosa e' scontato e non insultero' il tuo QI dando ulteriori spiegazioni.
 
A.

 Il dubbio è: in locale tutto bene, ma in rete LAN con altri 25 Client, sarà lo stesso?
 
Se parliamo di accesso tradizionale ai dati, con selezione di record, inserimento, modifiche e cancellazioni - visto che fai uso del componente *TClientDataSet* - non vedo grossi problemi: la connessione e apertura di una transazione per rendere persistenti le modifiche avviene solo quando fai ApplyUpdates(); in tutti gli altri momenti (se hai fatto le cose per bene) non è presente una connessione fisica attiva al database per cui non consumi risorse sul server che ospita il DB e puoi supportare un ampio numero di utenze senza problemi.
 
Il fattore che preoccupa è l'intercettazione di quell'IBEvent: cosa fai quando lo ricevi? Se l'operazione è pesante, può accadere che aggiornamenti fatti da più utenti inneschi un pesante utilizzo del DB in risposta all'evento che segui e vada a inficiare pesantemente le prestazioni.
 
Come è stato suggerito da altri utenti, se possibile, io adotterei misure diverse. Magari spiega con precisione cosa fai con quell'evento...
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
#Home: 
http://bit.ly/marcobreveglieri
 
#Blog: 
http://bit.ly/compilaquindiva