Newsgroup: it.comp.lang.vo-clipper
Titolo: ricerca con SQL Server

Sto facendo il porting delle mie applicazioni Vo 2.5 da DBF a SQL
Server .
Ho un problema, con i DBF nelle finestre mettevo dei pulsanti per
spostare il record in avanti o indietro.
Con SQL non si può fare perchè dovrei scaricarmi tutta la tabella in
locale, o inventarmi qulache sistema che faccia una select
particolare, ed in base a come mi sposto la riesegua.
Qualcuno ha già fatto qualcosa di simile o sa come si fa?
Lo stesso dovrebbe valere per le visualizzazioni in browse.
Grazie
Pietro Angelo Cavoli
ENEA
Servizio Informatico Direzione Centro Casaccia
mail : 
cav...@casaccia.enea.it
http://www2.casaccia.enea.it
http://www.italiantartide.it
 

 ha scritto nel messaggio
news:3f02a2bf....@news.caspur.it...


No, non è esattamente uguale, quando fai una query ti porti dentro
tutti i record che hai chiesto, rallentando di molto l'apertura della
finestra, l'ho testato, non sono un espertissimo di SQL, ma se faccio
una query che mi restituisce tutta la tabella aspetto due minuti
(cronometrati), se faccio una query che mi restituisce 10 record la
risposta è immediata.
Forse sbaglio qualcosa?
PS la tabella ha 10000 record di 3000 caratteri ognuno


 Forse sbaglio qualcosa?
Il risultato di una query è esattamente come una tabella DBF virtuale. Se i
dati ottenuti sono troppi e quindi la risposta del server lenta, (problema
di SQL Server, MySql ad esempio è molto più veloce) devi individuare una
condizione che estratto un certo numero di record, arrivato all'eof riesegue
una query per ottenere un'altro blocco di record.
Con i DBF apparentemente il problema sembra non esistere, perchè la
paginazione dei dati la fa l'RDD. (Vi ricordate nella versione 1 la
browsegranularity ?), con SQL la dobbiamo fare noi.
Devi individuare nelle tue tabelle una condizione che ti permette di
spezzarle. Purtroppo SQLServer non ha nel comando select una opzione che
invece esiste in MYSql che è Select ..................... limit x,y che ti
permette appunto con facilità di spezzare in tronconi da n record il
risultato delle tue query.


Ecco!
Esattamente quello che servirebbe a me, non sapevo che MySQL avesse
un'opzione dele genere, con SQL Server me lo devo inventare io, e non
è esattamente banale, bisogna scrivere un bel po di codice e fare
molti IF...

Pietro Angelo Cavoli


 molti IF...
Tieni presente che l'SQL è stato inventato quando ancora non esistevano
le liste scorrevoli. Mi chiedo sempre perché diavolo dobbiamo utilizzare
tecnologie tanto obsolete. Mah...
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

Hai troppo ragione !
Massimo


Quali sarebbero le tecnologie obsolete?
Se devo cercare un nome e non mi ricordo esattamenente com'è, oppure
voglio scorrere un database per vedere una serie di dati che mi
interessano,  ad esempio una serie di ordini con il loro contenuto,
come faccio?
Apro un'altra maschera che mi fa una query e mi restituisce una serie
di dati ed eventualmente la rifaccio, oppure scorreo il database con i
comendi skip, o più correttamente movenext?
Inoltre, scusa la mia ignoranza, cosa sono le liste scorrevoli,
ariinoltre dove le ho nominate?
L'SQL è stato inventato quando i PC non esistevano, ed ha subito varie
evoluzioni in effetti non esiste più un SQL standard ma esistono vari
dialetti, la funzione che serve a me è implementata su MySQL, come ha
scritto Danilo, ma io uso SQL Server che non ce l'ha.

Pietro Angelo Cavoli


 scritto Danilo, ma io uso SQL Server che non ce l'ha.
E questo fatto non ti sembra di per sé un buon motivo per considerare
tale tecnologia non esattamente il massimo? E poi anche con MySQL ti
tocca comunque fare a mano la paginazione ripetendo la query con
parametri diversi. Insomma, è tornare indietro rispetto alla incredibile
comodità del file sharing.


Enrico Maria Giordano wrote:
 > Insomma, è tornare indietro rispetto alla incredibile
 > comodità del file sharing.
 >
Scusate l'intromissione... e quale strumento prevede il file sharing ed 
esattamente cosa è?
Ciao, Antonio

Polemicuccia in newsgroup.
Ritenere il mondo SQL obsoleto è alquanto paradossale, dimmi come
riesci a gestire database con milioni di record.
Tu che tipo di database usi?
Applica la tecnologia file sharing in un ambiente di campus con 2000
PC e 50 accessi concomitanti e fammi sapere cosa succede.
Gli automatismi di paging esistono, apri un recordset tramite ADO e
vedi come funziona, io uso VO che utilizza chiamate ODBC che non
prevedono il paging.
Io non adopero le listview per visualizzare il contenuto di una
tabella, o perlomeno le adopero poco in quel modo.
Aspetta, stai facendo confusione tra un linguaggio di accesso ai dati
SQL (Structure query language, linguaggio per interrogazioni
strutturate inventato da IBM; negli anni 70 con il nome di SEQUEL,
Structure English QUEry Language), quello attuale è SQL99 o SQL3, e la
tecnologia dei database relazionali, il Basic è un linguaggio di
sviluppo, SQL è un linguaggio per interrogare i database, sono due
cose completamente diverse.
La prima standardizzazione di SQL è stata fatta dall'ANSI nel 1986,
l'ultima nel 1999 (SQL99 o SQL3).
Ovviamente poi ognuno ha implementato quel che volevo.
L'utilizzo del filesharing in ambienti medio grandi "seri" non esiste,
ed anche in quelli piccoli tende a sparire l'uso dei dbf è un
residuato ed anche Acces ha i suoi bei limiti, File Maker non funziona
in modalità sharing, ma su protocollo di rete (IP o altro).
La straordinaria comodità del filesharing va a cozzare contro la
robustezza e la sicurezza delle applicazioni, pensa solo alle stored
procedure oppure ai metodi di rollback, io ho iniziato da poco, ma è
tutto un altro mondo.

