Newsgroup: it.comp.lang.visual-basic
Titolo: Il "mio Client/Server" - [Lungo] vaneggiamento...

Devo essere impazzito, ma mi è venuta un'idea (lo dico subito, non
originale, non totalmente almeno) che mi pare "non male".
La intitolo "Il mio Client/Server" e, prima di entrare nei problemi tecnici
(che, a naso, non mi sembrano insormontabili), volevo capire se sono
definitivamente andato o se invece posso pensare di svilupparla (magari in
team, perchè no?!):
Parliamo di gestione di database in ambiente di multiutenza.
Disponiamo di una rete locale (per ora fermiamoci qui, ma il concetto è
parimenti applicabile anche a una rete web) con una macchina (una sola, per
semplicità) che fa da server e "n" macchine come postazioni relativamente
"stupide", i client, appunto.
Per capirci meglio (perchè sinora non ho scritto nulla di diverso dalla
realtà che tutti conosciamo), immaginiamo di avere i nostri database
(Access, SQL Server, qualsiasi altro tipo) e i relativi "motori" sul server
e i vari applicativi (per semplicità diciamo uno solo, ma è del tutto
indifferente) che girano contemporaneamente sui client e gestiscono i
database sul server. Insomma, le solite cose.
Ora, usando DAO o ADO o altro verso Access o SQL Server o altro, che
succede? Succede, in estrema brevità, che i vari client chiedono al server
(o, meglio, al motore di gestione del database, che potrebbe essere
residente anche sui client stessi, come accade con Jet) di eseguire
determinate operazioni (magari pre-digerite dagli "strumenti" di interfaccia
che risiedono sul client stesso) sui database. Strutturazione
dell'architettura del database e, più frequentemente, aggiunta, variazione,
eliminazione e lettura di informazioni/records. Ci siamo? Bene, ma come
"dobbiamo" fare queste cose quando scriviamo l'applicativo?
Dobbiamo creare oggetti (database/connessioni, recordset, oggetti
d'architettura come TableDef o Catalog, etc.), connetterci al database con
una sintassi diversa per ogni tipo di database, comporre comandi SQL di
recupero o di azione (anch'essi in alcuni casi da adattare in funzione del
tipo di database di destinazione) e gestire recordset/records in aggiunta,
variazione, eliminazione e lettura (scorrimento). Anche quest'ultima serie
di procedure può essere diversa se sono diversi gli oggetti usati e/o il
tipo di database (si pensi, per esempio, al metodo Edit che c'è in DAO, ma
non più in ADO). Non desidero considerare fastidioso scrivere il codice per
un'operazione o per l'altra, per quanto esso breve o lungo sia.
Ed ecco il sunto della mia pazza idea: Desidero scavalcare ogni tipo di
differenza fra un oggetto e l'altro, fra un tipo di database e l'altro e
eliminare completamente ogni oggetto dalla memoria dei client! Come?
Immaginiamo che sul server giri, fin dalla sua accensione, un programma, "il
mio Client/Server" che prevede la completa gestione (con strumenti e
istruzioni adeguate e assolutamente "classiche") di ogni tipo di database,
supponiamo Access e/o SQL Server. Quel programma è continuamente "in
ascolto" e, com'è giusto che sia, ha la funzione di "servire i client".
Immaginiamo anche che i client non dispongano (quindi anche l'applicativo
scritto) di una virgola di qualcosa che richiami il concetto di database
(quindi niente DAO, ADO, Jet, DSN, ODBC e compagnia bella. Niente di tutto
ciò! Pare poco? Si pensi solo ai problemi che tali oggetti ci regalano...),
ma si "limitino" a spedire comandi al programma-server, certamente
contemplando l'intero linguaggio SQL (quello standard '92, scegliamone uno
che sarebbe ora), ma anche e soprattutto che possano colloquiare col
programma-server con "istruzioni" (in un "linguaggio testuale" inventato)
del tipo DB_CONNECT, RS_OPEN, RS_ADDNEW, RS_UPDATE, RS_DELETE,
COMMAND_SQL_EXECUTE, etc. Insomma, i vari metodi che oggi tutti utilizziamo
per interagire con un database. Tenuto conto del "grosso" del linguaggio
SQL, non sono molti, se ci pensiamo bene.
Che accade, allora? Accade che i client sono molto meno "pesanti", la
sintassi dei comandi per il database (di qualunque tipo esso sia) è _sempre_
quella (le date così, il separatore interi/decimali così, punto e basta!) e,
soprattutto, _sarà sempre quella_, anche per eventuali nuovi tipi di
database coi quali ci si voglia interfacciare (se "noti" al
programma-server). Accade anche, cosa per nulla marginale, che sulla rete
viaggiano (come detto, con una sintassi interna assolutamente inventata e
"aperta al futuro") solo i comandi e i risultati, quelli strettamente
necessari. Immaginiamo che viaggino delle stringhe o, se preferite, dei file
di testo. O, ancora, dei bytes opportunamente compressi per ridurre
ulteriormente il carico di rete e che poi verranno adeguatamente
decodificati da chi li riceve.
Il programma-server che fa? Riceve le richieste e le archivia
cronologicamente, le interpreta e le esegue usando le istruzioni che oggi
usiamo, adeguando il tutto al tipo di database col quale si deve
interfacciare. Il motore del database, qualunque esso sia, farà (attenzione,
localmente) quel che il programma-server gli dice di fare e i risultati
eventuali verranno recepiti dal programma-server stesso che li traduce nella
"nostra sintassi" (ovvero quella che i client si aspettano) e li invia al
client che ha fatto la richiesta.
Ipotizzando che il programma-server sia già scritto e funzionante (ovvio che
nel tempo gli interventi/adeguamenti/bugs si concentrano quasi
esclusivamente sul programma-server, non sull'applicativo), mi fermo e butto
giù, in ordine sparso, quelli che mi sembrano i vantaggi per il
programmatore dell'applicativo:
-Client (e applicativo) liberi da ogni oggetto per la gestione dei database
-Sintassi unica, stabile per l'eternità eppure aperta a nuove
evoluzioni/funzioni.
-Traffico di rete ridotto alla reale necessità, qualunque sia il tipo di
database
-Motori che lavorano solo ed esclusivamente sul server (insomma, anche
Access diventa Client/Server)
-Risultati sempre e comunque interpretabili, sono testi
-Risultati sempre scorrevoli, proprio perchè il recordset non esiste più
-Gestione dei lock sicura in quanto il programma-server fa una cosa per
volta, in ordine di richiesta.
E gli svantaggi palesi. A voi, se volete (ma con cattiveria), quelli che a
me sfuggono:
-Codice per la fruibilità "in chiaro" dei dati, però concentrabile in un po'
di Sub/Function/Cls scritte una volta per tutte
-Necessaria (?) ottimizzazione per recuperare grosse moli di dati a
"pezzettoni" e non in unico blocco. No, lo cancello, il client ha la
stringa/file e ne fa quel che vuole.
-Necessità di "riconoscere" univocamente i records per l'esecuzione di
comandi successivi
Ok, per ora finisco. Solo una domanda: Sono impazzito, ovvero sto inventando
l'acqua calda?

 ha scritto nel messaggio
news:bij5iv$97qdd$1...@ID-174464.news.uni-berlin.de...
: Devo essere impazzito, ma mi è venuta un'idea (lo dico subito, non
: originale, non totalmente almeno) che mi pare "non male".
:
: La intitolo "Il mio Client/Server" e, prima di entrare nei problemi
tecnici
: (che, a naso, non mi sembrano insormontabili), volevo capire se sono
: definitivamente andato o se invece posso pensare di svilupparla (magari in
: team, perchè no?!):
:
: Parliamo di gestione di database in ambiente di multiutenza.
[CUT]
:Strutturazione
: dell'architettura del database
Argomento delicato, CHI può fare COSA, SQL Server e MSDE gestiscono,per
questo motivo, diversi titpi di utenze.
:e, più frequentemente, aggiunta, variazione,
: eliminazione e lettura di informazioni/records. Ci siamo? Bene, ma come
: "dobbiamo" fare queste cose quando scriviamo l'applicativo?
IMHO sono le specifiche del server che devono regolare tali iterazioni. (C'è
chi puote e chi non puote e chi...)
: Dobbiamo creare oggetti (database/connessioni, recordset, oggetti
: d'architettura come TableDef o Catalog, etc.), connetterci al database con
: una sintassi diversa per ogni tipo di database, comporre comandi SQL di
: recupero o di azione (anch'essi in alcuni casi da adattare in funzione del
: tipo di database di destinazione) e gestire recordset/records in aggiunta,
: variazione, eliminazione e lettura (scorrimento). Anche quest'ultima serie
: di procedure può essere diversa se sono diversi gli oggetti usati e/o il
: tipo di database (si pensi, per esempio, al metodo Edit che c'è in DAO, ma
: non più in ADO). Non desidero considerare fastidioso scrivere il codice
per
: un'operazione o per l'altra, per quanto esso breve o lungo sia.
:
: Ed ecco il sunto della mia pazza idea: Desidero scavalcare ogni tipo di
: differenza fra un oggetto e l'altro, fra un tipo di database e l'altro e
: eliminare completamente ogni oggetto dalla memoria dei client! Come?
La vedo dura, conosci meglio di me le differenze tra DAO e ADO, se poi
guardi 
ADO.NET
, l'approccio è cambiato ulteriormente!
: Immaginiamo che sul server giri, fin dalla sua accensione, un programma,
"il
: mio Client/Server" che prevede la completa gestione (con strumenti e
: istruzioni adeguate e assolutamente "classiche") di ogni tipo di database,
: supponiamo Access e/o SQL Server. Quel programma è continuamente "in
: ascolto" e, com'è giusto che sia, ha la funzione di "servire i client".
:
: Immaginiamo anche che i client non dispongano (quindi anche l'applicativo
: scritto) di una virgola di qualcosa che richiami il concetto di database
: (quindi niente DAO, ADO, Jet, DSN, ODBC e compagnia bella. Niente di tutto
: ciò! Pare poco?
Se la metti così devi rinunciare a tutto il modello ad oggetti, puoi solo
limitarti ad interrogare un server ed interpretare le sue risposte, mi
sembra un po' riduttivo.
: Si pensi solo ai problemi che tali oggetti ci regalano...),
: ma si "limitino" a spedire comandi al programma-server, certamente
: contemplando l'intero linguaggio SQL (quello standard '92, scegliamone uno
: che sarebbe ora), ma anche e soprattutto che possano colloquiare col
: programma-server con "istruzioni" (in un "linguaggio testuale" inventato)
: del tipo DB_CONNECT, RS_OPEN, RS_ADDNEW, RS_UPDATE, RS_DELETE,
: COMMAND_SQL_EXECUTE, etc. Insomma, i vari metodi che oggi tutti
utilizziamo
: per interagire con un database. Tenuto conto del "grosso" del linguaggio
: SQL, non sono molti, se ci pensiamo bene.
:
: Che accade, allora? Accade che i client sono molto meno "pesanti", la
: sintassi dei comandi per il database (di qualunque tipo esso sia) è
_sempre_
: quella (le date così, il separatore interi/decimali così, punto e basta!)
e,
: soprattutto, _sarà sempre quella_, anche per eventuali nuovi tipi di
: database coi quali ci si voglia interfacciare (se "noti" al
: programma-server). Accade anche, cosa per nulla marginale, che sulla rete
: viaggiano (come detto, con una sintassi interna assolutamente inventata e
: "aperta al futuro") solo i comandi e i risultati, quelli strettamente
: necessari. Immaginiamo che viaggino delle stringhe o, se preferite, dei
file
: di testo. O, ancora, dei bytes opportunamente compressi per ridurre
: ulteriormente il carico di rete e che poi verranno adeguatamente
: decodificati da chi li riceve.
Si, ma una query pesante è una 'query pesante'.
Anche se interpelli una sorta di StoredProcedure il flusso di dati in
risposta non so quanto tu possa comprimerlo.
: Il programma-server che fa? Riceve le richieste e le archivia
: cronologicamente, le interpreta e le esegue usando le istruzioni che oggi
: usiamo, adeguando il tutto al tipo di database col quale si deve
: interfacciare. Il motore del database, qualunque esso sia, farà
(attenzione,
: localmente) quel che il programma-server gli dice di fare e i risultati
: eventuali verranno recepiti dal programma-server stesso che li traduce
nella
: "nostra sintassi" (ovvero quella che i client si aspettano) e li invia al
: client che ha fatto la richiesta.
Si, ottima idea.
: Ipotizzando che il programma-server sia già scritto e funzionante (ovvio
che
: nel tempo gli interventi/adeguamenti/bugs si concentrano quasi
: esclusivamente sul programma-server, non sull'applicativo), mi fermo e
butto
: giù, in ordine sparso, quelli che mi sembrano i vantaggi per il
: programmatore dell'applicativo:
:
: -Client (e applicativo) liberi da ogni oggetto per la gestione dei
database
Ti ripeto che, ad ogni modo, in locale  il client deve poter utilizzare
oggeti tipo (uso terminologia ADO-like)  Database, RecordSet e affini,
magari disconnessi e indipendenti dal server.
: -Sintassi unica, stabile per l'eternità eppure aperta a nuove
: evoluzioni/funzioni.
: -Traffico di rete ridotto alla reale necessità, qualunque sia il tipo di
: database
Eh...problema annoso...
: -Motori che lavorano solo ed esclusivamente sul server (insomma, anche
: Access diventa Client/Server)
:
: -Risultati sempre e comunque interpretabili, sono testi
:
: -Risultati sempre scorrevoli, proprio perchè il recordset non esiste più
Qui sono perplesso.
: -Gestione dei lock sicura in quanto il programma-server fa una cosa per
: volta, in ordine di richiesta.
Giusto
: E gli svantaggi palesi. A voi, se volete (ma con cattiveria), quelli che a
: me sfuggono:
:
: -Codice per la fruibilità "in chiaro" dei dati, però concentrabile in un
po'
: di Sub/Function/Cls scritte una volta per tutte
:
: -Necessaria (?) ottimizzazione per recuperare grosse moli di dati a
: "pezzettoni" e non in unico blocco. No, lo cancello, il client ha la
: stringa/file e ne fa quel che vuole.
:
: -Necessità di "riconoscere" univocamente i records per l'esecuzione di
: comandi successivi
E tanti altri...
: Ok, per ora finisco. Solo una domanda: Sono impazzito, ovvero sto
inventando
: l'acqua calda?
Non so, ai posteri l'ardua sentenza!
Ciao, Luca.

 E tanti altri...
(Svantaggi, ndr). Per esempio?

l'idea non è malvagia, però secondo me ci sono questi svantaggi:
1) in un'era in cui sta evolvendo .net, tutte queste tecniche su ado
cadranno in disuso, per cui credo sia obsoleto impegnarsi oggi a sviluppare
questo discorso
2) se ho ben capito l'applicativo server si mette a metà strada tra
l'applicazione e il db vero e proprio. Tu svilupperesti questo strato in
visual basic? mmhh......io, credo, se ne avessi la capacità lo svilupperei
con qualcosa di più performante.....
3) non sono molto ben convinto del grande guadagno che ne otterresti. Lo
scopo è quello di ottenere qualcosa di indipendente dal db in uso: ebbene,
non vorrei dire castronate, però anche con ADO puoi ottenere questo
risultato, ovviamente se scrivi codice compatibile con i db che intendi
usare.
E' vero, in alcuni casi devi sostituire l'istruzione IIF di Access con la
CASE di MySQL e la IF di sqlserver 2000, però, ripeto, basta usare le
clausole previste dall'SQL standard per non avere grossi problemi......
4) guarda che è veramente un lavoro titanico. E' vero, basta aggiornare
l'applicativo server, però anche i client necessitano per forza di cose di
essere rivisti ogni volta. Cosa succede se crei una nuova istruzione che
prima non avevi? devi mettere mano a tutti gli applicativi client ed
implementarla dove serve......
altro: .NET va sempre di più verso una concezione disconnessa dei dati, tra
l'altro indipendente dai dati. L'unico oggetto è l'Oledb.OledbConnection, di
cui esiste una variante per ogni db supportato da .net. Ma tutti gli altri
oggetti (dataset, dataadapter, datatable, datarow, etc.) sono indipendenti,
per cui, vedi, la risoluzione ai tuoi problemi c'è....
E' vero, tu dici: ma in vb6 questa cosa non c'è (io non sono nemmeno
d'accordo su questo, vedi prima). Ok, per i progetti vb6 potrebbe anche
servire, però supponi di aver già finito il lavoro: tu ti metteresti
veramente a ritoccare tutti i tuoi vecchi progetti vb6? io, personalmente,
no, a dico sul serio......
dagli applicativi client togli i riferimenti agli oggetti per i database, è
vero, però aggiungi quello del componente server che hai intenzione di
creare......mah.....
boh, non vorrei sembrarti un po' critico, forse lo sono stato......
bisognerebbe pensarci su, credo, una bella analisi.....mah.....
good coding!!!
good coding!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

L'acqua calda no ... diciamo che io sta cosa ci avevo pensato ancora
due anni fa, quando non bazzicavo nemmeno qua sul ng, che probabilmente
come me e te ci hanno pensato anche altri ... ma che per le stesse
ragioni per le quali io ho rinunciato, altri non lo hanno fatto
(tempo) e hanno anche aggiunto l'odioso scoglio dei costi.
Fare una cosa del genere significa scrivere a monte un GB di documentazione
circa i metodi e le routine a disposizione che l'oggetto dovrebbe
esporre. E fare questo è già un lavoro immane, perchè implementare
come dici tu, sintatti dao, ado, 
ado.net
 e via dicendo significa studiarsi
bene ognuno dei seguenti oggetti, e soprattutto sapere quali sono i
loro limiti di performance, abbattendo di conseguenza anche i relativi
difetti con piccoli strategemmi risolti e implementati nelle nostre belle
funzioncine.
Io per esempio dao l'ho sempre snobbato a favore dell'ado. L'ho usato
un paio di volte, ma da quando usci immediatamente ado, vidi subito
i vantaggi e l'ho abbracciai dalla versione 1.5
Boh ... l'idea fattibile, in gruppo sicuramente, vantaggi futuri, quelli
che hai detto mi vanno bene ... sbocchi commerciali, perchè in fondo
bisogna anche pensare alle tasche e non solo ai possibili usi futuri
all'interno di applicazioni in house ... nessuno senza un valido
strumento.
Mi metto in lista se ti serve una mano ...
-- 
Saluti
Andrea Moro

 inventando l'acqua calda?
Inventando l'acqua calda :-)
Saluti.

 originale, non totalmente almeno) che mi pare "non male".
