Newsgroup: it.comp.lang.delphi
Titolo: AARGH!!! DATABASE DEL XXXXX!!!!

@#$%$£!!!!!!
Sto uscendo pazzo PAZZO PaZzO!
Come cavolo si gestiscono i database in Delphi??????????
A che $&£/#&/£$ di %£"$&" servono i TDBBDBFanculoSet?!?!?!
PER FAVORE indicatemi qualche tutor in rete, qualche libro in libreria,
un pezzo di qualcosa che spieghi per esteso (il più possibile, vi prego)
la logica di tutta la baracca e come si fa a farla funzionare... :-((((
PRESTO prima che riformatto TUTTOOOOOO!!!!!!!

 Come cavolo si gestiscono i database in Delphi??????????
Che versione di delphi? e a quale tipo di db vuoi accedere?
Ciao, Antò.

 un pezzo di qualcosa che spieghi per esteso (il piů possibile, vi prego)


Calma!
Calma!
le prime volte con i db sono toste x tutti.
Prima di esplodere, xche non "condensi" tutti i tuoi dubbi
in qualche domanda mirata?
Cosa è che ti ha fatto inkazzare in questo modo?
Ti mancano le basi dei db relazionali o tozzi sull'accesso ai dati
vero e proprio?
Bye
AS
"Se è Microsoft non funziona"
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

"Belfagor" ha scritto nel messaggio
| PER FAVORE indicatemi qualche tutor in rete,
| qualche libro in libreria,
| un pezzo di qualcosa che spieghi per esteso
| (il piů possibile, vi prego)
| la logica di tutta la baracca e come si fa a
| farla funzionare... :-((((
|
Fundamentals of Database Development (with Delphi)
http://delphi.about.com/library/weekly/aa020601a.htm
Chapter one of the free Delphi Database Course for beginners.
--
Ciao.
ACSH
[D4]
---------------------------
Chi fa da se'
fatica il doppio

 vero e proprio?
Allora...
So cos'è una query, so cosa sono campi, record, indici e chiavi,
operazioni di selezione e proiezione... so creare un DB con
Access (non solo tabelle, anche query, maschere e report) e
modificarlo se non mi va come è fatto.
Adesso, io voglio fare una (semplice) agendina Delphi per vedere
come funzionano tutti quegli oggettini carini per i dati che stanno su
Delphi 5.0 Professional. Perchè ho in mente di usarli poi per un mio
progetto più grande. Un programmino tanto per esercizio insomma.
Ma qui cominciano i casini.
Per vedere i dati ho messo un DBGrid nella form principale (che è
pure l'unica), poi ho messo un TDatabase e un TDataset (perchè l'help
mi dice che ci deve stare per forza) e li ho collegati, cioè ho messo nelle
proprietà apposite i nomi dei vari componenti dati.
Ma quando vado a scrivere i metodi cominciano i casini: deve esistere
per forza il file .DBF (o quello che è) dei dati? Non posso crearlo ex novo
se non c'è (caso di installazione del programmino)? TDatabase è il
componente giusto o ci devo mettere TTable come alcuni esempi
sembrano suggerire? (E allora che cavolo è TDatabase???)
I TFieldDef vanno definiti a runtime o in fase di design? E gli indici?
Che cavolo è il TDataSet e PERCHE' ce lo devo mettere??
So già che qualcuno potrebbe dire "Fai un par di (mila) prove e vedi
com'è"... MA NON POSSO, IL PRG MI SI PIANTA APPENA
PARTE: RUNTIME ERROR!!!!
AAHAAAAARRGHH!!!

 Che cavolo è il TDataSet e PERCHE' ce lo devo mettere??
Come sopra
TDataSet encapsulates a database-engine independent set of properties,
events, and methods for working with data.
Many of the properties, events, and methods in TDataSet are abstract.
Abstract declarations are declarations without implementations. At the
TDataSet level they cannot be used or accessed. Developers must use or
derive descendants of TDataSet that declare and implement these abstract
methods. Many of the other TDataSet methods are declared and implemented in
TDataSet as virtual methods, but the implementations are merely stubs that
are reimplemented in descendants such as TClientDataSet, TBDEDataSet,
TDBDataSet, TQuery, TStoredProc, and TTable.
Single-tiered applications that use flat-file data and multi-tiered database
applications that use distributed datasets access their data using
TClientDataSet, a direct descendant of TDataSet. Developers who develop
their own distributed dataset objects should derive them from TClientDataSet
as well.
Applications that base their data access on ActiveX Data Objects (ADO) use
TADODataSet, another direct descendant of TDataSet, or the more specific
descendants TADOTable and TADOQuery.
Traditional single-tiered and two-tiered database applications that access
data through the Borland Database Engine (BDE) use TQuery, TStoredProc, or
TTable objects. Developers who create custom dataset components that use the
BDE directly in a client application derive them from TBDEDataSet,
TDBDataSet, TQuery, TStoredProc, or TTable.

Ciao,
prova a vedere qui:
http://www.kaposnet.hu/books/tysdelphi4/
troverai un libro su delphi gratis (in inglese)
che contiene anche alcuni capitoli sulla programmazione db.
Ciao, Rocco

 proprietà apposite i nomi dei vari componenti dati.
1) Il TDatabase stabilisce la connessione con un database.
Poi, nelle query, indichi come database il suddetto TDatabase.
Questo x il Bde. Se usi Ado o DbExpress, esiste invece del TDatabase
un oggetto TxxConnection che fa in pratica le stesse cose, solo
con metodi e proprietaà diverse.
A che serve?
Immagina che la tua applicazione possa lavorare con + db diversi.
Ad esempio, un gestionale potrebbe avere un db per ogni anno
di competenza....
Se non avessi TDatabase e/o TxxConnection, dovresti andare a
cambiare il nome del db su tutte le query della tua applicazione.
Invece, pasta cambiarlo sul TDatabase e via.
2) Sotto il tdatabase viene la TQuery.
La tquery sa che deve eseguire un qualcosa sul database indicato
dal TDatabase. Da qui fai una bella select etc etc etc
La query è readonly: x aggiornarla devi associare un TUpdateSql.
Se usi il requestlive hai il problema che non puoi aggiornare
query che contengono delle join.
Io ho scelto di usare sempre tUpdateSql.
3) Il Datasource si mette in mezzo tra i componenti visuali e 
la query, anzi , il dataset, x essere + precisi.
TTable, TQuery, TAdoQuery, TClientDataset etc ereditano tutti
da TDataset.
4) LE TTable vanno DIMENTICATE.
5) Creare il db a runtime lo puoi fare.
Le TTable hanno un metodo (CreateTable o simile...) 
da utilizzare per la creazione delle Tabelle
dopo aver definito la struttira di campi e indici.
Questo metodo va usato SOLO per Paradox, Dbf et similia.
Se usi un db client/server in genere il db si crea dalla console
del db stesso (IbConsole x Interbase, SqlCentral x Sybase,
Enterprise Manager per M$Sql ...)
Se poi hai power designer, puoi progettare il tuo db in modo
visuale e lui ti sforna un enorme script sql che fa tutto.
Funziona di sicuro su Sybase (!!), Oracle, M$Sql e interbase.


Dimenticavo....
In genere gli oggetti non visuali (tipicamente, oggetti di accesso
ai dati) vengono chiaffati in un datamdoule e non direttamente sul
form: questo x separare la logica della applicazione dalla parte
visuale.
Esiste di solito un data module principale nel quale metti
il TDatabase o la TxxConnection.
Poi, si crea un data module per ogni form.
I vari oggetti di accesso ai dati si attaccano poi al db indicato
dal TDatabase o TxxConnection messa nel datamodule principale.


 4) LE TTable vanno DIMENTICATE.
Ah, perchè? Cos'hanno che non va?

 Ah, perchè? Cos'hanno che non va?
Non vanno dimenticate, semplicemente possono dare 
problemi con quantita' di dati molto grandi, ovvero
molto piu' grandi di quelli gestibili con Paradox.
Le TTable vanno pero' bene per gran parte delle 
applicazioni piccole.  Se solo il BDE fosse un po' 
piu' stabile e meno buggato...