Pietro Angelo Cavoli


 ed esattamente cosa è?
La tecnica per cui il database viene condiviso da più programmi. Per
contro, il client/server prevede che il database sia utilizzato
direttamente solo da un unico programma e cioè dal motore (database
engine).


 tutto un altro mondo.
Vedi, io non sono contrario ai miglioramenti tecnologici (ci
mancherebbe!) ma mi incavolo quando incappo in situazioni assurdamente
penalizzanti e in limiti inaccettabili solo perché il mondo è stato
convinto che l'SQL è oro mentre il DBF è pupù. Insomma, anche la
produttività è importante e l'SQL non la favorisce di certo.


 ha scritto nel messaggio
news:3f02a2bf....@news.caspur.it...


facendo finta di non capire in queste cose ci sguazza.
A me pare che quello che fa finta di non capire sia tu, dato che
questo argomento e' gia' stato trattato e le conclusioni sono gia'
state tratte.
Il fatto che poi tu lo faccia 'democraticamente' non fa alcuna
differenza.

 di casa si sta parlando.
A quanto pare non sei in grado di tenere una discussione rispettosa del
prossimo e corretta tecnicamente e quindi evito accuratamente di
risponderti.


 un'ottimo sistema se ben implementato.
Inoltre c'è da dire una cosa molto importante: i database engine hanno
bisogno di manutenzione, di un system administrator che li gestisca. Non
è pensabile di darli in mano ad un normale utente. E per chi, come me,
copre principalmente il target della piccola utenza, l'alternativa
database engine semplicemente non è proponibile. In pratica non esiste.


 ce ne sono eccome!
Le motivazioni di queste mie affermazioni sono già state date ed a lungo su
questo stesso News, comunque mi ripeto:
1 con i dbf (via RDD) è normalmente il client che si preoccupa di scrivere
sulle tabelle.
    con SQL (leggi su) è appunto il motore che si preoccupa di interagire
con le tabelle. Che succede se cade la connessione mentre
ricostrusci gli indici, oppure aggiorni un archivio prezzi perchè hai deciso
che da oggi tutto costa il 2% in più ?
2 Sul server devi avere risorse condivise per accedere alle tabelle,
l'utente della base dati deve essere utente di rete con diritti di lettura e
scrittura almeno sulle cartelle contenenti le tabelle degli archivi.
    Con Sql l'utente può essere ignoto alla rete, deve essere solo utente
del database.Può anche non sapere dove fisicamente è installata     la base
dati. Con i DBF la base dati sta in X:\PIPPO\PLUTO.... etc.
3 il motore del database si preoccupa di consentire o meno le operazioni di
accesso, lettura e scrittura. Con RDD è l'applicativo che         deve fare
tutto ciò, e non mi dire che se hai utenti con diversi diritti di accesso la
cosa è semplice.
    Certo se scrivi applicazioni in cui tutti fanno tutto OK, ma normalmente
non è mai così, un utente deve solo vedere, uno deve vedere     solo alcune
cose, una deve scrivere solo su fatture, uno deve scrivere su articoli, ma
non deve vedere i prezzi riservati e via così.
    La realtà e spesso molto complessa, perchè mi devo smazzare a scrivere
codice quando posso delegare il tutto al gestore del
database.
4 se ho un dipendente infedele, visto che ha accesso il lettura e scrittura,
entra nella cartella degli archivi e fa quello che vuole, copia,
rovina, etc.. con SQL si fa ugualmente ma è sicuramente un pò più complicato
e non alla porata del primo smanettone.
    Deve conoscere la password di amministratore, deve saper installare ODBC
o altro mezzo di connessione, deve conoscere il numero     IP del server,
insomma la tua organizzazione deve avere delle falle.
5 E' vero che anche i DBFs possono essere manipolati con linguaggio SQL, ma
mancando un motore sul server, non solo è                     masochistico,
ma non offre alcun vantaggio.
6 Con SQL posso costringere un utente a lavorare da una sola stazione, è lo
stesso sistema che me lo consente, con DBF lo posso fare     ma non è così
semplice.
7 E' vero che anche i datases SQL hanno indici, ma se la base dati è ben
progettata sono necessari solo per tabelle con un numero             grosso
di record, con qualche migliaio di record (10.000 20.000) non sono ancora
necessari. Ergo ancora più robustezza.

Visto che siamo in un newsgruop che discute di clipper e Vo intendo i DBF
standard di Clipper o VO.
Non vorrai paragonare la robustezza di Oracle, SQLServer, MySql con i DBF
via RDD.
Sulla comodità di interrogazione poi con clipper o vo e DBF devi scrivere
righe e righe di codice con cicli DO WHILE, magari nidificati, per fare cose
che con una query SQL fai con una sola riga di comando, e non dire che non è
vero.
Si tratta solo di saperle scrivere quelle righe.

 EMG
No Enrico è qui che sbagli, nostri applicativi con MySql una volta
installati non richiedono manutenzione.
I clienti me li scordo.
Danilo Giuliani.


Si tratta solo di saperle scrivere quelle righe.
Puoi benissimo fare interrogazioni SQL anche su archivi DBF.  Casomai
non puoi fare il contrario.
SQL e' un linguaggio piuttosto limitato, non puo' certo essere
paragonato ad un linguaggio di programmazione, tutt'al piu' ad una
sorta di script.
Non ti permette la liberta' che invece hai con xBase, questo
naturalmente limita parecchio il campo di applicazione di SQL.
Non e' un caso che gli applicativi piu' complessi con database SQL si
appoggiano su client scritti con linguaggi piu' evoluti (C, C++,
Delphi, vb! e dulcis in fundo... xBase)

E' chiaro che probabilmente stiamo parlando di due film diversi.
Fai affermazioni che non stanno ne in cielo ne in terra, scusami ma il mio
tempo è più prezioso
Danilo Giuliani
"acc" <fa...@address.invalid> ha scritto nel messaggio
news:tt8hgvoaju72pskts...@4ax.com...


