Newsgroup: it.comp.lang.delphi
Titolo: Delphi XE 2 + Firebird

Ciao a tutti,
   il giorno e' arrivato ..... abbiamo cambiato il gestionale !!!!
Questo programma lavora con firebird.
 
Non ho mai lavorato con firebird, quindi buio assoluto ... qualche link, 
libro, esempi ecc... sono ben accetti.
 
Il programma lavora con un unico megafile (C:\AllData\AllDB.phs di ben 3GB) 
con le credenziali di accesso standard di firbird
username SYSDBA con pwd masterkey.
"Aprendolo" con FlameRobin ho individuato le 3 tabelle che mi interessano 
con i relativi campi di interesse e come sono (intefer, float, datetime 
ecc..).
 
Sto impostando un progetto studio con la sola finalita' di aprire una di 
quelle tabelle e visualizzarla in una griglia, poi si cresce.
L'unica nota positiva e' che devo solo leggere un paio di campi per tabella 
quindi, in teoria, non dovrei fare disastri !!
 
Come detto sopra, partendo da zero prima devo capire cosa devo fare ... poi 
se riesco la faccio.
 
Grazie a tutti
 
Daniele
 
PS: Portate pazienza. 
 

Onestamente non so cosa siano i file phs (mai sentiti).
comunque se vai su youtube e cerchi "delphi firebird" trovi parecchio materiale, a cominciare da Marco Cantù (in inglese).
ciao.
 
giovanni

 materiale, a cominciare da Marco Cantů (in inglese).
Ne ho visionati alcuni, cerchero' con piu' attenzione di trovare qualche 
esempio che tratti anche come usare i file .phs
 
Grazie
 
Daniele 
 

 libro, esempi ecc... sono ben accetti.
 
Leggi la documentazione ufficiale di XE2 su come create applicazioni database, in particolare usando la libreria *dbExpress*, che include un driver per FireBird:
http://docwiki.embarcadero.com/RADStudio/XE2/en/Developing_Database_Applications
 
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
 #Home: 
http://www.marco.breveglieri.name
 
 #Blog: 
http://www.compilaquindiva.com
 
 #DelphiPodcast: 
http://www.delphipodcast.com
 

 esempio che tratti anche come usare i file .phs
 
Lascia perdere l'estensione dei file: FireBird generalmente usa l'estensione ".fdb", oppure ".gdb" per la compatibilità con InterBase.
 
L'estensione di quel file fa sospettare che semplicemente sia stato rinominato per evitare di dare ulteriori indizi sul formato a cui appartiene.


 esempio che tratti anche come usare i file .phs
 
Parti da un punto di vista sbagliato.
Utilizzando database c/s (firebird, oracle, db2, sybase, postgres, interbase etc....) TE NE FOTTI DEI FILE concentrandoti solo sui dati.
 
Studia il materiale che ti è stato indicato e tutto diventerà di una chiarezza cristallina.
 
A.

 visualizzarla in una griglia ?
 
SQL.
 
Occhio, però.
 
Se il database è strutturato come si deve è molto probabile che i dati 
che ti interessano possano risiedere in più tabelle.
 
Es.: nelle fatture potrebbe non esserci la ragione sociale del cliente 
ma solo un suo codice identificativo che rimanda alla tabella dei clienti.
 
È solo un esempio, ovviamente.
 
-- 
@WarpTen10
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 libro, esempi ecc... sono ben accetti.
 
LOL :) In bocca al lupo. Credo che, oggi, con la disponibilita` di database che esistono in giro (Postgres, MySQL, per citarne due facilmente accessibili), buttarsi su Firebird sia un mezzo suicidio.
 
 


A dire la verità io lo uso dal 2002 senza il minimo problema.


 A dire la verità io lo uso dal 2002 senza il minimo problema.
 
E sono contento per te, ma non e` questo il punto. 
Io, che ho usato Firebird da quando e` venuto fuori (e prima di esso Interbase), invece ho incontrato diversi problemi; uno per tutti: caduta improvvisa, e apparentemente inspiegabile, della connessione al db, risolta egregiamente passando, di netto, a Postgres, senza cambiare UNA linea di codice. Fortunatamente il codice era scritto sufficientemente bene da non richiedere troppe modifiche nell'accesso ai dati. Il punto e` che, se si deve scegliere tra Postgres e Firebird, non c'e` motivo per scegliere Firebird. MySQL non e` free per usi commerciali, quindi avrebbe questo svantaggio, a confronto. Il problema e` che Firebird e` usato, in prevalenza, agli sviluppatori Delphi. Non affascina praticamente nessuno al di fuori di quella comunita`. E segue la decadenza di Delphi. Per non partare di documentazione e supporto. Del tutto infimi. 

 appartiene.
 