[...]
Cioè hai intenzione di reimplemenate qualcosa come ADO e per giunta farlo in
VB?
I vari dialetti/sistemi server SQL sono nati come estensione/distorsione di
quelli ANSI oltre che per motivi commerciali/strategici anche per
migliorare/ottimizzare/rendere più semplice l'accesso ai dati stessi. Oggi
access, mysql, mssql (per citare quelli che conosco meglio) approcciano il
problema (accesso ai dati) in modi e con ottimizzazioni differenti ognuno
puntando su certe caratteristiche per far breccia sulla clientela: access ad
esempio punta sulla semplicità, mysql sulle prestazioni velocistiche pure
oltre che sul prezzo e naturalmente sul fatto di essere multipèiattaforma,
mssql sulla ricchezza di funzionalità e sulla possibilità di spostare gran
parte del codice sul server.
Creare un filtro comune ansi sql compliant non è ad esempio possibile già
per questi tre prodotti, a meno di rinunciare a gran parte delle
funzionalità degli stessi e ridurre la cosa ad un livello troppo minimale:
ad esempio mysql non è in grado di gestire alcuni tipi di query che invece
access e sqlserver gestiscono (se non con escamotage particolari e in
generale con loop nel software che si collega al server): il sacrificio imho
è spesso troppo alto e nelle mie applicazioni preferisco scrivere funzioni
differenti per DB differenti in modo da sfruttarne (specilamente nei punti
critici) le peculiarità.
Anche i nomi e la sintassi delle funzioni  (ad esempio quelle che agiscono
sulle stringhe) dei tre sopracitati sofware sono molto differenti (a volte
invce sono identiche): sarebbe pesantissimo scrivere un parser SQL chen vada
a modificare al volo sintassi sql e relative chiamate di funzione.
Personalmente lavoro ad un prodotto in grado di interfacciarsi ai tre, mi
sono scritto delle classi che aiutano nel lavoro ad esempio fornendomi la
costante per la cancellazione dei dati tramite query in base al db
utilizzato, oppure per la creazione delle tabelle (questa è particolarmente
ostica dato che i tipi di dati, specialmente per le stringhe, ma anche per i
currency sono profondamente differenti, e in più solo tramite ADOX è
possibibile creare tabelle in access con campi stringa che consentano
l'immagazinamento della stringa vuota (cosa che invece in mysql, mssql e in
generale secondo l'ansi sql è lo standard)), ma spesso le query vanno
distinte e scopro dopo un po' che quello che sembrava funzioanre in realtà
va corretto! Cerco poi per quanto possibile (ad esempio in fase di creazione
degli indici) di sfruttare le peculiarità dei singoli motori.
Insomma l'idea sulla carta è bella ma in pratica impossibile da realizzarsi
senza menomazioni e rinuce pesantissime.
Quanto sopra detto imho naturalmente.
hth,
Alessandro

 l'acqua calda?
Per certi aspetti non è molto diverso da usare piattaforme client server già
esistenti
e molto robuste (vedi oracle). La diversità sta probabilmente
nell'omogeneizzare a valle
la gestione del RDBMS che sta a monte, infischiandone di cio che c'è (Access
, SQL - Server , etc).
Concettualmente ciò non è diverso da ODBC, l'applicazione invece è
notevolmente diversa.
Ravviso piu ROI (Return on Investment) mentale che non di Business, e quindi
l'articolazione teorica
in conclusione mi sembra piu accademica che applicabile nella relata
informatica; ma questo è solo il mio parere.

 boh, non vorrei sembrarti un po' critico, forse lo sono stato......