Ho scatenato un bel casotto su questo newsgroup, almeno si è un po
movimentato!
Danilo ha perfettamente ragione, basta prendere un qualunque manuale
tecnico sui DBF per leggere le sue limitazioni!
Con SQL l'indice non si corrompre se cade la connessione, in quanto è
il server che gestisce la scrittura e non il client, inoltre se
programmi "bene" hai anche le procedure di rollback in caso di caduta
del collegamento, inoltre puoi dedcidere di ricreare gli indici in
base a determinate condizioni opuure schedulandole.
Prima di parlare e polemizzare bisognerebbe informarsi tecnicamente
sull'argomento, io non vado a "pubblicità", sfrutto la tecnologia
migliore per fare quello che mi serve, e lavorando in un mabiente di
campus (l'ENEA CASACCIA) con 2000 pc collegati e decine di accessi
concomitanti ho avuto modo di constatare le differenze abissali di
prestazioni, robustezza e affidabilità tra un prodotto in file sharing
(che può essere un xbase ma anche access) ed un sistema client server,
certo ho dovuto imparare ha fare il sysadmin di SQL Server, ma almeno
non devo fare continuamente manutenzione agli indici o agli mdb
corrotti!
Non credo che i fautori del file sharing abbiamo mai sviluppato per
più di una decina di accessi concomitanti!
Scusate qualcuno uso l'ADO con i DBF?


Continuo perchè anchio non riesco a stare in  silenzio.
Chi ha deciso che SQL è lento?
acc hai mai fatto una select su una tabella con trenta milioni di
record andando a cercare solo le timbrature di tizio il giorno x?
Fallo con un sistema qualunque.
I Server SQL non hanno solo letture e scrittura, hanno una
configurazione molto più ampia dei diritti di accesso, posso dire che
caio su una tabella puo leggere e scrivere su un campo, leggere un
altro campo e un altro campo neppure deve sapere se esista.
Prima di parlare, come sempre, bisogna fasri una cultura tecnica
sull'argomento, specialmente se si pretende di essere illuminati o
unti dal Signore, ( ne abbiamo uno e basta e avanza) da definire un
sistema nel mondo ritenuto da tutti (o quasi) il top della tecnologia
tecnolgia obsoleta, lenta, inaffidabile e altre cose molto ben
documentate.
Ora scusate ma anche il mio tempo è prezioso, devo realizzare un
sistema che mi permetta di tenere aggiornati e allineati i database
nelle basi iteliane in Antartide con solo collegamenti in dial up,
ovviamnete lo farò in dbf, così la prima volta che il satellite farà i
capricci e cadra il collegamento parto vado in mezzo ai pinguini e
faccio un bel reindex, visto che i pinguini non vogliono imparare ad
usare il file sharing..... sono per il client/server


Grazie per l'informazione, coem spesso succede, si tratta di un modo 
nuovo di definire le cose che ho sempre utilizzato....
Antonio


 Scusate qualcuno uso l'ADO con i DBF?
Non intensivamente ma ho fatto qualche prova con il motore Visual FoxPro
e pare funzionare bene.


 documentate.
Questo tipo di atteggiamento non trova posto in una sana e pacata
discussione. Anch'io potrei dire la stessa cosa di te, no? Solo che io
mi prendo la briga di fare esperimenti...


Scusate qualcuno uso l'ADO con i DBF?
Non credo. Vorrebbe dire rallentare drasticamente l'accesso ai dati
:-)
Saluti
===============================================
Antonello Negrone - Biella - Italy
anto...@anc-software.it
www.anc-software.it

usare il file sharing..... sono per il client/server
Mai provato SPE? E' free :-))


 :-)
Già, però può essere utile se si vuole rendere disponibili gli archivi
DBF anche in applicazioni Internet.


A Roma la ragione non è degli asini, ma di altri tipi di persone...
Precisazioni:
1- il motore jet è sempre in file sharing, non c'è un database server
che risponde ad una chiamata, ma apro il database direttamente da
condivisione, anche se uso il jet.
2 - ADO di Fox pro è diverso dai recordset SQL;
3 - le funzioni di rollback di SQL SERVER o altra DBMS non sono
gestite da programma ma dal motore sul server, esiste anche l'undo di
VO ma se cade il collegamento ci fai poco...
4 - lo scheduler o la programmazione degli indici la fai sempre da
server, ci pensa lui a fare tutto
5 - i file hanno delle limitazioni, tutti, dai dbf ai documenti di
Word, non mi ricordo il limite, non ho il libro sottomano,
6 - Vorrei vedere delle prove comparative, certo se faccio una ricerca
sul mio PC solo soletto è più veloce DB3 plus o Clipper di qualunque
altra cosa, facciamo la prova su sistemi distribuiti con molti accessi
concomitanti
7 - Microsoft è l'ultima arrivata in questo mondo, e la si usa solo
per comodità e perchè noi abbiamo un Contratto di Campus e ci costa un
decimo di Oracle o di DB2, altrimenti utilizzavo MySQL
8 - lungi da me l'idea di imporre la mia idea ;-)
ma quando si fanno polemiche, che sono sempre costruttive perchè si
impara sempre qualcosa, bisogna essere documentati su quel che si
dice, classico il rollback, è una delle cose fondamentali dei motori
client/server, non si può scrivere che la implemento in clipper o
simile!
9 - la pubblicità sarà ure potente, ma seguite un po i professionisti
del settore e chiedetegli come sviluppano le grosse applicazioni, non
le applicazioni per due, tre massimo dieci client!
Per Antonello, un caso singolo non fa storia, bisognerebbe verificare
tutta l'applicazione ed i movimenti effettutati, ricordiamoci che
stiamo parlando di due cose che funzionano entrambe, con delle
differenze, nessuno ha detto in questo ng che gli archivi in DBF non
funzionano, io li ho usati fino all'altro ieri, ed attualmente ho due
applicazioni per la gestione delle timbrature una scritta in VO con
archivi dbf l'altra sempre in VO ma si appoggia a SQLServer, la prima
la mantengo per compatibilità perchè deve scaricarmi i dati su un
vecchio programma di gestione del personale in VB e ti posso garantire
che la differenza di prestazioni è notevole, con lo steeso codice, ho
solo subclassato i DBServer di VO, quindi un test efficiente e
riproducibili.
Mi spiace ma non conosco SPE.


