Newsgroup: it.comp.lang.delphi
Titolo: Da delphi 2006 a delphi 10

Ciao,
in azienda abbiamo sviluppato un gestionale in delphi 2006. Abbastanza 
grande, connessione db tramite dbexpress, usa componenti indy, 
controlli sviluppati da noi che derivano da VCL, FASTreport...
 
Ora c'e' l'idea di modernizzarci un attimo... come gestire la 
migrazione da delphi 2006 all'ultimo 10? C'e da morire? riscrivere 
tutto?
Insomma.. avete qualche esperienza?
Grazie, ciao!

Ciao.
Nelle nuove versioni Indy c'è, magari nel frattempo potrebbe essere cambiata qualche property.
Anche dbx c'è, ma lo indicano come deprecated e invitano a usare firedac.
 
Riguardo componenti e librerie di terze parti occorre valutare caso per caso, cioè, mettersi li, PROVARE DI PERSONA e fregarsene di suggerimenti a vanvera di "guru" che passano dalle vs parti per caso.
 
La prima cosa che secondo me dovreste valutare riguarda gli impatti del passaggio da ansi a unicode, introdotto a partire da delphi 2009.
 
A.

 tutto?
 
E' sempre difficile rispondere a questa domanda, perché l'effettiva stima temporale non dipende solo dai componenti che sono stati utilizzati, ma anche da *come* lo sono stati.
 
Tra l'altro, il passaggio a una versione successiva alla 2009 richiede anche di affrontare la migrazione a Unicode, che in casi specifici può richiedere diversi interventi a seconda del modo in cui sono state utilizzate le stringhe.
 
Dallo scenario descritto, comunque, c'è il lato positivo che tutte le librerie menzionate sono ancora presenti e anche supportate.
 
Per farsi un'idea specifica, io suggerirei di scaricare una versione trial di Delphi 10 e provare a compilare i package e le applicazioni in modo da vedere quali sono gli errori che iniziano a emergere, se ci sono.
 
Dal risultato della prova si potrà fare una valutazione più precisa.
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
 #Home: 
http://www.marco.breveglieri.name
 
 #Blog: 
http://www.compilaquindiva.com
 
 #DelphiPodcast: 
http://www.delphipodcast.com
 

 tutto?
 
Dal momento che l'idea e` "modernizzarsi", avete considerato di lasciar perdere Delphi, ed adottare una tecnologia piu` sul mercato? C#, per esempio? Sicuramente richiederebbe un effort molto maggiore che un passaggio ad una nuova versione di Delphi, ma potrebbe costarvi di meno e potrebbe garantire al vostro codice una maggiore longevita`.
 
 
 

 potrebbe costarvi di meno e potrebbe garantire al vostro codice una maggiore longevita`.
 
A questo punto, costerebbe di meno comprare la tua stessa sfera di cristallo. :)
 
Cioè, siccome l'idea è "modernizzarsi", si dovrebbe buttare via *oggi* il "know how" acquisito su un prodotto attualmente attivo e ancora ben supportato per riscrivere interamente il software, già in funzione, con un'altra tecnologia e ri-acquistando anche i componenti di terze parti per fare fondamentalmente le stesse identiche cose di prima.
 
Non lo suggerirei nemmeno se avessi la garanzia che Delphi scomparisse domani e, se anche ce l'avessi, visto che parliamo sempre di una riscrittura completa, posticiperei ovviamente fino all'ultimo un simile costo da sostenere, che invece di garantire al codice una maggiore longevità finirebbe invece per azzerare semplicemente la durata della vita dell'azienda stessa. :|


parliamo sempre di una riscrittura completa, posticiperei ovviamente fino all'ultimo un simile costo da sostenere, che invece di garantire al codice una maggiore longevità finirebbe invece per azzerare semplicemente la durata della vita dell'azienda stessa. :|
 
Ma non dire cazzate. Le aziende devono investire sul proprio futuro. Non si puo` pensare, oggi, di continuare ad usare Delphi a livello professionale. Lo si puo` fare solo, come nel caso dell'OP, per ragioni di continuita`, ma lo si fa a proprio rischio e pericolo. Ed e` un rischio grosso. 
 
Non ho la benche` minima intenzione di alimentare una polemica con te sul tuo caro Delphi, per cui non riceverai altre risposte da me.

