Newsgroup: it.comp.lang.delphi
Titolo: Firebird - alcune domande di utilizzo  pratico

Buongiorno a tutti e grazie per le risposte ai precedenti messaggi.
Ho alcune domande da neofita di Firebird (ma in generale di DBMS)
1) Utilizzo cacheupdate: conviene ?
Avevo letto mesi fà che il problema della cache e che non permette di
eseguire lock ottimistico.
Premetto che comunque verrebbe usata all'interno di una transazione e che il
lock lo farei pessimistico (nel caso di master/detail) su il record
principale master.
Il dubbio è se conviene eseguire tutte le variazioni in memori.
Tutte per modo di dire xchè non posso pensare di
inserire/modificare/annullare tutte le righe di una fattura/ordine ecc. in
quanto oltre il tempo di trasferimento finale (meglio eseguire +
trasferimenti piccoli)  c'è il probelam di aggiornare x gli altri user
alcuni campi di accumulo.
Ma potrei eseguire la cache per tutte le operazioni che coinvolgono una riga
(aggiornamenti dati clienti/esistenze ecc) e solo se tutto ok (per i 4/5
record coninvolti)  mandare il tutto al server e chiudere la transazione in
vece che mandare il tutto al server DURANTE la trnsazione e poi magare
annullare il tutto.
2) Mi attira in alcuni casi il lock ottimistico (evito che uno user si beva
il caffè bloccando anche altri user) ma le domanda sono
a) oltre a segnalarmi che un record è stato variato durante la mia
trasnsazione da un altro utente mi dice anche quali field sono variati o
devo eseguire un controllo da programma salvando i valori originali in
variabili ed eventualmete confrontarli di nuoivo con quelli del record su
server)
b) se la transazione NON và a buon fine devo rileggere il record con una
where o la cosa è automatica ?
3) per sapere se un a where ha dato esito poistivo posso leggere recordcount
o questa mi carica tutta la query in memoria.
In altre parole recordcount torna 0 se non trovato nulla e 1 se ha trovato n
record opuure legge tutto il dataset per dirmi che ne ha trovati 1 milione ?
(esagero)
4) in caso i modifica o ricerca è vero che se seleziono solo i campi
interessati il tutto è + veloce xchè non trasferisce i record interi ?
5) per fare la modifica di un campo questo deve essere messo nella select ?
7) esiste un tool manager free/opensource/ abuon prezzo per eseguire
gestione DB (creazione tabelle comprese) che non sia rischioso come IBEasy+
1.2.2 o Marathon che sono carini ma nel fare le prove mi sono trovato con
tabelle eliminate senza volerlo o addirittura tutto il DB (sai che bello dal
cliente)
8) che differenza c'è tra un field float (ho sempre usato questi) e un campo
decimal o numeric e come si impostano e quanto spazio occupano ?
9) ultimo ma non meno importante : esistono documentazioni (anche
scaricabili a pagamento) per Firebird e relativo SQL) per capire anche cosa
e come usare sono i domains, trigger, views, procedure, generator,
exception, roels di FB) e soprattutto per cercare di stressarvi di meno ?
Per ora è tutto non odiatemi per favore - grazie

 Per ora è tutto non odiatemi per favore - grazie
-- 
Alberto Salvati
A *Neapolitan* delphi developer who is studing c# & .Net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso!"

 exception, roels di FB) e soprattutto per cercare di stressarvi di meno ?
Documentazione di IB6 in inglese  :
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_download_documentation
in particolare ti segnalo la developer guide.
Marco Kregar
marco....@FirebirdSQL.it
www.FirebirdSQL.it
"over the bench the goat sings, under the bench the goat dies"

 una where o la cosa è automatica ?
Non è atumatica.
ciao
  gabriele

Aiungo questo link di documentazione in italiano:
http://xoomer.virgilio.it/jkhaldi/db.html
-- 
Ciao!


scaricabili a pagamento) per Firebird e relativo SQL) per capire anche 
Trovi parecchia documentazione su 
www.ibphoenix.com
Luigi D. Sandon - D&amp;D Support Team
--- posted by geoForum on 
http://www.delphiedintorni.it

Oracle prevde gli indici bitmapped, specifici x casi di questo tipo.
Occhio agli indici bitmap di Oracle: sono efficienti nello storage ma
molto poco negli aggiornamenti: l'inserimento di valori richiede la
rigenerazione degli indici. Sono ottimi per il datawarehouse dove gli
inserimenti sono relativamente pochi ed effettuati ad intervalli precisi,
molto meno in applicazioni OLTP dove gli inserimenti sono molto frequenti.