Esatto, ieri sera prima di andare a casa l'ho rinominato con nome di 
fantasia (pippo.dnl) ed e' stato aperto da flamerobin senza problemi.
Ergo e' solo nome di fantasia !!!
 
Ciao
 
Daniele 
 

 
http://docwiki.embarcadero.com/RADStudio/XE2/en/Developing_Database_Applications
 
 
Grazie per il link, procedo subito con lo studio.
 
Ciao
 
Daniele 
 

 UNA linea di codice.
 
Da come lo descrivi sembra più un problema dei componenti per l'accesso 
a Firebird che non un problema di Firebird stesso.
 
Io ho sempre usato IBX e non ho mai avuto problemi.


Con Postgres uno che conosco ha riscontrato un problema di performance sulle join implicite (basate su where) rispetto a quelle esplicite (basate sul costrutto join) su una mole di dati non banale.
 
Con FB (non lo uso da un bel po...), un altro mi ha segnalto che a fronte di numerose cancellazioni di record, le performance degradano pesantemente e l'unica strada per risolvere è usare gbak (o come kaz si chiama..non so) per forzare la compattazione del file del database. 
 
Ribadisco che sono MIE esperienze dirette, fermo restando che le 2 persone le considero molto affidabili.
 
Puoi riportare qualche dettaglio in piu' sul contesto nel quale hai riscontrato i problemi relativi alla connessione con fb, tipo numero utenti, tecnologia di accesso ai dati, mole dei dati, versione di delphi e del motore etc?
 
A.

 
Mi associo a Warp10; in funzione dal 2006 senza battere ciglio.

Pardon...
Ribadisco che *NON* sono MIE esperienze dirette
 
A.
 

 a Firebird che non un problema di Firebird stesso.
 
No, era un problema del database. Investigammo il problema a lungo, all'epoca, perche` volevamo evitare un cambio netto del db. Non mi ricordo esattamente di cosa si trattava, ma escludemmo si trattasse dei componenti. Non ricordo il problema esatto, perche` e` stato circa 10 anni fa, abbiamo sostituito il db praticamente al volo, e in poco tempo, e mai piu` toccato.

 Puoi riportare qualche dettaglio in piu' sul contesto nel quale hai riscontrato i problemi relativi alla connessione con fb, tipo numero utenti, tecnologia di accesso ai dati, mole dei dati, versione di delphi e del motore etc?
 
Non ricordo le versioni cosi` come non ricordo il nome esatto del driver dbExpress usato. Usavamo dbExpress e ClientDataSet. Si e` trattato di piu` di 10 anni fa. Gli utenti erano una quindicina in un ufficio, e una decina nell'altro, a pochi chilometri. La mole di dati attorno a qualche centinaia di migliaia di record (in alcuni casi sforava, di poco, il milione).
 

 Mi associo a Warp10; in funzione dal 2006 senza battere ciglio.
 
E ribadico che il punto non era quello. Mi riferivo alla scarsa documentazione/supporto disponibile in giro, e al fondamentale errore di scegliere un database come Firebird, quando esistono validissime alternative, piu` conosciute, documentate, supportate e, con tutta probabilita`, migliori performance.

 Si e` trattato di piu` di 10 anni fa. 
 
Magari oggi va meglio...?
 
A prescindere, la cosa è comunque preoccupante, visto il carico non particolarmente tosto.
 
A.

 Magari oggi va meglio...?
 
E chi se ne importa. Il punto e` che a nessuno verrebbe in mente di proporre Firebird in un contesto che non sia strettamente Delphi-friendly (e anche con Delphi, io preferivo di gran lunga MySQL e Postgres). Oggi (e non solo da oggi) esistono database gratuiti, documentati, supportati, funzionanti tanto quanto FB, se non meglio. Ed e`, se proprio si deve fare un passaggio, di gran lunga piu` intelligente adottare questi che FB.