DBF anche in applicazioni Internet.
Io già lo faccio utilizzando SPE ed accedo ai dati con DBUSEAREA,
SKIP ecc.ecc.


Mi spiace ma non conosco SPE.
ahi ahi ahi ;-)))
SPE č un motore client/server scritto in VO (da me) nato per poter
accedere ai DBF via TCP/IP senza condivisione dei dischi.
Attualemente SPE ha una estensione che si chiama SPEDBF, il quale non
č altro che un RDD che permette di accedere ai DBF senza dover
riscrivere i programmi, es:
RDDSETDEFAULT("SPEDBF")
DBUSEAREA( true, "MYDB\PIPPO.DBF")
caratteristiche salienti:
- accesso via TCP/IP (LAN, WAN, Internet)
- autenticazione utenti lato-server
- estensibile a piacere scrivendo DLL lato-server in VO
- cache locale dei record
- transazioni che permettono l'aggiornamento (o il rollback)
simultaneo di piu' record in  piu' aree di lavoro 
In fase di sviluppo:
- ricerce veloci utilizzando la libreria FTS (free text search)
Dal numero di download in un paio di mesi, ho potuto
constatare che l'interesse verso i DBF č sempre vivo, e
SPE č una macchiana dell'ossigeno alternativa ;-))
(non vorrei che una battuta banalizzasse l'argomento)


 le applicazioni per due, tre massimo dieci client!
E quali sarebbero questi "professionisti del settore"? Aristotele è
morto da tempo.


 SKIP ecc.ecc.
Ottimo. Ma è solo per VO, vero? Mai pensato di farne una versione per
Clipper/Fivewin o per lo meno per [x]Harbour?


 SPE è una macchiana dell'ossigeno alternativa ;-))
Scusa, mica l'ho capita questa battuta. Che significa? Me la spieghi?
Sono curioso...


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

più di una decina di accessi concomitanti!
Credi o ti sei documentato ?  ROTFL!  Ti invito a leggere cio' che hai
detto tu stesso poco fa...
Ci sono svariate applicazioni realizzate con Clipper (ma anche con
altri sistemi) in rete che prevedono l'utilizzo di piu' posti, se dai
un'occhiata anche sul NG internazionale troverai diverse testimonianze
in proposito.

scusami ma il mio tempo è più prezioso
Chissa', magari su questo potresti avere ragione...

Un Client/Server!
Me lo guarderň

Pietro Angelo Cavoli


Uso file DBF dal DB3 plus, di esperienza ne ho un po' ed ho ancora
moltissime applicazioni scritte in clipper che girano perfettamente,
ho un un programma per l'elenco telefonico interno scritto in clipper
summer 87 e ricompilato con clipper 5.01 con 10 tipi di ricerca
diversi (tag in CDX) ed è una applicazione che batte qualunque
programma in velocità di letture e stampa elenco, ed è usata
contemporaneamente da un centinaio di utenti che ce l'hanno sempre
aperta.
Ma ha appena 3000 record.....


 Mi sono letto tutto il thread e sono un po' sconvolto / perplesso.
Condivido perfettamente tutto ciň che hai scritto nel seguito del
messaggio.


 gestire con sicurezza le transazioni, dai tempi del clipper, ed ora in VO.
Come funzionano RollBack() RollGo()?????
Paolo

 ha scritto nel messaggio
news:beeghu$3uuid$1...@ID-119280.news.dfncis.de...


usare il file sharing..... sono per il client/server
Con xBase puoi effettuare questa operazione automaticamente, come
parecchie altre del resto.  E' un linguaggio di programmazione, e come
tale ti permette di implementare qualunque operazione che lo sia.
Con SQL certe cose mica le puoi fare, anzi per quanto ne so svariate
operazioni di manutenzione e controllo degli archivi non le puoi
proprio fare, non sono previste dallo standard del linguaggio.
Se da un lato hai la possibilita' di effettuare transazioni con un
server SQL senza nemmeno sapere di marca sia, dall'altro penso proprio
tu debba fare ricorso a strumenti alquanto mirati e tutt'altro che
"standard" per poter fare la manutenzione, e sperare che questi
funzionino bene altrimenti non avrai capacita' di intervento.

 wrote in message
0bCOa.623$qa5....@news2.tin.it...


 PC e 50 accessi concomitanti e fammi sapere cosa succede.
Probabilmente a parità di Hardware succedono meno casini rispetto alla
tecnoligia Client server.
Sono pronto a scommetterci una birra :-)
Immagino che si utilizzi della tecnologia attuale, cablaggio categoria 5
switch a 100 Mb etc. e dei processori sui PC di una certa potenza
elaborativa, insomma quello che si trova attualmente in commercio.
Prova a pensare solo al fatto che gran parte dell'elaborazione avviene su un
povero server e ci sono 2000 PC che si grattano le balle in attesa di
risposte dal server (come in Italia, uno che lavora e altri 5 che
guardano...)
non ti sembra uno spreco e una cattiva distribuzione del lavoro?
A me viene l'ansia quando vedo il nostro server di Posta Netware 5 in cui
gira solo il POA di Groupwise (Server di Posta in tecnologia Client Server)
che alla prima interrogazione del tipo cerca tutti i messaggi con scritto
"Enrico Maria Giordano" o "pac" mi spara la CPU alle stelle (40%) e non ti
dico quando lo si fa in due contemporaneamente (90%) , mentre la CPU del
client sta allo 0 percento.
La cosa tragica è che nel client ho un 2,4 GHZ mentre il server è un P 400.
Nell'altro server invece dove ci sono gli archivi DBF del mitico RAP che è
un vecchio, brutto e zozzo programma in Clipper la CPU è sempre tendente
allo zero. Significa garanzia di un Mean Time To Wait costante nel tempo
ogni ora di ogni giorno e ogni giorno dell'anno, fatture o non fatture,
copie o non copie, Backup o non Backup.
Degno di un programma serio e che fa andare avanti le aziende che producono.
Sto aspettando la licenza di prova dell'Advantage Database Server e non
appena ce l'avrò farò tutta una serie di test, ma solo perchè un cliente
desidererebbe avere on line alcuni indici condizionali per una particolare
attività di ricerca.
So già che creerò gli indici in un tempo che sarà circa 1/3 del tempo
attuale ma la CPU verrà sparata almeno al 70%.
Creare un indice in locale la spara al 100%.
Tutto va valutato di volta in volta sempre e le soluzioni migliori
"potrebbero" sembrare "erroneamente" in controtendenza.
Ciao