Mi sta benissimo, Igor. L'avevo detto: "con cattiveria".

 Mi metto in lista se ti serve una mano ...
Grazie.

[*Gabriele Del Giovine [MVP]*=gabriele_@_
delgiovine.it
] ha scritto:

Guarda, l'unico dubbio che avevo era se avresti risposto o meno.

 di sfruttare le peculiarità dei singoli motori.
Appunto. La mia presunzione sta nel voler concentrare tutte le differenze in
un punto solo, lasciando l'applicativo uguale.

 valido strumento.
Cominciate con il controllo dei brevetti esistenti e futuri! Non vorrete
mica che poi vi soffino il lavoro vero?

 originale, non totalmente almeno) che mi pare "non male".
L'idea è valida.
Non originale, effettivamente, ma la differenza la potresti fare se
finalmente tu riuscissi a farci lavorare qualcuno sopra.
Ad oggi, tutto ciò che faccio è grossomodo indipendente dal db, nel senso
che, come so fai anche tu, non esiste che io apra un recordset o una
connessione direttamente nel form. Dal form, chiamo una mia funzione
Apri_Connessione, Apri_Recordset, Esegui_Comando, ecc..., a cui passo come
parametro il tipo di db, per cui anche la sintassi Sql viene leggermente
variata in funzione del db stesso.
Quindi, si tratterebbe solo di formalizzare questa cosa, e di spostarla lato
server.
Vedo solo un problema, comunque superabile:
Di ADO, uso moltissimo le funzionalità lato client, ossia Filter, Sort,
Move, ecc..., e trovo molto comoda la struttura dell'object model del
recordset, con le sue collection Fields, da cui accedo a dettagli importanti
del campo.
Se eliminiamo Ado (e, lo ammetto, mi piacerebbe), dovremmo creare una o più
classi da utilizzare come supporto dei dati lato client, cercando di
rimanere sui buoni livelli di performance di Ado.
Un filo più complesso potrebbe diventare la gestione asincrona lato client,
dovendo in qualche modo gestirci un polling del socket per intercettare la
fine di qualcosa, e scatenare quindi l'evento corrispondente.
Complesso, certo, ma non impossibile.
A questo punto, il discorso deve spostarsi sui tempi.
Sviluppare una cosa del genere richiede (limitandoci, per il momento, a
Access, Sql-Server, Oracle e MySql), una stima spannometrica di:
Analisi e formalizzazione specifiche: 1 mese_uomo
Sviluppo lato server: 3 mesi_uomo
Sviluppo lato client: 3 mesi_uomo
Test e Debug: 2 mesi_uomo
Test finale e rilascio: 1 mese_uomo
Anche prendendo con le dovute molle la stima sopra, abbiamo un totale di 10
mesi_uomo, ossia un costo di 30.000Euri.
Bene. Se qualcuno ha tempo da dedicare a questa cosa, allora il costo
diventa 0 (se in alternativa deve guardare la tv...).
Siccome credo improbabile che una persona con le dovute competenze abbia
tempo libero per questo progetto, occorre che la cosa avvenga
professionalmente.
Spostiamo ulteriormente il tiro: quanto si può ricavare dal rilascio di una
soluzione come questa?
Poco o niente. Siamo partiti dicendo che uno degli obiettivi era eliminare
la necessità di Ado, quindi tutto il lato client va rilasciato sotto forma
di codice sorgente, affinchè sia compilato all'interno del client
(altrimenti avremmo un Wolf_DAC 2.71 da installare dopo DCOM98 ecc...).
Qualcosa si può ottenere 'vendendo' il lato server già compilato...
Fine delle riflessioni.
ciao
Alberto

 informatica; ma questo è solo il mio parere.