>
magari le tue.
 
 

 Non ho la benche` minima intenzione di alimentare una polemica con te sul tuo caro Delphi, per cui non riceverai altre risposte da me.
 
Ecco, adesso sì che la mia giornata è rovinata. :)


 ma lo si fa a proprio rischio e pericolo. Ed e` un rischio grosso. 
 
L'importante, imho, è scegliere CONSAPEVOLMENTE, cosa che fanno in pochi.
 
A.

 Qua chiederei ad entrambi di definire cosa si intende per "ben supportato".
 
Per "ben supportato" intendo che 
 
1)
vi sono rilasci frequenti di nuove versioni del prodotto, con nuove funzionalità;
 
2)
vengono rilasciate bug fix entro breve termine, e da qualche tempo anche per versioni precedenti, non solo per l'ultima;
 
3)
le novità e i requisiti imposti o consigliati dai produttori delle piattaforme indirizzate (Microsoft, Apple, Google) vengono recepiti tempestivamente e integrati nel prodotto;
 
3)
la documentazione ufficiale (online e offline) è stata notevolmente migliorata e contiene anche molti approfondimenti tecnici oltreché tutorial completi ed esempi tenuti aggiornati;
 
4)
vengono regolarmente pubblicati filmati e video per mostrare l'utilizzo corretto di librerie e componenti, vecchi e nuovi (vedi come esempio CodeRage, Skill Sprints, ecc.);
 
5)
vengono pubblicati libri aggiornati sul linguaggio e sul prodotto (vedi quello su Object Pascal di Marco Cantù, la serie "Coding in Delphi" di Nick Hodges, "Delphi Cookbook" di Daniele Teti, più altri testi mirati sul Mobile e FireMonkey).
 
6)
esiste una community che organizza eventi, scrive articoli sui blog, produce esempi e materiale da studiare per acquisire nuove conoscenze e scambiare pareri.
 
Ciao,
  Marco.


 Per "ben supportato" intendo che 
 
<cut>
 
Capito.
 
A.

 DOPO che è partito come va?
 
Direi abbastanza bene. Hai esperienze diverse?
 
Tutte le volte che ho visto qualcosa "andare male", di solito la colpa era dello sviluppatore e non del framework (e a volte quello sviluppatore potevo essere pure io). :D


 essere pure io). :D
 
Sicuramente il primo posto dove cercare un errore è il proprio codice.
E quando dico "cercare" intendo cercare SUL SERIO e sbattersi.
Però credo che chiunque fa sto lavoro almeno una volta ha beccato magagne dovute agli strumenti..
 
con db2 v7 beccammo un brutto bug nel leggere il 255 esimo campo di una tabella. I 2 adiacenti li beccava senza casini, ma quello li prp no.
Ora non ricordo se era prp db2 a fare cazzate oppure ado.
Visti i precedenti, sono prevenuto, lo ammetto, e credo più ad un problema ADO che di db2.
..lo so: "..come?? unatabella con più di 255 campi??".
Ma a volte ci sono cose che NON PUOI TOCCARE PERCHE' IL COSTO NON TI PERMETTE DI FARLO.
 
Ancora...
Software con circa 800 installazioni (server) sparse in tutta l'area EMEA.
Solo da un cliente, mai sullo stesso client e sempre in modo casuale, andando ad aprire una qualsiasi query con ADO saltava fuori un errore "query already open". Ovviamente, poche righe sopra c'era un query.close....
 
Lascimo stare poi se uno eredita dalle cose dei devex...
 
A parte ciò, non stavo mettendo in dubbio la stabilità.
Ma visto che le ultime applicazioni sulle quali ho lavorato e lavoro tutt'ora sono mission critical e/o con mole di dati dannatamente pesante e/o complessità di ealborazione estremamente elevata, sono molto sensibile sulle performance.
 
A.