Potresti fare qualche cosa per Clipper/Fivewin e di conseguenza Harbour?
Aumenteresti ancora di più l'interesse in quanto la diffusione è senz'altro
maggiore

 Ma ha appena 3000 record.....
3000 o 300000 è la stessa cosa

 usare il file sharing..... sono per il client/server
Avete i gruppi di continuità in Antartide?


 dimensioni con i DBF.
Bravo Enrico, non c'č niente di piů veloce.

Simpatico ng ho scoperto che in Italia ci sono 4 persone che parlano
di superiorità di un sistema su DBF.....
Per continuare a parlare, avete mai sentito parlare di carico di rete,
in soldoni traffico?
Mettete un analizzatore di protocollo aprite un file dbf con 1.000.000
di record e dieci indici (CDX con 10 tag) e vedete che succede, fate
la stessa cosa con un client/server, moltiplicate il tutto per cento
(accessi medi durante il giorno di una applicazione media) e poi per
il numero di client e datemi il risultato
Sistemi in Cluster?
Applicazioni distribuite?
Ripeto a chi è sfuggita la cosa, mi compro una ferrari per correre ed
un tir per trasportare merci, se ho applicazioni medio piccole posso
usare xbase e dbf (e lo faccio normalemte) se ho applicazioni medio
grandi in cui debbo rispettare l'integrità dei dati utilizzo un
sistema client/server (visto che ancora si fa confuzione tra SQL e
server, specifico)
Ariripeto le funzioni di rollback sono native sul server, quindi è il
server che fa il rollback non il client, si programma una stored
procedure, le si passano i dati e lei, sul server,  fa le
elaborazioni, molto diverso dal gestirlo sul client, perchè se il
client cade, il rollback lato client non funziona (è caduto il client)
Per quanto riguarda il carico sul server, ovviamente un sistema
client/server carica di più la macchina server, ma mi lascia tanta
banda libera!
Anche qui fare dei test e vedere di quanto si carichi la cpu con SQL
Server, ed invece di quanto si carichi a gestire un notevole traffico
di rete.
Comunque la richiesta da cui è nato tutto il putiferio l'ho risolta
tramite SQL e VO.
Per chiudere ripeto, io programma in DBF dai tempi del DB3 plus ho
sviluppato molte applicazioni in clipper e Vo, conosco benissimo
vantaggi e svantaggi dei dbf e dei linguaggi xbase, conosco però anche
ADO e SQL Server, quindi ho potuto fare le prove comparative e posso
parlare con cognizione di causa di tutte e due i sistemi, non sono
espertissimo ma parlo solo di quello che ho provato, se qualcuno vuole
venire a fare dei test lo accolgo volentieri, e gli faccio fare un bel
giretto per i nostri impianti.


 Bravo Enrico, non c'è niente di più veloce.
In realtà erano 200 record estratti su 2 milioni.


 banda libera!
E' il solito vecchio concetto del collo di bottiglia che si sposta da una
parte o dall'altra
Per quanto mi riguarda io preferisco che si sposti sulla rete e sugli
switches, ormai siamo arrivato al Giga sul rame senza cambiare cavo, vedi un
pò tu
E poi come ho scritto in un precedente post pensare di avere delle CPU sui
clients che stanno idle mi sembra uno spreco.
Se il parco clients è obsoleto allora c'è la bellissima soluzione, molto
venduta da noi e cioè il Citrix Metaframe, viaggia in rete solo il mouse, la
tastiera e l'immagine video. Telelavoro, commercialisti con più sedi, che
non cambiano il loro applicativo neanche se li minacci di morte e lavorano
alla grande con questo software geniale che fa resuscitare i software
gloriosi del passato.

 tastiera e l'immagine video.
Potresti dare ulteriori informazioni su questo prodotto?
Ciao e grazie
Paolo Cherubini

 ha scritto nel messaggio
news:beh4s2$1sr$1...@nntp.weblinea.it...


Grazie
Paolo

Questo ng è diventato il mio passatempo preferito!
Mai detto di essere un saccente, infatti non rispondo mai su questo ng
perchè c'èsempre qualcuno che ne sa più di me, anzi chiedo spesso
La nostra rete e fatta con switch a 100 MB, anche qui leggersi manuali
e caratteristiche delle reti 10base100 switched.
Poi sulla nostra rete non passano solo le mie applicazioni ma anche
altro.
A proposito il livello di occupazione di banda oscilla tra 60 e 80%,
cioè satura.
Il Citrix lo conosco dai tempi di windows NT (1996), ed ho fatto dei
test con la loro versione demo.
Certo però che se mi dici che un sistema client/server carica la
macchina, figurati Citrix, che richiede 64 o 128 MB di ram per client
collegato e buona CPU per fare il lavoro.
Ottimo sistema, da noi hanno messo  un cluster con 12 macchine più una
di riserva per far funzionare tutto il sistema informativo/gestionale
con Citrix.
Non per motivi di traffico, ma di manutenzione dei client,
centralizzato è molto più semplice.
Ne abbiamo un'altro per la gestione degli sportelli energetici
regionali, ci sono uffici in dialup e con citrix riescono a lavorare,
sia chiaro non è roba che gestisco io ma la nostra funzione centrale
info, io sono solo un curioso.


 collegato e buona CPU per fare il lavoro.
Infatti si consiglia di avere una macchina solo per Citrix

 cioè satura.
Mi è venuta in mente un'altra cosa.
Dato che mi sembra esagerato che mediamente siate sul 60-80%
Hai provato a capire chi genera più traffico e perchè
Quando lavoravo come sistemista in banca c'erano dei capi progetto che
mettevano in produzione applicazioni che creavano disastri sia a livello di
mainframe sia a livello di rete. Ovvero programmi scritti da cane, montagne
che partoriscono topolini, obrobri, schifezze, chiamali come vuoi.
Scansioni sequenziali su tabelle immense per cercare un banalissimo dato e
cose del genere.
Creazioni di tabelle provvisorie per tirare fuori due banalissime
informazioni
Il buon senso a volte è la carta vincente.
Quest'oggi abbiamo parlato di CPU, di RETE, di tante cose ma ci stiamo
dimendicando forse che il problema più grande siamo noi sviluppatori che
molto spesso non ottimizziamo il nostro codice e creiamo danni al Sistema
Informatico che ospita il nostro software.