E' anche il mio. Lo farei a tempo perso e per puro diletto. Poi, come si sa,
quando una cosa c'è e funziona (dopo 8000 test) la si può anche usare e,
magari, vendere...


E' solo che vorrei farti notare che quello che tu vuoi realizzare è stato
realizzato. ODBC,  DAO, ADO, RDO, JDBC sono solo alcuni.
Esiste poi tutto l'insieme dei wrapper che permettono di separare la logica
applicativa
e la logica di accesso ai dati dalla componente di presentazione (il
client), per realizzare
la cosiddetta logica a 3 livelli.
Per VB ad esempio esistono tutta una serie di prodotti che fanno questo in
automatico
a partire dalla struttura del DB. In azienda usiamo un prodotto che fa ciò
Ottieni i sorgenti di una serie di oggetti COM che implementano delle
interfaccie consistenti indipendentemente dal wrapper di accesso ai dati
(ODBC, DAO, ADO, RDO, librerie native)
Molti dei prodotti di data-modeling fanno la stessa cosa. Disegni il DB e
loro ti generano
gli oggetti per la manipolazione del db, ovviamente sempre usando una
interfaccia comune.
Per interfaccia comune o consistente intendo il fatto che il programmatore
applicativo
si trova sempre di fronte agli stessi metodi e non si cura di cosa
effettivamente lo mette
in comunicazione con il back-end (il db).
A che serve tutta sta roba? A rendere il client il più leggero possibile.
Considera
che questi oggetti (COM, Java Beans, Web Services) stanno normalmente NON
sul client.
Vengono invocati dal client per mezzo di meccanismi di invocazione remota
(DCOM, RMI, Soap o quel che ti pare). Se poi metti questi aggeggini dentro
un Transaction Monitor ottieni
anche benefici relativi al fatto che scrivi codice in barba a qualsiasi
rogna relativa alla concorrenza, alla scalabilità ed alla disponibilità
degli stessi. E ti permettono di avere
meccanismi di transazione distributa anche su DB di produttori diversi
perchè esiste una specifica comune fatta dall'X/Open per coordinare i vari
monitor di transazione dei DB server
fra loro.
La tua iniziativa rimane comunque ammirevole. Anche io tre anni fa mi sono
scritto
per puro piacere personale una intera implementazione di SOAP lato server e
client
con tanto di meccansimo di serializzazione/deserializzazione in XML di
oggetti COM e
tipi semplici ben sapendo che .NET ed il SOAP Sdk per VB 6 facevano la
medesima cosa.
L'unica cosa è che il mio oggetto per la serializzazione/deserializzazione
di oggetti COM
NON richiede l'implementazione dell'interfaccia IPropertyBag :-)
Saluti.

 sacco di prestazioni.....
