da db paradox a internet
geppetto
Da anni faccio manutenzione di un'applicazione in delphi2 che fa uso di
database paradox tramite bde.
Ora , al fine di evitare la riscrittura della procedura anche piuttosto
complessa e composta da circa una trentina di tabelle strettamente
relazionate, come posso portare l'applicazione su internet?
In particolare ho bisogno di integrare funzionalita' almeno di
consultazione (ma se si potesse anche operare modifiche in parte non
sarebbe male) dei database da parte di utenti esterni?
Esiste un modo o dei tools per evitare troppo lavoro?
Grazie a tutti
Geppetto
Andrea Laforgia
<enimeil...@gmail.com> wrote:
>Ora , al fine di evitare la riscrittura della procedura anche piuttosto
>complessa e composta da circa una trentina di tabelle strettamente
>relazionate, come posso portare l'applicazione su internet?
A mio avviso, dovresti rivederla completamente. L'interfaccia utente
va sicuramente creata ex-novo e sopratutto il DB retrostante deve
essere un client/server. Paradox è un vecchio sistema file-based,
inadatto per lo sviluppo su web. Personalmente ti consiglio di
passare a MySQL, che è un RBDMS di alto livello e usatissimo in ambito
web. Per la trasformazione della base dati, non credo che ci sia
molto da fare, devi rifarla completamente a mano. Io tempo fa mi
scrissi un tool per trasformare un intero schema Paradox nel relativo
schema Firebird. Il programma accettava la cartella in cui erano
presenti i file .DB e generava il codice SQL per la ricreazione della
base dati sotto Firebird. Se la base dati è grande, potresti fare la
stessa cosa. Non credo che le tue tabelle godano di relazioni o
integrità referenziale, per cui, eventualmente, i legami tra di esse
vanno ricostruiti. Se vuoi usare MySQL, un tool ottimo per questo
scopo è DBDesigner della FabForce.
>In particolare ho bisogno di integrare funzionalita' almeno di
>consultazione (ma se si potesse anche operare modifiche in parte non
>sarebbe male) dei database da parte di utenti esterni?
E' una domanda?
geppetto
> A mio avviso, dovresti rivederla completamente. L'interfaccia utente
> va sicuramente creata ex-novo e sopratutto il DB retrostante deve
> essere un client/server. Paradox è un vecchio sistema file-based,
In pratica e' come rifate tutto il programma ?!?! :((
Ma ti rendi conto di cosa vuol dire riscrivere tutto?
Pensavo ci fosse un sistema piu' indolore :(
> inadatto per lo sviluppo su web. Personalmente ti consiglio di
> passare a MySQL, che è un RBDMS di alto livello e usatissimo in ambito
> web.
Ma non in ambito lan (dato che devo usarlo anche da clients lan-side.
O mi sbaglio?
Anche perche' per uso commerciale (come nel mio caso) MYSQL e' a
pagamento ! In questo caso forse Firebird sarebbe meglio. Non pensi?
Per la trasformazione della base dati, non credo che ci sia
> molto da fare, devi rifarla completamente a mano. Io tempo fa mi
In pratica dovrei riscrivere l'interfaccia utente magari in delphi es.6
o 7 e accedere ad una basedati ricostruita in MYSQL sia per il
data-entry da back-office che da utenti remoti su internet ?
E poi magari farmi (come mi racconti) un programma di trasporto dei dati
da paradox a mysql (dato che attualmente il software e' installato a piu
clienti ) ?
> stessa cosa. Non credo che le tue tabelle godano di relazioni o
> integrità referenziale,
Ma scherzi?!?! Assolutamente si! Ma che software sarebbe altrimenti?
> vanno ricostruiti. Se vuoi usare MySQL, un tool ottimo per questo
> scopo è DBDesigner della FabForce.
Vale anche per Firefox eventualmente?
>>In particolare ho bisogno di integrare funzionalita' almeno di
>>consultazione (ma se si potesse anche operare modifiche in parte non
>>sarebbe male) dei database da parte di utenti esterni?
>
>
> E' una domanda?
Hai ragione. Ho sbagliato :( Era un'affermazione :))
In pratica non mi conviene nemmeno toccarla la vecchia applicazione ma
inizire da zero con una nuova a questo punto !?
Grazie
Geppetto
Andrea Laforgia
<enimeil...@gmail.com> wrote:
>Intanto grazie Andrea per la risposta.
E di che...
>> A mio avviso, dovresti rivederla completamente. L'interfaccia utente
>> va sicuramente creata ex-novo e sopratutto il DB retrostante deve
>> essere un client/server. Paradox è un vecchio sistema file-based,
>
>In pratica e' come rifate tutto il programma ?!?! :((
>Ma ti rendi conto di cosa vuol dire riscrivere tutto?
>Pensavo ci fosse un sistema piu' indolore :(
Sì, purtroppo me ne rendo conto, perché mi è capitato spesso di dare
supporto per far scalare applicazioni scritte in Paradox verso sistemi
più robusti (in particolare Oracle). Il problema è nell'architettura
di Paradox che, essendo un sistema file-based, è fondamentalmente
diverso da un RDBMS come Oracle, MySQL o SQL Server. Cambia
totalmente, quindi, non solo la struttura dei dati, ma la modalità di
accesso dal parte del programma. Con Paradox, le operazioni sui dati
sono tutte client-side, mentre con un RDBMS il carico di lavoro è lato
server e il client si limita a comunicare che tipo di operazioni
svolgere sui dati. Il problema è che molto spesso si sviluppa, senza
prevedere stravolgimenti di questo tipo (e ammetto che è anche
difficile prevederli, a volte). Io credo che, nell'ottica di
trasferire un software come il tuo su web, conviene pianificare la
riscrittura totale, e del programma, e della base dati. Purtroppo un
sistema indolore che riesca a fare una trasformazione in automatico
non c'è. L'interfaccia web è fondamentalmente diversa da quella
desktop e c'è una netta differenza tra la presentazione e
l'elaborazione dei dati.
>> inadatto per lo sviluppo su web. Personalmente ti consiglio di
>> passare a MySQL, che è un RBDMS di alto livello e usatissimo in ambito
>> web.
>
>Ma non in ambito lan (dato che devo usarlo anche da clients lan-side.
>O mi sbaglio?
>Anche perche' per uso commerciale (come nel mio caso) MYSQL e' a
>pagamento ! In questo caso forse Firebird sarebbe meglio. Non pensi?
MySQL è usato ed usabile per entrambi gli scopi, sia in rete locale
che su web. E' un ottimo DB, tra i più facili da installare ed
utilizzare. La licenza costicchia (intorno ai 500$ annuali per
server, ma fanno spesso offerte speciali). Se vuoi mantenere bassi i
costi, comunque, Firebird è sicuramente un'alternativa valida.
>In pratica dovrei riscrivere l'interfaccia utente magari in delphi es.6
>o 7 e accedere ad una basedati ricostruita in MYSQL sia per il
>data-entry da back-office che da utenti remoti su internet ?
Ma che intendi per "utenti remoti su internet" ? In base alle tue
richieste iniziali, io ho pensato che tu abbia avessi di accedere al
sistema via _web_ (per mezzo di un browser, per intenderci).
Nel caso fosse così, io ti consiglio, se non ti è d'intralcio, di fare
un'interfaccia unica, quella web, da utilizzare poi anche in lan. Su
lan puoi comunque installare un web server sul server e utilizzare il
browser come thin client.
>E poi magari farmi (come mi racconti) un programma di trasporto dei dati
>da paradox a mysql (dato che attualmente il software e' installato a piu
>clienti ) ?
Sì, esatto. Questa, comunque, dovrebbe essere la parte più semplice
;-)
>> stessa cosa. Non credo che le tue tabelle godano di relazioni o
>> integrità referenziale,
>Ma scherzi?!?! Assolutamente si! Ma che software sarebbe altrimenti?
Non so se mi sono spiegato bene. Con Paradox, l'integrità
referenziale non la usa praticamente nessuno (anche perché, come molte
altre cose, è gestita malamente), quindi ho dato per scontato che
neanche tu la utilizzassi. Ma, comunque, il fatto di usarla non ti dà
nessun vantaggio, dovrai riscrivere anche le relazioni tra tabelle.
>> vanno ricostruiti. Se vuoi usare MySQL, un tool ottimo per questo
>> scopo è DBDesigner della FabForce.
>
>Vale anche per Firefox eventualmente?
Vuoi dire "Firebird" :-)... no DBDesigner (almeno che io sappia)
lavora solo con MySQL.
>In pratica non mi conviene nemmeno toccarla la vecchia applicazione ma
>inizire da zero con una nuova a questo punto !?
Non so che cosa puoi recuperare della vecchia, ma se sei intenzionato
a cambiare DB, la scelta che puoi fare è solo verso un RBDMS come
Firebird o MySQL. In quel caso, l'applicazione devi praticamente
riscriverla.
geppetto
> E di che...
Dello sforzo che persone come te fanno nel trasferire l'informazione in
ambito pubblico. E soprattutto dello sforzo che hai dovuto fare per
acquisirle ;)
Il problema è che molto spesso si sviluppa, senza
> prevedere stravolgimenti di questo tipo (e ammetto che è anche
> difficile prevederli, a volte). Io credo che, nell'ottica di
Ma io non intendo stravolgere il programma.
Il fatto che il mio software non sia mai andato su architettura C/S non
vuol dire che non sia stato previsto. Semplicemente il software, per
ragioni di prestazioni e prezzo, e' sempre andato bene cosi.
Sono gia' a conoscenza del fatto che se avessi scritto il software in
php o asp con accessi a RDBMS sarebbe pronto per il web.
Ma chi me lo faceva fare 10 anni fa? E soprattutto non c'era la necessita'
Qui il punto non e' "client/server o no".
Il problema e' che sullo stato di fatto riscrivere tutto non e' una
soluzione, capisci il perche' del mio post?
A me basterebbe poter consultare alcune tabelle su un web server interno
all'azienda. Se non posso scrivere sugli archivi Paradox da Apache (per
esempio) pazienza; ma almeno riesco a leggere dati da parte di operatori
esterni all'azienda. ( ... Mhhh. Mi sta venendo in mente una sorta di VPN).
> Ma che intendi per "utenti remoti su internet" ? In base alle tue
Qualsiasi utente che, tramite la nostra discussione, riuscira' a leggere
i dati dei miei archivi da una postazione esterna all'azienda (es. un
portatile via GPRS o postazione fissa remota, ecc. ecc.
> richieste iniziali, io ho pensato che tu abbia avessi di accedere al
> sistema via _web_ (per mezzo di un browser, per intenderci).
O con browser web o con client di consultazione, per esempio lo stesso
mio software installato su postazione remota (sempre al fine di evitare
la riscrittura totale dell'applicazione)
> Non so se mi sono spiegato bene. Con Paradox, l'integrità
> referenziale non la usa praticamente nessuno (anche perché, come molte
> altre cose, è gestita malamente), quindi ho dato per scontato che
Sik. E io che pensavo di aumentare la stabilita' degli archivi :(
>>Vale anche per Firefox eventualmente?
>
>
> Vuoi dire "Firebird" :-)... no DBDesigner (almeno che io sappia)
> lavora solo con MySQL.
Si. Con tutti questi fuochi in giro (Firefox, Firebird, Firewire,
Firewall ... ) ogni tanto mi brucio ;-)
> Non so che cosa puoi recuperare della vecchia, ma se sei intenzionato
> a cambiare DB, la scelta che puoi fare è solo verso un RBDMS come
> Firebird o MySQL. In quel caso, l'applicazione devi praticamente
> riscriverla.
Certo se penso che gia' per passarla da Delphi2 ad almeno Delphi7 c'e'
un bel po' di lavoro .....
Forse e' il caso di considerare la riscrittura in PHP. Sara' un'impresa :((
Grazie del tuo tempo, Andrea.
Geppetto
Andrea Laforgia
> A me basterebbe poter consultare alcune tabelle su un web server interno
> all'azienda.
E' un accrocchio, ma credo che funzionerebbe. L'interfaccia,
comunque, sarebbe da riscrivere. Dovresti avere delle ISAPI o dei
moduli Apache (meglio quest'ultima soluzione) che leggono/scrivono
su base dati Paradox. Non so però quanto bene si integri il BDE
per le applicazioni web-based, non mi sono mai azzardato a fare
una cosa del genere. Tieni presente che il BDE ha dei bug
conclamati che però non verranno mai risolti, perché è ormai
"deprecated" e non viene più fatta manutenzione da parte di Borland.
> O con browser web o con client di consultazione, per esempio lo stesso
> mio software installato su postazione remota (sempre al fine di evitare
> la riscrittura totale dell'applicazione)
Paradox non va bene per questi utilizzi. Utente remoto significa
necessariamente configurazione client/server (tieni presente che
persino con un DB c/s si hanno problemi di prestazioni, se non si
fa un tuning adeguato). Il problema dei sistemi file-based è che
non c'è un server che elabora, ma tutto è svolto lato client,
scaricando l'intera base dati. Assolutamente improponibile per
l'utilizzo remoto.
> Si. Con tutti questi fuochi in giro (Firefox, Firebird, Firewire,
> Firewall ... ) ogni tanto mi brucio ;-)
Eh eh :) hai ragione...
> Forse e' il caso di considerare la riscrittura in PHP. Sara' un'impresa :((
Puoi anche riscrivere l'applicazione senza abbandonare Delphi
(vedi l'uso di ISAPI oppure l'adozione di Delphi 2005 con la
possibilità di sfruttare le potenzialità di .NET in questo senso),
ma sicuramente l'architettura dei dati e dell'applicazione stessa
è da rivedere. Se ci fossero altre soluzioni meno traumatiche, te
le proporrei ;-)
warp10
Senza stravolgere la tua applicazione potresti usare Terminal Server.
L'applicazione gira su un server e gli utenti si collegano tramite
client e usano il server come se fossero li' davanti. Devi prevedere una
robusta politica di permessi per evitare che l'utente remoto ti spenga
il server, ma non e' troppo complesso. L'occupazione di banda e' minima
perche' viaggiano solo le schermate. Tutta l'elaborazione e' a carico
del server che deve, quindi, essere ben carrozzato.
Tutto questo partendo dal concetto che tu abbia a disposizione un server
almeno W2K (2003 sarebbe meglio) e che i client siano collegati almeno
tramite ISDN (ADSL sarebbe meglio).
Se non ricordo male sotto W2KSRV avevi 120 gg. di prova prima della
disattivazione del servizio. Ti rimane una connessione sola come
Administrator. Hai, quindi, 4 mesi in cui pensare a qualcosa di
alternativo, soprattutto per le tabelle Paradox. Io uso IB/FB e mi trovo
benissimo.
Andrea Laforgia
[...]
> Senza stravolgere la tua applicazione potresti usare Terminal Server.
Già, così gli utenti remoti si impiccheranno a un albero, dopo il
terzo giorno di utilizzo del programma.
warp10
Ottima considerazione tecnica.
Andrea Laforgia
[...]
> Ottima considerazione tecnica.
La considerazione tecnica è sottintesa. Immagino che tu non abbia
mai lavorato da remoto con TS. Non mi meraviglierei, visto che
sei solito aprire bocca su ciò che non conosci.
warp10
Sono circa 4 anni che ho in piedi un'applicazione Delphi che gira su un
server TS a cui sono collegati cinque client remoti tramite un router ISDN.
Le prestazioni sono dignitose, non eccelse, anche perche' il server, non
nostro, non e' granche'.
Ho tirato fuori quest'ipotesi visto che geppetto aveva scarsa
voglia/tempo di riscrivere l'applicazione. In questo modo da' la
possibilita' ai suoi client remoti di lavorare.
geppetto
> voglia/tempo di riscrivere l'applicazione. In questo modo da' la
> possibilita' ai suoi client remoti di lavorare.
In efftti non e' una cattiva idea.
Sempre che leprestazioni diano accettabili (ma credo di si per sola
consultazione).
Ma scusami la domanda: TS funziona come VNC dove da server deve esserci
l'appicazione che gira veramente (se fosse cosi sarebbe monoutente)?
Grazie
Geppetto
geppetto
Corba in ambito delphi o altro.
Cosa ne pensate. Sono troppo costose?
Sono difficili da implementare?
Geppetto
warp10
Tramite TS tu hai un server che permette agli utenti remoti di eseguire
applicazioni che siano installate su di esso come se questi utenti
fossero seduti davanti al server.
Quanti utenti possono accedere contemporaneamente? Dipende dal numero di
licenze attive sul server. Ogni utente puo' avere una propria copia
dell'applicazione attiva indipendentemente dagli altri. Ogni client vede
il server come se ci stesse lavorando solo lui.
Se tu guardi il monitor del server, pero', non vedi l'applicazione
girare. Il client non prende il controllo del server, ma ne sfrutta le
applicazioni installate.
Ai tempi di W2K si parlava di un'occupazione di banda di circa 12K per
connessione. Ricorda che viaggiano solo movimenti del mouse del client e
schermate di risposta del server e niente altro.
Andrea Laforgia
Un application server è quella parte dei sistemi cosiddetti
"three-tier" che conserva la "business logic" dell'applicazione.
Gli altri "tier" si occupano, tipicamente, della presentazione dei
dati e dell'accesso fisico al database. Ad esempio, il primo tier
potrebbe essere il web browser, il secondo l'app server vero e
proprio interfacciato dal client e il terzo il database. Un
application server lavora quasi sempre con un web server e
l'intero sistema prende il nome di "Web application server".
Il web server si occupa di accogliere le richieste lato client,
interfacciare in modo adeguato l'app server e restituire i dati
formattati al client. I Web app server supportano spesso anche il
protocollo di brokering di CORBA.
CORBA è un'architettura studiata dall'Object Management Group (un
consorzio costituito da molte aziende), per la creazione di
software distribuito (in termini semplici: mediante oggetti che
viaggiano in rete). Un antagonista per CORBA è DCOM di Microsoft,
ma ha sempre avuto problemi piuttosto seri e, nel tempo, è stato
di fatto abbandonato.
Sia CORBA che DCOM sono stati superati a favore di SOAP, che ha il
vantaggio di sfruttare il protocollo HTTP e il linguaggio XML per
la formattazione delle informazioni. Su di esso si basano i
moderni WebServices.
geppetto
> Sia CORBA che DCOM sono stati superati a favore di SOAP, che ha il
> vantaggio di sfruttare il protocollo HTTP e il linguaggio XML per la
> formattazione delle informazioni. Su di esso si basano i moderni
> WebServices.
Diciamo che mi complico molto la vita?
Nel senso che per riscrivere il tutto vale la pena cambiare in questa
direzione?
Andrea Laforgia
> Diciamo che mi complico molto la vita?
Parecchio.
> Nel senso che per riscrivere il tutto vale la pena cambiare in questa
> direzione?
No.
Morde
> Se tu guardi il monitor del server, pero', non vedi l'applicazione
> girare. Il client non prende il controllo del server, ma ne sfrutta le
> applicazioni installate.
Ottimo. Questo e' proprio la sostanziale differenza con VNC: con vnc
l'utento prende il controllo dell'intero server, mentre in TS il server in
se' rimane sempre libero.
ciao
--
Morde.
ICLDweb: http://www2.samatel.com/icld/
Andrea Laforgia
> Ottimo.
In fin dei conti, non hanno inventato nulla. E' il concetto di
"terminale", vecchio 50 anni.
geppetto
Beh. Allora perche' tanto impegno a sviluppare architetture
client/server se bastava trasportare solo mouse.actions e framebuffers
vari ?
Andrea Laforgia
> Beh. Allora perche' tanto impegno a sviluppare architetture
> client/server se bastava trasportare solo mouse.actions e framebuffers
> vari ?
Eh?!
geppetto
Scusa per la genericita'.
Nel senso che se Terminal Server (con il solo uso di mouse e schermate
trasportate su rete, in parole povere) e' una soluzione stravecchia e
conosciuta per interagire con un server, perche' la necessita' di creare
Application Server e Aplicazioni Distribuite ?
Andrea Laforgia
> Nel senso che se Terminal Server (con il solo uso di mouse e schermate
> trasportate su rete, in parole povere) e' una soluzione stravecchia e
> conosciuta per interagire con un server, perche' la necessita' di creare
> Application Server e Aplicazioni Distribuite ?
Perché il processo tecnologico ha fatto sì che questo tipo di
applicazioni fossero necessarie. I concetti legati al terminale
non sono poi cambiati, se consideri l'uso del browser. Un browser
si adatta benissimo alla funzione del terminale, perché, di fatto,
è un thin client, non fa alcuna operazione in locale (se non
richiamare funzioni Javascript/VBScript) rimanda tutto al server.
E' lato server, poi, che esisterà l'application server.
In quanto alle applicazioni distribuite, la loro esistenza è
dettata da altre esigenze.
geppetto
> vantaggio di sfruttare il protocollo HTTP e il linguaggio XML per la
> formattazione delle informazioni. Su di esso si basano i moderni
> WebServices.
Scusa ma , non potrebbe essere una soluzione quella di aggiornare
costantemente un database in MYSQL (posto sul server web interno) dal
database Paradox e usarlo per la consultazione da internet?
Andrea Laforgia
> Scusa ma , non potrebbe essere una soluzione quella di aggiornare
> costantemente un database in MYSQL (posto sul server web interno) dal
> database Paradox e usarlo per la consultazione da internet?
"Aggiornare costantemente" è un'espressione che mi fa paura.
Che intendi esattamente? eseguire una query ogni tot su Paradox e
compiere update ogni tot sulla base dati MySQL ? E' una porcata
che, forse, funzionerebbe.
geppetto
> In quanto alle applicazioni distribuite, la loro esistenza è dettata da
> altre esigenze.
Molto chiaro .
Thank you so much.
geppetto
> "Aggiornare costantemente" è un'espressione che mi fa paura.
> Che intendi esattamente? eseguire una query ogni tot su Paradox e
> compiere update ogni tot sulla base dati MySQL ? E' una porcata che,
> forse, funzionerebbe.
No. Intendo che , almeno per le table sottoposte a consultazione da
utenti esterni, si scrivano cntemporaneamente i record sia in paradox
che in MYSQL ;)
Andrea Laforgia
> No. Intendo che , almeno per le table sottoposte a consultazione da
> utenti esterni, si scrivano cntemporaneamente i record sia in paradox
> che in MYSQL ;)
Sě, puň essere un compromesso, ma tieni presente che per la
presentazione dei dati via web, č necessario (ovviamente) scrivere
delle ISAPI o dei moduli Apache di accesso al DB.
warp10
La tecnologia alla base di TS e' molto simile a quella di Citrix
Metaframe o Winframe (non mi ricordo). Penso che sia stata "acquistata"
da M$ ma non ne sono certo.
La prima prova che avevamo fatto per testare Citrix era con una scheda
proprietaria Citrix che ha trasformato un arcaico 286 in un PC nuovo
fiammante (per l'epoca) in grado di far girare Office97 su W2K. Il mouse
andava un po' a scatti ma ci avevano assicurato che usando un PC dal 386
in su non ci sarebbe piu' stato quel difetto. Le prestazioni erano,
ovviamente, quelle del server e non del 286.
Quella scheda prendeva totale possesso del PC su cui era installata.
Entravi nel suo BIOS, settavi i parametri del server Citrix a cui
connettersi, come accreditarsi al server, quale applicazione lanciare
una volta connesso (volendo) e se spegnere il PC locale una volta
disconnesso. Un'esatta replica di un terminale "stupido".
L'esperimento tramite scheda non e' andato a buon fine perche' dal PC
remoto non potevano giocare a Solitario. Non sto scherzando, e' andata
proprio cosi' ed allora abbiamo optato per TS.
geppetto
> remoto non potevano giocare a Solitario. Non sto scherzando, e' andata
> proprio cosi' ed allora abbiamo optato per TS.
AHAHAH Incredibile :))
geppetto
> Sì, può essere un compromesso, ma tieni presente che per la
> presentazione dei dati via web, è necessario (ovviamente) scrivere delle
Perche' ? Non va bene scrivere pagine dinamiche in php che interroga
MYSQL (quello popolato dal client Delphi) ?
warp10
Geppetto, mi sono trovato anch'io nella tua stessa situazione.
Alla fine ho convertito le tabelle Paradox in un database IB e riscritto
l'applicazione da Delphi in JSP (Java Server Pages).
E' stato un lavoraccio, l'ammetto, ma penso sia l'unica strada
percorribile alla lunga distanza. Anche la soluzione TS che ho proposto
e' un palliativo, non una soluzione definitiva perche' ha pur sempre
bisogno di un client (a meno che non usi XP sui client remoti).
Forse potresti valutare Intraweb anche se sono il primo (non l'unico in
questo NG) a dirti di pensarci attentamente.
Il primo passo che devi compiere e', pero', la ristrutturazione delle
tabelle Paradox in un unico database sotto un RDBMS robusto (IB/FB,
MySQL o altro sta a te decidere).
warp10
No, no... reale :(
geppetto
> geppetto wrote:
>
>
> Il primo passo che devi compiere e', pero', la ristrutturazione delle
> tabelle Paradox in un unico database sotto un RDBMS robusto (IB/FB,
> MySQL o altro sta a te decidere).
Gia' . Penso che ormai il mio destino sia quello, anche se mi secca
enormemente non poter distribuire la mia applicazione con un semplice
cdrom con annesso bde. Ma pazienza mi mettero' a lavorare come un mulo :((
Sara' un casino fare il deploying dell'applicazione :(
warp10
Hai tutto il mio affetto e non ti sto prendendo in giro...
Prendila come un'esperienza, un modo di conoscere altre cose. Imparerai
molto una volta che avrai finito.
geppetto
>
> Prendila come un'esperienza, un modo di conoscere altre cose. Imparerai
> molto una volta che avrai finito.
Ok. Lo faro' ;)
Grazie ti tutto a te ed Andrea.
Scusate se uso il NG per augurarvi anche un veloce Buon Natale ma dopo
una mano cosi' ci vuole.
Andrea Laforgia
> Perche' ? Non va bene scrivere pagine dinamiche in php che interroga
> MYSQL (quello popolato dal client Delphi) ?
Usare PHP è comunque una soluzione (il supporto per MySQL da PHP è
ottimo). Io ti consigliavo un'ISAPI o un modulo Apache per avere
tutti i "pezzi" dell'applicazione scritti in Delphi.
geppetto
> Usare PHP è comunque una soluzione (il supporto per MySQL da PHP è
> ottimo). Io ti consigliavo un'ISAPI o un modulo Apache per avere tutti
> i "pezzi" dell'applicazione scritti in Delphi.
>
>
Ok. Mi devo documentare ;)
Grazie mille Andrea.