Esistono anche stream multimedia, oltre che il traffico dei
ricercatori sui supercalcolatori, sto all'ENEA ed esiste anche questo,
non abbiamo reti dedicate.
Certo e che gli sviluppatori non tengono mai in conto il problema del
carico sulla rete, confermato dalle discussioni sulla superiorità
presuntta di xbase su client/server.


 presuntta di xbase su client/server.
Scusa sono un pochino stanco non ho capito bene l'ultima tua affermazione
puoi spiegarti meglio così domattina lo rileggo
Buona serata

Mah ... scusate entro anche io e poi esco subito perché non sono ancora
esperto in SQL. Da poco tempo, seguendo i consigli di Danilo, mi sono
addentrato nel mondo SQL creando una applicazione che usa come DB MySQL.
Devo dire che sono molto soddisfatto dei risultati, non ho trovato
complicazioni nello stilare il codice (VO) ed a gestire le tabelle con
Query.  Sul fatto che i DBF siano poco affidabili devo dire che purtroppo...
dico purtroppo il fatto mi sembra vero. Tempo fa in collaborazione con una
ditta abbiamo realizzato un'applicazione per gestire i documenti di
esattoria di una grossa banca di Prato. Ebbene... quando il DBF è arrivato a
circa 400.000 record ha cominciato a vacillare... tipo perdita di alcuni
record o frequente corruzione degli indici. Penso che adesso anche questa
ditta sia andata su DB SQL gestiti da VO.

Bisogna allora dire che le tabelle gestite dai DBMS quali ORACLE, SQL
Server, MySQL sono più sicuri dei DBF ? Che poi usino SQL come linguaggio di
interrogazione questo è un altro paio di maniche. Se la mia affermazione è
giusta allora per certe applicazioni di una certa levatura preferisco i DBMS
che usano SQL...scusate !!!

tecnoligia Client server.
La gestione di un database in rete con approccio Client/Server e'
sempre un'ottima soluzione, permette di ottimizzare l'accesso ai dati
e di minimizzare il traffico in rete.  Ovviamente non e'
indispensabile, dipende sempre dal carico di lavoro.
La questione e' un'altra:
Client/Server non e' prerogativa di SQL, anzi le due cose non hanno
nulla a che vedere l'una con l'altra.
Esistono RDD Client/Server che operano su DBF (vedi ADS).
Mi pare che i sostenitori di SQL non abbiano le idee chiare su quello
che sono le caratteristiche di SQL, e quelle del database che fornisce
questo linguaggio.

presuntta di xbase su client/server.
Non so se sia colpa del tuo Server...o proprio non ci arrivi,
rileggiti i post!  Nessuno qui ha parlato di superiorita' di xBase su
Client/Server (che tra l'altro e' una affermazione che non ha alcun
senso).
L'argomento della discussione era SQL.

 record o frequente corruzione degli indici.
400.000 record mi sembrano veramente troppo pochi perché ci possano
essere dei problemi. Io credo che c'era qualcosa che non andava nel
programma che li gestiva.


 e di minimizzare il traffico in rete.
Detto così è troppo generale. In realtà, come dissi all'inizio di questo
thread, queste tecniche sono nate quando ancora non esistevano i
programmi interattivi. Oggi gli utenti vogliono avere tutti i loro dati
in linea in tutti i modi possibili e questo a volte rende inutili gli
sforzi effettuati per ridurre efficacemente il traffico di rete.


 L'argomento della discussione era SQL.
Infatti. Mi rendo conto di aver contribuito anch'io alla confusione
parlando fin dall'inizio di file sharing. Avrei dovuto limitarmi a dire
(cosa che confermo) che l'SQL è di gran lunga meno versatile dei normali
linguaggi di programmazione (infatti non è un linguaggio di
programmazione). Solo che nella foga ho dato la colpa anche alla tecnica
client/server che forse non ne aveva.


O, meno male siam tornati all'inizio, avevo chiesto se qualcuno aveva
implementato un sistema per fare il paging di una tabella SQL, cioè
scorrerla in avanti e indietro senza doversi caricare tutta la tabella
in memoria.
acc rileggi tu tutti i post e vedi chi ha risposto fuori tono rispetto
alla mia richiesta iniziale, e rileggi anche chi ha parlato di
superiorità tecnologica di sistemi xbase su file sharing rispetto a
sistemi client/server, oltre che a documentarsi tecnicamente prima di
polemizzare è opportuno anche leggersi i messaggi prima di rispondere
pere a mele, tenendo sempre presente che le critiche e le polimiche
aiutano a capire cos'altro esiste al mondo, e magari si scopre che le
nostre convinzioni sono errate e c'è di meglio.


"potrebbero" sembrare "erroneamente" in controtendenza.
Condivido in pieno :-)
Saluti
===============================================
Antonello Negrone - Biella - Italy
anto...@anc-software.it
www.anc-software.it

Clipper/Fivewin o per lo meno per [x]Harbour?
Scritto in VO e quindi compatibile solo con VO. 
Se ci sara' una conversione, sara' per [x]Harbour, sto'
solo aspettando il momento buono per provarlo e valutarlo.


Sono curioso...
Veramente č una battutaccia e pure scritta male, il pensiero č:
"SPE puo' essere considerato una macchina dell'ossigeno alternativa
per far vivere piů a lungo i DBF."
:-)


ditta sia andata su DB SQL gestiti da VO.
Anch'io, tempo fa', credevo il limite di stabilità dei DBF era 100.000
record. Poi mi hanno fatto toccare con mano DBF con milioni di record
e indici NTX sul quale mi hanno fatto fare alcune SEEK praticamente
istantanee.
Da' lì ho compreso che la stabilità dei DBF dipende molto dalle
tecniche di programmazione.
Probabilmente i DBMS sono meno "vulnerabili" a imprecisioni di
programmazione.
Saluti


 solo aspettando il momento buono per provarlo e valutarlo.