Se implemento le peculiarità di ogni cosa che prevedo, no. Perchè alla fine
le uso come adesso.

 possibile.
Ecco, io voglio (vorrei, ovviamente) anche concentrare tutto in un unico
programma, lasciando la sintassi di utilizzo fissa e valida perennemente,
anche quando ci sarà 
ADO.NET
 versione 45. Il programmatore non deve più
impazzire per una cosa nuova o un bug scoperto. Il suo applicativo non
cambia di una virgola. Dovrà solo aggiornare, eventualmente, il
programma-server. Il "framework-server", come mi piace chiamarlo.


Fatti un giro su 
www.componentsource.com
. Rimarrai sbalordito.
Ed alla fine ti costa pure di meno :-)
Saluti.

 il lato server già compilato...
Certo. Che "vale" è il nocciolo, il lato server che però, paradossalmente,
per essere apprezzato, andrebbe distribuito gratuitamente, come il framework
di net... ;-)

 l'acqua calda?
Non sei impazzito, ma stai cercando la risposta che tutti stanno cercando a
diversi ordini di problemi.
Stando in ambiente personal computer e vicino a casa ms:
1) Interfaccia verso database diversi:
Problema annoso: padre di tutti i problemi...
vedi sotto.
2) Sintassi standard:
La sintassi xbase è stata storicamente uno dei primi tentativi di
standardizzare il linguaggio di interrogazione dati, in ambiente pc.
Sql è la risposta più strutturata della comunità degli sviluppatori alle
esigenze di standardizzazione della sintassi di accesso ai database (non
solo in ambiente pc).
Odbc, Dao (per certi aspetti, meglio sarebbe parlare dell'applicazione di
dao a odbc), ado, 
ado.net
 sono le risposte in termini di standardizzazione
dell'interfaccia ai database da parte di ms.
Il problema, tuttavia, non è risolvibile.
Sql stesso lo dimostra: tutti si dichiarano "compliant" con sql standard,
'89 o '92 che sia, ma _tutti_ implementano le proprie personali "estensioni"
al linguaggio.
Le esigenze commerciali prevalgono su quelle puramente tecnologiche.
Sono poi particolarmente significativi casi come quello di access, strumento
desktop destinato anche (e più) agli utenti "final" e come tale "ampliato"
verso il basso...
3) Accesso attraverso oggetti:
Si potrebbe disquisire per parecchio sulla "reale" necessità di utilizzare
degli oggetti per l'accesso dati.
Linguaggi come il cobol ne fanno allegramente e performantemente a meno.
Odbc stesso non è interfaccia ad oggetti e nulla ti vieta di gestire dati
senza interfaccia oggetti neanche in vb.
Ma la possibilità, introdotta da dao e magnificata da ado di getire i
database ad oggetti ha reso molto più semplice e gestibile il passaggio da
un motore dati ad un altro, ha avvicinato l'obiettivo della sintassi comune,
ha (imho quel che più conta) avvicinato la logica mentale stessa dello
sviluppatore alle esigenze del client-server.
Mi pare di capire che il fatto di dover installare gli oggetti di accesso
dati sia uno degli aspetti che più ti danno fastidio.
Credo, onestamente, che, non fosse per il vizio perpetuo di ms di cambiare
le carte in tavola da una release all'altra dei suoi stessi prodotti (e qui
penso ai cambiamenti di logica che stanno tra ado 1.2 e ado 2.7 ma, a
maggior ragione, verso ado.net...), allora non ti turberesti tanto...
sbaglio?
Soluzioni:
1) la più semplice: usa un motore database unico.
Personalmente da tempo punto su Sql server:
    - performance ottime
    - costo "onesto"
    - disponibilità di una versione light e free come msde.
