Newsgroup: it.comp.lang.vo-clipper
Titolo: Ancora sul Technical Meeting

Ciao a tutti,
sono rimasto molto soddisfatto dal technical meeting, è stata una giornata che
mi ha arricchito di idee ed informazioni. Ringrazio i relatori che sono stati
all'altezza della situazione. Devo dire che anche l'organizzazione ha
funzionato bene, CA (a caval donato non si guarda in bocca) ha assolto
benissimo il suo compito.
Una piccola critica, naturalmente con spirito costruttivo, va alla poca
visibilità di questo technical meeting. Una maggiore promozione poteva
coinvolgere maggiormente gli eterni indecisi che non sono ancora passati al
mondo VO pur provenendo dal Clipper. Anche perchè i posti a sedere e le cibarie
non mancavano.
A mio avviso il technical meeting ha evidenziato che:
1) i file DBF/CDX, pur funzionando benissimo, presentano delle lacune in alcune
situazioni e, per non trovarsi completamente impreparati, è giusto iniziare a
studiare un'alternativa;
2) le reti di PC ed il mondo internet/intranet ci obbliga ad una rivisitazione
del modo di programmare e di strutturare gli applicativi.
In parole povere, VO e Windows non sono un punto di arrivo ma, al contrario, un
punto di partenza.
A voi la parola.
B. Notario
-- 
Posted from 
flat-p10-m036.aruba.it
 [62.149.170.38] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 del modo di programmare e di strutturare gli applicativi.
Qual'è il problema per quanto riguarda le reti locali (immagino che tu
intenda questo con "reti di PC", giusto?)? Per Internet francamente non
vedo altra soluzione che utilizzare strumenti completamente diversi nati
apposta per quel tipo di applicazioni (linguaggi di scripting vari o
Java). Per Intranet il discorso è diverso in quanto, essendo normalmente
presenti server propri, è possibile installare qualsiasi tipo di
software su di essi e quindi con il CGI si può utilizzare qualsiasi
strumento.
EMG
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 wrote in message
c2c7c5114dd8c971654...@mygate.mailgate.org...


 wrote in message
xxXF7.20804$zu5.7...@news1.tin.it...


credo.
Beh, so che non e' forse paragonabile, ma io con ADS della Extended
System ho ottenuto dei risultati decisamente al di sopra del normale
utilizzo dei dbf condivisi in rete. Per la precisione parlo di ADS 5.1
su Server Netware 4.2
Lo dico sono come esperienza che mi sento di riportare, non per fare
paragoni :)
Ciao.Alberto.
-------------------------------------------------------------
Alberto Rubinelli           Mail : 
alb...@retrocomputing.net
A2 SISTEMI                  Http : 
www.retrocomputing.net
Via Costantino Perazzi 22   Tel 0321 640149
28100 NOVARA (NO) - ITALY   Fax 0321 391769
ICQ : 49872318              Odigo : 5269083

 strumento.
Il problema è proprio questo. Io che non sono un programmatore professionista
non ho voglia di studiare Java, html, php, asp, ecc. ecc. Però sarei contento
di usare un solo linguaggio che possa accedere a qualsiasi base dati. 
Probabilmente Java è sulla buona strada.
E mi fermo qui.
-- 
Posted from 
flat-p09-m074.aruba.it
 [62.149.169.76] 


non mi diverto).
Non credo che SQL sia tanto adatto allo sviluppo di applicazioni,
ritengo piu' performante il sistema classico, casomai sarebbe
interessante la disponibilita' di un database manager Client/Server
che permetta di ottimizzare gli accessi al database ed il protocollo
di rete.
SQL e' utile se e' necessario "interfacciare" il database con sistemi
diversi, che richiedono questo tipo di gestione.
[cut]
ciao, acc.   
a...@libero.it

 Il mondo Sql riconosciamolo è un'altra cosa.
Affermazione quanto meno da approfondire, non ti pare? Io l'unica cosa
che vedo nell'SQL è la sua scomodità rispetto alla normale
programmazione procedurale o object-oriented. Va bene per fare
rapidamente solo le cose semplici. Oltre un certo grado di complessità
non si riesce ad esprimere il problema con una query imperativa.


 solo dbf. Senza rallentamenti e senza perdita di dati.
Questo non mi sorprende affatto. Ritengo che l'affidabilità di un
sistema di archiviazione non dipenda dai records coinvolti. Ci possono
essere dei limiti fisici (ad esempio, se il numero di record fosse
contenuto in 16 bit si potrebbero gestire al massimo 64k di records) ma
se non ci sono bugs nelle funzioni di base non vedo cosa potrebbe
cambiare. Forse l'efficienza potrebbe non essere sufficiente ma a quanto
pare non è questo il caso dei DBF.


 ha scritto nel messaggio
news:xxXF7.20804$zu5.7...@news1.tin.it...


 ha scritto nel messaggio
news:9sb3v8$23m$1...@nreadb.inwind.it...


 ha scritto nel
messaggio news:3BE85909...@emagsoftware.it...


 ha scritto nel
messaggio news:6uqgut8n1j0l95kk5...@4ax.com...


 Probabilmente Java è sulla buona strada.
Probabilmente. Ma stenta ad affermarsi come potrebbe. Forse a causa di
scelte sbagliate della Sun (ma è solo un sentito dire).


Mah anche con Vo si può fare un browse di un file DBf e di una tabella sql
in modo molto semplice.  Tutti i vari sistemi accedono a a tabelle sql
ecc... tramite ODBC o altri meccanismi "infernali" inventati da MS. L'ideale
sarebbe avere un interfacciamento "diretto" con le funzioni ecc.. del motore
del DBMS.  Questo ad esempio è ciò che ha realizzato il nostro buon Danilo
Giuliani per VO e MySql. Un'altra casa americana ha fatto la stessa cosa con
Vo e ORACLE.

E' utilizzabile da Clipper 5.3?
Certamente, non l'ho fatto io di persona, che uso ancora la vecchia
5.2E, ma lo usano parecchi con la 5.3