Ok, se ti serve aiuto sono qui.


 programmazione.
Giusto. E' come usare un programma già fatto e testato contro il
doverselo scrivere da soli. Ci sono pro e contro. Chiaramente il
programma già fatto non può essere versatile come quello che ci si
scrive da soli. E chi, come me, ha spremuto molto dello spremibile dai
malleabili meccanismi di indicizzazione e integrazione col linguaggio
degli RDD si rende conto di quanti limiti ponga la tecnica
client/server, a fronte dei vantaggi che offre. Secondo me la bilancia
pende dalla parte del file sharing...


 per far vivere più a lungo i DBF."
Ah, adesso è chiaro. :-)



www.anc-software.it
Pietro Angelo Cavoli


ariiva anche a 150....
Gli unici limiti riconosciuti ai DBF sono quelli descritti nella
tabella delle caratteristiche tecniche (vedere VO26pg.pdf).
Brevemente:
Dimensione massima file (bytes): 	
1 billion (NTX)	2 billion (CDX) 
(1 billion, se non erro è 1Gb, ponendo un record lungo 255 bytes
otteniamo 3.921.568 records)
Max records:
500.000 (NTX)	1 billion (CDX)
Numero ordinamenti per workarea:
15
Ho cercato anche informazioni sui limiti di utenti contemporanei e,
come immaginavo, non ho trovato nulla.
A questo punto credo che i limiti siano (se ci sono) imposti dal
sistema operativo e dal file system. O no?
Saluti


Ok, se ti serve aiuto sono qui.
Bene, sento che presto arriveranno alcune domande :-)
Anzi, domanda veloce veloce: il compilatore di xHarbour
ha ancora bisogno di un compilatore C?


 sistema operativo e dal file system. O no?
Esattamente.


 ha ancora bisogno di un compilatore C?
Sì. Ti consiglio il gratuito Borland C++ 5.5.1. Oppure, se ce l'hai, il
MS Visual C++. Il fatto di aver bisogno di un compilatore C è la
semplice idea che ha reso possibile che [x]Harbour fosse
multipiattaforma e multilinguaggio. Infatti Antonio Linares ha già
avviato la parte di Harbour (per il momento non xHarbour) che genera, al
posto di codice C, codice IL (Intermediate Language di .NET). Ho provato
e già alcuni minuscoli programmini di esempio possono essere compilati
ed eseguiti nella .NET framework (tra l'altro con eseguibili
incredibilmente piccoli - roba tipo 3 Kb!).


Sě. Ti consiglio il gratuito Borland C++ 5.5.1.
Io l'ho scaricato, ma mi hanno mandato uina chiave che dicono valga
per alcuni mesi. O forse ho scaricato una versione piu' nuova?

nostre convinzioni sono errate e c'è di meglio.
Capita a tutti di dire cose imprecise, a volte si fraindende il
messaggio originale o per altri motivi, perlomeno a me capita, e non
ci vedo nulla di male.
C'e' chi ha il buonsenso di ammettere l'errore o di discuterne se non
ritiene di aver sbagliato e chi preferisce svicolare o cambiare
discorso.
Da te non ho ancora avuto risposta ne' smentita alle questioni
sollevate, per ora l'unica novita' e' il fatto che tu hai studiato ed
io a quanto pare no.
Ok, puo' darsi che qualcuno ti creda sulla parola, io invece trovo
strano che una persona cosi' preparata non risponda con valide
argomentazioni a sostegno delle proprie affermazioni.
Se sto solo perdendo tempo, abbi almeno la compiacenza di dirmelo.
Ma risparmiati risposte 'generiche' e insensate che non portano da
nessuna parte.

sforzi effettuati per ridurre efficacemente il traffico di rete.
Enrico, sono d'accordo con te riguardo alle critiche su SQL.  Se
parliamo in termini di "prestazioni pure", SQL non brilla di certo.
Naturalmente SQL ha altri vantaggi e chi lo sceglie tiene conto di
altre caratteristiche.
Riguardo invece all'approccio Client/Server contro il classico
sharing, devo dissentire.  Se l'applicazione ha un elevato numero di
transazioni la soluzione Client/Server e' sicuramente piu' efficiente.

per alcuni mesi. O forse ho scaricato una versione piu' nuova?
Forse hai sbagliato prodotto, magari hai scaricato una versione "di
prova" del compilatore C++ di Borland o del C++ Builder.
Quello a cui si riferiva Enrico e' una versione completamente "Free"
del C++ Builder, che contiene soltanto il necessario per compilare
(compilatore, librerie, header e qualche utility), manca l'IDE e tutto
il resto.  La licenza comunque e' piuttosto permissiva ne permette
l'uso anche per lo sviluppo di applicazioni commerciali.
Questa distribuzione e' definita come: "C++Builder 5 command line tool
development system" e la trovi sul sito "Community" di Borland:
http://community.borland.com
Per scaricare il pacchetto e' necessario registrarsi sul sito,
operazione comunque gratuita, il file (zippato) e' circa 8.5 MB.
Sul sito "commerciale" di Borland puoi invece scaricare liberamente la
documentazione (file di Help ecc.), nella sezione relativa C++
Builder.

>transazioni la soluzione Client/Server e' sicuramente piu' efficiente.
per l'approccio client/server hai scritto quello che ho sempre scritto
io, però non si può parlare di prestazioni di SQL, dipende da come
accedi al database, con ODBC o ADO?
Inolte dipende soprattutto da che DBMS adoperi, tra SQL Server, DB2,
Informix, Oracle e MySQL ci sono notevoli differenze di accesso ai
dati, inoltre il tempo di accesso alle tabelle in scrittura è
condizionato fortemente dalle regole di integrità che hai impostato
sulla tabella, se hai messo che nessun valore può essere NULL e
determinati campi devono contenere un range di dati ben preciso i
tempi aumentano.
Poi un giochino, perchè potrebbe essere che in effetti mi sono
dimenticato come si programma in VO o clipper, questa è una query SQL
che mi da la somma degli ordini effettuata dall'unità CAS nel 2003
SELECT SUM(ImportoEURO) AS Expr1
FROM  dbo.tblRichieste
GROUP BY UnitaAddebito, Anno
HAVING (UnitaAddebito = N'CAS') AND (Anno = N'2003')
Query scritta usando il pannello viste di SQL Server in maniera
visuale, i ritorna il campo Expr1 con la somma, scrivendo tramite il
normale approccio xBase ci dovrebbe volere molte più righe.


 per alcuni mesi. O forse ho scaricato una versione piu' nuova?