Occasionalmente, per progetti di basso profilo e tendenzialmente monoutenti,
mi affido ancora a jet, che presenta il vantaggio di non richiedere
l'installazione del motore database.
2) pur usando motori diversi di database, interfaccia attraverso un'apposita
classe che riesca a tener conto delle divergenze tra provider oledb e tra
sql differenti.
3) usa la tua soluzione:
attenzione che temo ci sia molto, molto, molto, molto lavoro da fare per
ottenere un prodotto prestante, debuggato, in gradi di transazionare
correttamente e di gestire correttamente la multiutenza.
Per certi aspetti, i problemi che potresti incontrare, sono simili a quelli
classici di un database replicato.
Fai un po' di test "pasticciati" su una replica di database e poi ne
riparliamo...
(anche in termini di "costo" economico di un simile progetto...)
ciao
ugo

 differenze in un punto solo, lasciando l'applicativo uguale.
E' imho antieconomico sviluppare qualcosa di simile... significherebbe avere
oltre al costo per lo sviluppo, anche un costo di addestramento ad un nuovo
"linguaggio" senza certezza sulla protezione dell'investimento...
...e soprattutto non abbiamo ancora parlato di prestazioni! :(

 magari, vendere...
Allora in bocca al LUPO.....

 (anche in termini di "costo" economico di un simile progetto...)
Sì, ma ora sono in fase "cervellotica", non scrivo una riga.

 ...e soprattutto non abbiamo ancora parlato di prestazioni! :(
Già.

allora, vado avanti qua. mi pare che il riassunto delle caratteristiche di
questo framework-server debbano essere le seguenti
1) indipendenza dal database
2) tutta la gestione spostata sul lato server
conclusioni, IMHO:
1) ripeto, come ho detto prima, ADO fa già questo e altro. Dal canto mio,
uso ADO dalla release 2.0 fino ad oggi ed ho sempre avuto a disposizione gli
stessi oggetti. Ovvio, mdac_typ adesso supporta xml, e un mucchio di altre
funzionalità, ma per avere a che fare con più db diversi (che è il
presupposto di Lupo), mi sono limitato ad usare le caratteristiche base. Per
questo, ripeto, non vedo alcun particolare vantaggio.
2) sì, questo è vero, è tutto lato server. ma a questo punto, mi chiedo: da
un punto di vista commerciale (io lavoro in proprio e devo fare questi
ragionamenti), è molto diverso vendere una soluzione Access-based piuttosto
che MSDE o mysql e simili. E' vero, Lupo, dal punto di vista della
programmazione non cambia nulla, se usassimo il tuo framework, però non
cambia nemmeno nulla dal punto di vista prestazionale, dato che
indipendentemente dal tipo di db usato, ci si appoggia sempre sullo stesso
framework per l'accesso ai dati.
sinceramente, non ne vedo un gran vantaggio, ecco, è questo il discorso. Il
server che ritorna i dati all'app client tramite stringhe secondo me è un
po' pesante, c'è un sacco di overhead sulla rete.
Ci sono un po' di punti oscuri, e secondo me i vantaggi non sono così
evidenti.
L'unico tratto essenziale, credo, è l'indipendenza dal db, problema già
risolto con ADO, ripeto. Lo faccio da anni.


 già risolto con ADO, ripeto. Lo faccio da anni.
None! GoTo 1*) ;-)

 l'acqua calda?
Allora.. secondo me nn e' che tu abbia "inventato l'acqua calda", ma stai
semplicemente implementando quella che e' conosciuta come un'architettura
a piu' livelli... Hai certamente dei vantaggi, ma cmq ricordati che
risparmi si tempo se devi effettuare delle modifiche al DB (nel senso
cambiare tipo di DB o, forse, poche altre modifiche radicali), ma ne perdi
un sacchissimo per fare tutto questo lavoro...
Che cmq e' quello che in .NET puoi fare tranquillamente basandoti su delle
datatable che passerai a un motore server che creera' SqlDataAdapter,
OleDbDataAdapter, OdbcDataAdapter a seconda della situazione....
Insomma.. secondo me e' un lavoro troppo lungo, che ci si puo' in gran
parte risparmiare senza assolutamente penalizzarsi....
Inoltre ricorda che cosi' nn rendi completamente slegato il client:
difatti se devi aggiungere nuove funzionalita' (ES: Un wizard... boh...)
devi interevnire direttamente sul client, o prevedere che questo effettui
degli "aggiornamenti automatici" dal Server.. oppure fare tutto via Web
:))))
Ciaoooo!! :DD
DisgustingAngel
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 fare tutto via Web :))))
No. Il client/applicativo (salvo l'uso di nuove funzionalità, a libera e
totale discrezione del programmatore) nooooon cambia! Non ha oggetti da
installare, nè cambia la sintassi. Non devo nemmeno ricompilare. Cambia solo
il programma-server!!!

 il programma-server!!!
Non vorrei deluderti ma hai inventato CICS o DCE/RPC o JAVA RMI o DCOM o
XML/RPC o SOAP. Scegli la sigla che più ti pare.
PS: sicuramente nei dimentico qualcuna. Mi pare che su Appple e Amagia ci
fossero
anche delle cose simili.
-- 
-- 
Saluti e salute a tutti.
________________
Gabriele Del Giovine [Microsoft MVP] - Windows 2000 - Windows NT 4.0
- Le informazioni fornite in questo messaggio sono fornite
  senza vincolo di garanzia e senza responsabilità alcuna.

vabbè che sei microsoft [MVP], però almeno *Apple* e *Amiga* scrivili
giusto, no???
:-))))
dai, sto scherzando, eh!
cmq, sono d'accordo con te. anche oggi gli applicativi ADO non li ho
cambiati di una virgola dalla release 2.0 alla release 2.7 di
mdac_typ.exe.....semplicemente perchè mi sono limitato ad usare metodi e
proprietà che esistono da un milione di anni.....senza usare nulla di
particolare.....
è questo il succo del discorso, secondo me. Se l'obiettivo principale è
ottenere l'indipendenza dal db, allora è già acqua passata....tutto qua!
per tutti gli altri aspetti se ne può parlare, ma IMHO i vantaggi non sono
rilevanti....


 anche delle cose simili.
Se così fosse (e non ne dubito) perchè tutti noi (comunque molti) usiamo
ODBC o DAO o ADO o 
ADO.NET
 o Piripicchio e stiamo costantemente a
preoccuparci del * o del %, o del Find con più chiavi o una sola o di date
#MM/GG/AAAA# o 'AAAAMMGG' o del DISTINCT in DAO e in ADO e i cursori che
scrollano o no o sono a sola lettura o no o della password per 97, 2000 o XP
o Data-eccetera o ... mille altri ancora.
Io vorrei (veramente ho sperato a lungo che altri, e sappiamo chi, ci
pensassero ben prima) eliminare tutto 'sto casino. Perchè, senza entrare nel
merito delle singole (e incontestabili) peculiarità, tale è!
Ok (lo so, è vecchia, ma non è mai stata una battuta): MS mi assuma, io ho
qualche idea su cosa fare, non ho detto come (per questo ci sono 10^7
persone che stanno ben sopra di me), ma cosa!
Siccome penso che 10^7-tot persone possano essere in MS, allora deduco che
MS non lo fa perchè non vuole, non perchè non può.
Sbaglio? Anzi, RICOMINCIAMO?!

 sono 10^7 persone che stanno ben sopra di me), ma cosa!
Non č compito di Microsoft creare on aggeggio simile.
E' compito delle terze parti costruire i framework applicativi.
Tu nel realizzare un coso del genere vedi le cose dal tuo punto di vista
Un'altra persone potrebbe vederle in maniera completamente opposta
alla tua. Chi ha ragione? Quale interfaccia si include nel wrapper?
E poi, Microsoft ti dice di usare ADO e SQLServer. Fine.
Saluti.

 :-))))
E' vero :-) Non me ne sono accorto......
Apple ed Amiga.
Saluti.

E poi, Microsoft ti dice di usare ADO e SQLServer. Fine.
Messa cosi' sembra un dogma religioso...
-- 
ciao, hal

 E poi, Microsoft ti dice di usare ADO e SQLServer. Fine.
Ed io rispondo NO scordatevelo! <g>
PS:
E poi ADO o 
ADO.NET
? Non hanno nemmeno assegnato delle costanti serie agli
errori di ADO che già hanno deciso di disfare e rifare tutto di nuovo! :-(


No :-)
Per questo ADO (cosi come DAO) non è altro che una interfaccia
ad alto livello per accedere ai servizi offerti da dei provider di dati.
D'altra parte ognuno è libero di farsi male come vuole :-)


 E poi, Microsoft ti dice di usare ADO e SQLServer. Fine.
Tenendo buono SQL ANSI, un'interfaccia per quei pochi metodi, persino
simil-SQL o addirittura simil-Microsoft. Certo, e non ho difficoltà ad
ammetterlo, pur per quei pochi metodi sarebbe "l'ennesima sintassi". Però
perennemente (!) stabile. Se il punto di vista comunemente accettato è
quello, se possibile, di lavorar di meno, credo che tutti (MS compresa) lo
accetterebbe. Presuntivamente (no, non presuntuosamente), s'intende.

infatti lo č, ne dubiti?
:-)))
il fatto č che č giusto che sia cosě: cosa puoi pretendere di meglio che
usare sqlserver e ADO ?
io, sinceramente, nulla di piů.....
ue, occhio: sempre aperto alle novitŕ. ho sistemato proprio durante l'estate
il mio applicativo di punta, ripulendolo e adattandolo per MySQL. Solo dopo
ho scoperto che MySQL non supporta certi tipi di query......dico, MA COME E'
POSSIBILE!!!! Un RDMS serio deve avere dei requisiti minimi........porca
miseria.....
e poi perchč chi ha detto loro di gestire le date aaaa/mm/dd (mi
pare).....se hanno piů ragione loro ad utilizzare questa codifica, perchč
gli altri hanno fatto diversamente?!?!?!?
qui c'č qualcosa a monte in tutto questo discorso: le cose non saranno MAI
le stesse, č assurdo pensare di scrivere un applicativo che possa resistere
per 15 anni al passo della tecnologia di programmazione.......per cui ci
sarŕ sempre qualcosa da riscrivere, sempre qualcosa da fare.....e non solo
dal punto di vista della sintassi, quello č il meno.
Per chi di voi ha guardato .NET, ci č accorto almeno lontanamente che i
concetti di ADO non ci sono piů? Non ci sono piů recordset da aggiornare in
real-time: li "scarichi" dalla connessione sul client, li lavori e li
aggiorni sul db.
E' tutto cambiato: non si naviga piů nei recordset, sembra quasi di
spostarsi in tabelle e matrici.....
questo per dire che le cose a volte subiscono un salto troppo forte per
essere previsto oggi, e fare un framework per l'accesso ai dati che sia
sufficientemente aperto non credo sia fattibile......IMHO.......


 perchč gli altri hanno fatto diversamente?!?!?!?
Veramente tutti usano quel formato, tranne Access...
Ciao
Alberto

:-/
ah, questa mi giunge ora.....scusa, vabbè, a parte Access, io ho usato
MySQL, SQL Server e Oracle.
Quest'ultimo ce l'ho davanti adesso, vede le date in dd/mm/yyyy: prende le
impostazioni internazionali?
sql server sinceramente adesso non me lo ricordo, mah.....sei sicuro?


 spostarsi in tabelle e matrici.....
Cioè si è tornati indietro! Geniale davvero! ;-)

 sql server sinceramente adesso non me lo ricordo, mah.....sei sicuro?
Altro che.
Che ammettano conversioni implicite secondo le impostazioni internazionali o
altri accrocchi del genere, puň essere, ma non ti so dire, perchč io uso
yyyymmdd sempre e comunque, e tutti lo accettano, indpendentemente dalle
impostazioni del server, del db o dell'utente.
Ciao
alberto