Uhm... questa mi giunge nuova. Forse hai scaricato, appunto, la 6?


 transazioni la soluzione Client/Server e' sicuramente piu' efficiente.
Dipende sempre dal tipo di transazioni. Il concetto di transazione è poi
molto simile a quello di elaborazione batch, molto lontano dalle attuali
esigenze interattive di cui parlavo sopra. Secondo me il client/server
perde parecchio terreno, come efficienza, nei programmi puramente
interattivi.


prova" del compilatore C++ di Borland o del C++ Builder.
E' vero, ho scaricato la versione prova del 6. Ora mi sono scaricato
il compilatore 5.5.1 e non mi ha fatto storie :-)

Uhm... questa mi giunge nuova. Forse hai scaricato, appunto, la 6?
Si, errore mio :-)

 > Grazie


ordinamenti per workarea.
Ho fatto una prova sul campo creando 20 tags in un CDX e tutto
funziona bene.
Probabilmente la documentazione è obsoleta.



Io lavoro da poco con SQL e VO ma dagli insegnamenti avuti dal buon Danilo
Giuliani ti rispondo dicendoti che in pratica dipende dal DBMS con cui
lavori. In genere tutti i motori DBMS gestiscono in automatico il blocco
/sblocco del record, quindi non ti devi più preoccupare. In MySQL si deve
bloccare il record da programma. Esiste lo statement LOCK TABLES e UNLOCK
TABLES, che si usa solo in caso di modifica di un record. Per la
cancellazione e append di un record, non è necessario... fa tutto il motore
in automatico.

 ha scritto nel messaggio
news:nQUPa.21180$it4.5...@news1.tin.it...

Io veramente mi riferivo a tutte quelle situazioni in cui vengono coinvolte
più tabelle e spesso più record della stessa tabella e quindi prima di
iniziare la transazione mi preoccupavo, in DBF, che tutti i record coinvolti
fossero stati bloccati correttamente.
In SQL la fase di interrogazione "SELECT" e la fase di aggiornamento sono
ben distinte, chi ci assicura che dopo aver fatto l'interrogazione ma prima
dell'aggiornamento qualcuno non abbia modificato qualcosa ?
Grazie a tutti e buone vacanze a chi va ...

interattivi.
Il protocollo utilizzato durante lo sharing e' piu' pesante rispetto a
quello utilizzato da applicazioni server/based (stile ADS).
Naturalmente il traffico diventa pesante quando si fanno estrazioni
complesse o comunque elaborazioni che coinvolgono parecchi record.
Nei casi di data entry, e piccole elaborazioni invece la differenza
tra ADS e il classico sharing e' minima ed il problema ovviamente non
si pone.

 complesse o comunque elaborazioni che coinvolgono parecchi record.
Appunto. E' lě che il client/server, secondo me, perde terreno in quanto
non consente tutti i trucchetti e le ottimizzazioni possibili con il
file sharing. E nelle applicazioni attuali (come dimostra il problema
che ha originato questo thread) la classica query che restituisce il
piccolo dataset non č molto utilizzata.


piccolo dataset non č molto utilizzata.
Al contrario, quello e' proprio il caso in cui il server guadagna di
piu'.  Mi pare di capire che stiamo parlando di due "server" diversi,
e forse e' il caso di chiarire...
Io mi riferisco al modello utilizzato da ADS, che opera in modo
differente rispetto ad esempio ai classici SQL, (Enrico ti prego, non
cadere anche tu nell'equivoco...)
Se dai un'occhiata alla documentazione di ADS (so che con Harbour
viene distribuito anche un client ADS, non so pero' se sia
accompagnato da una documentazione completa) ti accorgerai che
supporta praticamente tutte le classiche funzioni di xBase, percio' i
trucchetti e le ottimizzazioni si fanno anche qui e piuttosto
semplicemente, e' sufficiente lasciare il codice cosi' com'e', senza
modifiche ;-).
Il miglioramento che un server (stile ADS) introduce forse e' un po'
nascosto, perche' e' implementato a livello di protocollo.  Le
funzioni sono le stesse, ma il traffico che queste generano sulla rete
e' minore; anche il carico del server diminuisce, e non solo a causa
della riduzione dei messaggi ma anche grazie ad una migliore gestione
delle risorse (meno accessi al disco).

 delle risorse (meno accessi al disco).
Certo, un RDD di questo tipo può ottimizzare il traffico (al prezzo,
come abbiamo visto, di una minore versatilità). Ma un normale motore
client/server basato sull'SQL ha molte meno chance.


 programma che li gestiva.
Concordo, ho in giro gestioni di magazzino con due o tre milioni di 
record (DBFCDX) e mai dato rogne.
Ciao.Alberto.
-- 
Alberto Rubinelli - A2 SISTEMI               posted with Gravity 2.60b
Via Costantino Perazzi 22 - 28100 NOVARA (NO) - ITALY     ICQ 49872318
E-Mail : 
alb...@retrocomputing.net
  Tel. 0321 640149 
Web    : 
www.retrocomputing.net
      Fax  0321 391669 BBS  0321 392320

 riscrivere i programmi, es:
Ma si tratta di un progetto opensource o di un prodotto commerciale ?


>Ma si tratta di un progetto opensource o di un prodotto commerciale ?
Si tratta di un prodotto freeware, il motore e le varie DLL si possono
utilizzare sia per lo sviluppo che per gli utenti finali senza limite
di numero. 
I sorgenti invece si pagano ma non si possono distribuire ne'
diffondere gratuitamente.
Ciao
Antonello
===============================================
Antonello Negrone - Biella - Italy
anto...@anc-software.it
www.anc-software.it

I sorgenti invece si pagano ma non si possono distribuire...
...ne' gratituitamente ne' a pagamento.
Ciao