sì, effettivamente il discorso del formato fila, anche se come ho detto ad
Albe, mi sembra strano che sia soltanto Access l'anomalo.....Oracle che ho
qui mi fa vedere le date in DD/MM/AAAA.
cmq, nessuno ti dice che tra 10 anni, per qualsiasi motivo, questo formato
non cambierà ancora.....
sarà sempre una continua rincorsa.......e guai se smetterà di esserlo,
IMHO......
i traguardi non si raggiungono mai, si spostano soltanto......
questo costa fatica, ovviamente.....
anche il discorso dei recordset. Una volta i recordset non c'erano. Poi li
hanno creati, e siamo tutti abituati ad usarli.
Chi comincia oggi con .NET non li conoscerà nemmeno, e lavorerà direttamente
con 
ado.net
. Poi però magari le cose cambieranno, ed ecco che anche loro
dovranno adeguarsi.....
scusate, ma voi credete che questi problemi ce li abbiamo solo noi?
chi costruisce cellulari non ha questi problemi?
automobili?


 sql server sinceramente adesso non me lo ricordo, mah.....sei sicuro?
Ciao Igor,
SQL Server offre due data types per la memorizzazione delle date: datetime e
smalldatetime.
datetime
--------
Range di validità: 1 gennaio 1753 - 31 dicembre 9999 con una precisione pari
a 0.00333 secondi.
Bytes occupati: 8 (2 coppie di interi di 4 bytes)
- i primi 4 per la memorizzazione dei giorni prima o dopo l'1 gennaio 1900
- gli altri 4 per la memorizzazione dei millisecondi dopo la mezzanotte
smalldatetime
-------------
Range di validità: 1 gennaio 1900 - 6 giugno 2079 con una precisione al
minuto.
Bytes occupati: 4 (2 coppie di interi di 2 bytes)
- i primi 2 per la memorizzazione dei giorni dopo l'1 gennaio 1900
- gli altri 2 per la memorizzazione dei minuti dopo la mezzanotte
Come vedi le date sono memorizzate internamente come 2 coppie di interi :-)
Per maggiori informazioni leggi il seguente tip:
http://italy.mvps.org/MVPs/lbenaglia/LorenzoBenaglia-Tip-FormatoDate.htm
Ciao!
-- 
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com
http://italy.mvps.org

 meglio di me, poteva/doveva farlo!"?
Mai porre limiti alla Provvidenza :-)
Saluti.

 li lavori e li aggiorni sul db.
Mi hai preceduto :-)
Saluti.

 l'anomalo.....Oracle che ho qui mi fa vedere le date in DD/MM/AAAA.
Qua non ti seguo benissimo.
Siccome Oracle è un servizio non interattivo, tu non puoi avere Oracle
davanti.
Al limite, avrai un client di amministrazione o di interrogazione sql di
Oracle.
Ma, in questo caso, è chiaro che il client non può mostrarti delle sequenze
di bit. Se il campo è una data, ti mostrerà una sua rappresentazione
stringa, e nel passare dal valore alla visualizzazione, necessariamente
prenderà come riferimento un formato delle impostazioni internazionali,
oppure un formato predefinito, ma comunque un formato che non ha niente a
che vedere con la memorizzazione o la sintassi Sql relativa alle date.
ciao
Alberto

automobili?
Mah, non so se l'operaio alla Fiat si scontra con i DataTable...:-)
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

D'altra parte ognuno è libero di farsi male come vuole :-)
Non ne dubito.
-- 
ciao, hal

sufficientemente aperto non credo sia fattibile......IMHO.......
Gia' adesso, imho, 
ADO.NET
 e' persino esagerato.
Tanto, se lavoro con Oracle, lo sfrutto al massimo e me ne frego di un
porting su un altro database: se il mio cliente ha speso 45000 eurI
per il suo db trovo scorretto e disonesto usarglielo al minimo comun
denominatore con un Access.
Se compri una Ferrari che fai, la usi come una Apecar 50?
-- 
ciao, hal

Approposito ... che cacchio hanno votato quegli incompetenti?
Stando a quanto dici, hanno votato picche, vero?
-- 
Saluti
Andrea Moro

 denominatore con un Access.
E' il mio stesso ragionamento di fondo.
Anche se tendo a far spendere al cliente un (bel) po' meno, con sql server.
ciao
ugo

 Non vedo cosa c'entri Sql Server in tutto questo.
SQL Server è di Microsoft.
Non credo che Microsoft ti dica usare ADO ed Oracle :-)
(vedo che a te Oracle piace tanto).
Saluti.

 Stando a quanto dici, hanno votato picche, vero?
No le votazioni dovevano svolgersi il 1° settembre... sembrerebbe (ma mi
riservo di trovare la notizia in inglese dato che io l'olandese non lo
capisco un granchè ;)) che abbiano rinviato al votazione dopo al 20
settembre... la manifestazione è risucita dato che c'erano circa 400 persone
in piazza (e non solo nerd con i brufoli ma anche professionisti e
professori universitari). Qui in italia (con la i minuscola) non è stata
diffusa la notizia della manifestazione ma in Belgio, Francia, Spagna e
Germania sì! ;-)

(vedo che a te Oracle piace tanto).
Perche' funziona benissimo, e' molto piu' configurabile di sql server
e non da tutte le seccature di sql server.
-- 
ciao, hal

Anche se tendo a far spendere al cliente un (bel) po' meno, con sql server.
Ovviamente uso Oracle con chi lo ha gia' (tipicamente grosse
organizzazioni che utilizzano sistemi operativi eterogenei).
Se l'azienda cliente e' medio/piccola o i dati non sono critici e il
cliente ha gia' licenze di sql server, ovvio che lo uso anch'io.
Sono incuriosito da MySql per applicazioni a basso costo, e non
dipendenti da windows, ma non ho attualmente tempo per fare
esperimenti :-(
-- 
ciao, hal
che ha casa, ormai, windows e' solo sui pc di test :-)

che ha casa, ormai, windows e' solo sui pc di test :-)
    ^^^^^
ooops!

 esperimenti :-(
E' veloce, stabile, ma mancano molte cose (che non sono in generale
indispensabili ma a volte sě) e bisogna fare a meno di interfacce
supergrafiche (io btw mi trovo bene con myphpadmin che č decisamente
multipiattaforma ocme interfaccia grafica :P)!

 esperimenti :-(
Un pochetto ci ho giocato:
non malaccio, ma manca tanto (e non parlo di interfaccia).
ciao
ugo