Newsgroup: it.comp.lang.vo-clipper
Titolo: [CLIPPER] Continuano i problemi con il driver DBFCDX

 va gestito in maniera diversa dal normale perchč cosě č solo un gran casino.
Oltre a quello che ti ho consigliato sopra, non mi viene in mente altro.
EMG

 > va gestito in maniera diversa dal normale perchè così è solo un gran


 La mia procedura che doveva essere semplicissima ...
Allora, se ho capito bene, il tutto potrebbe essere risolto
in modo più pulito come segue :
dbusearea(.T.,,"webdbf",,.F.)
*
* Indicizzo il database principale
* è preferibile usare la funzione ordcreate con gli RDD
* a tag multipli: ordcreate(<indexname>,<tagname>,<exp>)
*
webdbf->(ordcreate("webdbf","masterx","codimerce+codice")
webdbf->(dbgotop())
DO WHILE ! webdbf->(eof())
   *
   * crea un DBF per ogni codimerce ordinato su codice
   *
   dbname := webdbf->codimerce
   *
   * L'array aDUMMY serve solo se vuoi un sottoinsieme di campi
   * altrimenti può essere omesso
   *
   webdbf->(__dbCopy(dbname,aDUMMY,,{||webdbf->codimerce == dbname}))
   *
   * eventuale creazione degli indici per i DBF piccoli
   *
   dbusearea(.T.,,dbname,"dbtmp",.F.)
   dbtmp->(ordcreate(...))
   dbtmp->(ordcreate(...))
   dbtmp->(dbclosearea())
ENDDO
webdbf->(dbclosearea())
Con questo non è detto che risolvi i tuoi problemi con DBFCDX
però il programma mi sembra più pulito e funzionale.
Ti consiglio inoltre di aggiornare Clipper 5.2C alla 5.2e
molto più affidabile.
Per l'aggiornamento : 
ftp://ftp.ca.com/CAproducts/clipper/
Ciao,
Paolo

Scusa ma ho fatto un paio di errori nel msg. precedente
1. mancava una parentesi nella 1.a ordcreate
2. sempre nella ordcreate, usando una chiave composta
   č richiesto un ulteriore parametro con la chiave stessa
   sotto forma di codeblock
Pertanto il tutto diventa:
dbusearea(.T.,,"webdbf",,.F.)
*
* Indicizzo il database principale
* č preferibile usare la funzione ordcreate con gli RDD
* a tag multipli: ordcreate(<indexname>,<tagname>,<cexp>,<bexp>,[<unique>])
*
skey := "codimerce+codice"
webdbf->(ordcreate("webdbf","masterx",skey,&("{||"+skey+"}")))
webdbf->(dbgotop())
...
La parte riamnente andava bene !!
Ciao

 DOVE SBAGLIO?
In che senso "non lo vuole"?
EMG

    webdbf->(__dbCopy(dbname,aDUMMY,,{||webdbf->codimerce == dbname}))
Questo è invece un serio problema che l'uso delle funzioni comporta:
l'accesso diretto a parti dell'implementazione della libreria di Clipper
che in realtà sono solo ad uso interno e potrebbero cambiare da una
versione all'altra (e dato che il Clipper è tutt'altro che morto, vedi
Harbour, questo rischia di non essere solo una questione accademica).
EMG

chiaro) viene tradotto proprio con quella chiamata.
Non mi è affatto sfuggito, so benissimo come vengono tradotti i comandi
Clipper
nel file 
std.ch
, il fatto è che i comandi non mi piacciono per almeno 4
ragioni :
1) Nella maggior parte non consentono l'uso dell'alias, costringendo a cose
   del tipo:
  old_area := SELECT(wrkarea)
  SEEK mkey
  IF FOUND()
    .....
  ENDIF
  SELECT(old_area)
  invece del praticissimo (e secondo me molto più chiaro) :
  IF wrkarea->(DBSEEK(mkey))
    ...
  ENDIF
2) In alcuni casi possono generare confusione sulla funzione chiamata :
   Es.: INDEX ON <mexp> TO <mfile>
   Viene tradotto con la funzione ->dbcreateind() e NON ->ordcreate()
3) Usando metodologie OOP ci sono vari problemi, come hai detto anche tu,
   e noi ne abbiamo usato pesantemente (vedi Librerie OOP su ns. sito)
4) Molti comandi hanno parametri che vengono tradotti in codeblock.
   Utilizzando direttamente la funzione, si ha una flessibilità
   nettamente superiore.
Per quanto riguarda le funzioni interne non mi risulta che una sola sia
stata cambiata
dal 5.0 al 5.2e (almeno di quelle che uso io)
In fondo cambiando la versione dovresti comunque ricompilare,
quindi il prezzo da pagare sarebbe qualche replace all...
Secondo me i comandi sono più usati da chi non conosce a fondo il linguaggio
o ha
meno dimestichezza con linguaggi tipo C e C++.
A mio avviso rimane comunque una scelta molto personale, resta il fatto
che la stragrande maggioranza dei programmatori Clipper che io conosco usa
di preferenza le funzioni.
Spero comunque che le ns. discussioni continuino ancora,
magari ci incontreremo in qualche occasione, così potremo spiegarci meglio,
e forse scoprire che in fondo la pensiamo allo stesso modo.
Ciao
Paolo R.
paolo....@soft-com.it
http://www.soft-com.it

 e forse scoprire che in fondo la pensiamo allo stesso modo.
Alla fine lo scopo è lo stesso. E' giusto che ognuno segua la sua strada
per arrivarci.
EMG

programmi DOS in programmi per l'ambiente Windows (grazie alle Fivewin).
Di questo ero e sono pienamente consapevole, e ti posso dare pienamente
ragione.
Si tratta di una scelta di progetto. Personalmente non ho mai avuto
intenzione
o esigenze di portare applicativi da Clipper a Windows, neanche tramite
FiveWin.
Preferisco usare per ogni ambiente, e a seconda del programma da realizzare,
il linguaggio che più si addice alla situazione.
Paolo R.

 il linguaggio che più si addice alla situazione.
Pensi quindi che il Clipper non sia adatto a sviluppare un gestionale
sotto Windows? Beh, ripensaci. :-)
EMG


Ciao
Paolo

EMG wrote:
Ma soluzioni nuove non significa sempre soluzioni più efficienti.
.......
(omissis)
Questa volta non voglio più risponderti punto x punto.
Mi sembra che il thread sia già lungo abbastanza, e poi,
visto che nessun altro è intervenuto, rischia di diventare
una questione personale che interessa poco il NG.
Concluderò solo dicendo che, pur riconoscendo la validità
di alcune delle tue affermazioni, resto convinto della bontà delle
ns. scelte di programmazione, avvallate dai riconoscimenti di chi
giornalmente utilizza i ns. software.
In fondo io cerco di intervenire sul NG principalmente per risolvere,
quando posso, i problemi che qualcuno espone, e poi per avvalermi delle
esperienze altrui per crescere professionalmente, cosa che del resto,
giudicando i tuoi interventi hai sempre fatto anche tu.
Ti inviterei pertanto a rivedere i termini del problema che ha dato
origine al thread, e a riconsiderare la mia soluzione che mi sembra
oltre che efficiente, anche molto elegante.
Devo anche dire che a differenza di molti del NG, noi non abbiamo
seguito la strada VO, avendo provato la versione 1.0, che era veramente
improponibile e a mio avviso ha scoraggiato tanti programmatori dal
proseguire con gli strumenti di CA.
Sicuramente la versione attuale sarà tutt'altra cosa, ma penso che la
ns. scelta di affidarci prima a Borland C++ e successivamente a CBuilder sia
stata e riamanga una delle più valide per programmare efficientemente in
Windows.
Non sono d'accordo che Clipper sia adatto a sviluppare gestionali sotto
Windows.
Clipper è nato per sviluppare gestionali, è stato un linguaggio eccezionale
per
facilità di apprendimento ed efficienza, ma ha fatto il suo tempo.
Continuare a metterci delle pezze per mantenerlo in vita, equivale a fare
ciò che Microsoft ha fatto con Windows per mantenere in vita il Dos :
un s.o. pieno di problemi (ma forse lei non aveva altra scelta, noi si).
Sicuramente non userei Clipper per sviluppare un gestionale ex-novo per
Windows,
esistono oggi numerosi strumenti nati per questo ambiente, che consentono di
creare applicativi x Windows in maniera molto più "naturale".
Cito solo quelli che abbiamo utilizzato con profitto negli ultimi anni :
Delphi,
CBuilder, PowerBuilder, Microsoft Visual C++.
Ho tralasciato volutamente Visual Basic perchè non lo considero un
linguaggio
adatto a scopi professionali (sopratutto per prg. gestionali).
Ciao,
alla prossima ...
Paolo R.

 > > DOVE SBAGLIO?
ma non puoi proprio fare a meno di questi indici condizionali
Creare un bell'indice solo su sub-tipo e gestirlo con una seek
e un do while non va bene ??
Altrimenti crea altri n file, uno per sub-tipo come con il principale
o no ??
Ciao
Paolo R.

 invece di padr("CIAO",15)
Scusa, ma non vedo proprio come il sistema riesca a discernere tra i due
tipi di padding. Sono quasi certo che il problema sia da qualche altra
parte...
EMG

 adatto a scopi professionali (sopratutto per prg. gestionali).
Su questo siamo perfettamente d'accordo.
EMG

 o no ??
Scusa ma non riesco a capire bene a cosa ti riferisci. Spiegati meglio,
per favore.
EMG

per favore.
Evidentemente, ed č la 4.a ed ultima volta che te lo dico, non hai letto
bene il problema prospettato su questo thread !!
Seguiti a dire che i tuoi interventi sono costruttivi, ma continui ad
ignorare il problema e a criticare le soluzioni proposte.
Senza rancore
Paolo R.

esso a filo doppio i poveri sviluppatori malcapitati.
Non ho mai scritto gestonali in C++, parlando di quello puro
(es. Borland C++ 5.02), anche se non credo sia un delitto,
ma visto che sviluppiamo anche software tecnici, lo usiamo con profitto.
Come già detto io cerco, quando possibile, di scegliere il linguaggio
più appropriato al problema da risolvere.
Per Visual C++ vale il discorso fatto per Delphi (non è una ns. scelta,
e concordo in buona parte con le tue osservazioni sullo standard).
Se invece ti riferisci a CBuilder, evidentemente lo hai utilizzato
molto poco, o non lo hai mai utilizzato seriamente.
CBuilder ha la sintassi del C++, rispettandone quasi in toto lo standard,
però ha in più la potenza dell'interfaccia visuale e dei componenti forniti
a supporto del linguaggio, che ne fanno uno strumento che ha ben pochi
rivali nello sviluppo di applicativi gestionali (e non solo).
L'unico rammarico è che la libreria VCL, su cui si appoggia l'ambiente,
sia stata scritta in Pascal, ma è comunque di secondaria importanza.
Paolo R.

 Senza rancore
Figurati. Io non me la prendo di certo.
EMG

 rivali nello sviluppo di applicativi gestionali (e non solo).
Ne terrò conto.
EMG

Questo  thread č stato molto emozionante, e per tale ragione volevo lasciare una
piccola traccia.
Conosco da anni Paolo e anche il modo col quale lavora. Mi piace molto come
scrive il codice, anche se credo che, a volte, utilizzi delle forzature
eccessive. Personalmente non sostituirei una
USE <file> NEW
con una
DBUSEAREA()
se non in casi particolarmente complessi.
Sono perň largamente a favore delle funzioni, rispetto ai comandi, piu' per altro
per l'uso dell'alias, che permette un risparmi di numero di righe di codice
scritte e permette di capire esattamente dove viene eseguito
il codice.
Ho visto parecchie persone che, scrivendo comandi senz'alias, eseguivano
operazioni su aree diverse, o, orrore, usavano l'alias per numero (5)->(DBSEEK(
... )).
Diciamo che la cosa importante e sapere cosa si sta facendo, con certezza
assoluta, poi il come č un discorso secondario.
Inoltre vorrei dire che, essendo un linguaggio non piu' sviluppato, clipper
rischia, ogni giorno, di incontrare nuovi problemi insormontabili.
Per esempio, pur essendo una buona libreria FiveWin, clipper ha un problema
interno di gestione dello stack, e per tale ragione applicazioni oltre il MB di
dimensione rischiano di uscire con errori di 667 di eval stack fault.
I DBF, non essendo "di default" gestiti in modo client server, sono molto
sensibili a corruzioni, date magari da una sola di X macchine collegate in rete.
Ci sono dei problemi fisici di dimensioni di archivi, memo (32MB), lunghezza di
campi (64K), variabili (64K) arrai (4096) valori .. spero di essermi ricordato
tutto bene ...
I DBF non gestiscono le transazioni, quindi non posso impostare un sistema
transazionale sicuro su DBF, clipper non gestisce le eccezioni, non č possibile
programmare in multithread ... etc etc.
Tutti questi sono aspetti importanti che non possono essere sottovalutati
Harbour, e qui vorrei dire un paio di cose.
Sicuramente l'idea č buona, ma il progetto non č ancora maturo. Per tale ragione
si sta pianificando ora la gestione dei thread, e si sta sistemando il sistema
degli RDD. Inoltre le browse sono ancora incompatibili e non č ancora possibile
chiudere applicazioni "utilizzabili" in modo pesante.
Vedremo, ma ci vuole ancora 6 mesi/1 anno di lavoro per avere una versione
stabile ed utilizzabile.
Tornando a FiveWin non vorrei che si sopravvalutasse il povero Antonio e il suo
team di sviluppo, che sicuramente non č esteso come il gruppo di lavoro che c'e'
dietro a linguaggi come Java e C++ o VB o VC.
Inoltre non esiste un vero RAD per FW e neppure per Harbour.
E tanto per essere in tema, credo che, per esprimere qualsiasi problema, si
debba, prima di tutto, usare l'ultima versione di un prodotto. Clipper 5.2, fino
alla versione C č inutilizzabile: indici non stabili, problemi di memoria e chi
ne ha piu' ne metta. Poi con le versione successive č diventato molto affidabile,
anche se molto dipende anche dal linker, che ci mette del suo per dare o non dare
stabilita'.
Lo stesso vale per 5.3, usare per forza la B.
A parte questo, DBFCDX di 5.2 hanno il problema di non tenere aggiornato l'array
dei record lockati, DBRLOCKLIST() e chi usa tale funzione puo' avere problemi,
inoltre il motore di 5.3 e' COMIX, quindi completamente diverso rispetto a 5.2 e
quindi con errori completamente diversi.
Ultimissima nota, mi e' molto piaciuto vedere questo accanimento nel difendere
delle posizioni, ad un certo punto pensavo partisse un pugno da parte di
qualcuno, ma per fortuna le acque si sono calmate.
Matteo Baccan



 di più moderno.
Per i DBF secondo me vale lo stesso discorso delle 10 e 50 righe
poi dipende da tipo e dimensione dell'applicativo, forse se hai
50 posti di lavoro DBF non va piu' bene ma con 4/5 posti di lavoro
hai una soluzione molto piu' snella, sempre meglio di quella ciofeca
del Jet Engine. Comunque questo e' opinabile, io preferisco ancora
i DBF
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 qualcuno, ma per fortuna le acque si sono calmate.
Quando si sono calmate? :-)))
EMG

 molto meglio di Harbour, almeno Xbase++ e' usabile oggi.
Però, almeno da quello che sento, la velocità dei programmi xBase++ non
è eccellente. Le voci sbagliano?
EMG

 Quando si sono calmate? :-)))
8->>>><
Matteo Baccan

 è eccellente. Le voci sbagliano?
non sbagliano .. purtroppo, ma sicuramente la versione 1.5 ha velocizzato
di molto, alcune operazioni .. peccato che sia un ambiente estremamente
prolisso, le applicazioni convertite tendono ad esplodere come dimensioni
se paragonate a pari exe in clipper .. pero' almeno .. e' abbastanza stabile,
non da mano sul fuoco, ma da programmarci allegramente si

 preferisco il primo, il 2' e' un po' piu' pasticciato.
Secondo me un RAD va bene solo per software altamente standardizzato. Se
uno, come me, deve produrre programmi strettamente personalizzati (e
ogni utente, nonostante i miei sforzi "standardizzatori", la pensa in
modo profondamente diverso...) credo che alla fine rappresenti solo un
intralcio. Sbaglio?
EMG

applicazione
Gestisco da 5/6 anni la mia quasi unica applicazione clipper, un
gestionale più o meno completo di contabilità, magazzino e vendite per
un'azienda di medie dimensioni dove lavoro.
Ad oggi, ho in linea 100.000 testate documenti, con circa 1.500.000
righe documento collegate, che interessano l'arco di 4/5 esercizi
fiscali.
L'indice relativo alle righe documento (.CDX, con Clipper 5.3b) è
attualmente di 94Mb.
Forse mi considerete un poco pazzo a gestire queste mega dimensioni,
in realtà, è pronto da sempre (oltre agli automatici backup
giornalieri) un sistema per archiviare in file (per esercizio fiscale)
diversi i documenti di cui sopra, al verificarsi di eventuali
problemi.
La comodità di effettuare ricerche su un unico file, comunque mi ha ha
fatto scegliere di tenere tutto assieme (almeno finchè questo sarà
possibile).
Per le semplici ricerche di mia necessità, non ho notato cali
prestazionali sensibili, o comunque tali da giustificare la divisione
in + file.
Queste considerazioni, non per fare smentite a quanto detto, visto che
non ho una grande esperienza e comunque non sufficente ad essere un
interlocutore alla pari con la vostra professionalità; ma piuttosto
per chiedervi se la linea che sto seguendo, (e le precauzioni prese)
può essere proseguita secondo voi.
Grazie e scusate ancora per l'intromissione.
Luigi Dorigo

 può essere proseguita secondo voi.
Secondo me, se hai già previsto (come hai detto) che, in caso di
emergenza, i vari esercizi possano essere separati, puoi continuare
tranquillamente. Un problema di lentezza potrebbe (dico potrebbe)
presentarsi in caso di richieste di ricerche più complesse.
EMG

 intralcio. Sbaglio?
Il RAD non vuol dire "gabbia" ma, "sviluppo in un minuto quello che di solito faccio in un
ora", poi puoi fare tutte le integrazioni che vuoi, manualmente, e soddisfare tutti i
clienti che vuoi.
Se il tuo cliente ti fa smontare l'applicazione funzionante perche' "non mi piace il
pulsante a derstra rosso, con la scritta blu, lo vorrei a sinistra verde, lampeggiante e
disabilitato in base ad un codice cliente" e paga ... ok, se lo fai a mano ci metti 1 H,
con un RAD/CASE lo sposti in 3 secondi, lo condizioni in 1 minuto e rigeneri in 10
secondi.
In 5 minuti hai fatto ...
Averlo fa comodo, se l'utente vede subito la sua interfaccia, alla peggio ti chiede
personalizzazioni minime, ..
quindi "why not?"
Non ho "mai" visto cose che non si potessero scrivere con un RAD, dato che e' integrabile
in ogni punto dell'applicazione. Prendi la tua applicazione .. la linki ad un applicazione
di un RAD e la puoi usare come una componente dell'intero ambiente ...
Comunque questo argomento e' OT treeeeeeementamente, poi, come sai, sono di parte e vedo
la cosa da "genitore" e non da utilizzatore.

le hanno ben chiarite all'interno del documento).
Mi sembra in effetti che quando parli di C/C++ sei un pň in difficoltŕ.
Cosa vuol dire "non č il massimo della comoditŕ" ??
Forse per chi non lo ha mai usato, per me il C++ č il miglior linguaggio
che un programmatore possa desiderare, l'unico che ti dia il pieno controllo
di ciň che stai facendo, altro che "sottili e complesse trappole" ??!!
Non č nemmeno vero che non sia adatto a scrivere programmi gestionali,
per esempio MxW (Mago x Windows - uno dei gestionali piů diffusi) č
scritto completamente in MFC e Visual C++.
Eviterei comunque di dare dei giudizi su un prodotto, non avendolo mai
utilizzato.
In fondo con che linguaggio credi sia stato scritto Windows ??
STOP.
Un saluto a tutti quelli che sono intervenuti.
Paolo R.

 clienti che vuoi.
Ti credo sulla parola. Comunque io, per il momento, non ne sento il
bisogno. Ho tutti gli strumenti necessari per velocizzare al massimo il
mio lavoro.
EMG

 In fondo con che linguaggio credi sia stato scritto Windows ??
In C, non certo in C++.
EMG

 bisogno. Ho tutti gli strumenti necessari per velocizzare al massimo il mio lavoro.
<pensiero_di_parte>
E se il lavoro dovessi cederlo a qualcuno? o sviluppare in team .. o risolvere un problema
diffuso .. o introdurre un nuovo RDD, o cambiare linguaggio da Clipper x XBase++?
Con un case hai tutto centralizzato e lo realizzi in pochissimo tempo .. e l'ultimo passaggio ..
da Clipper/DOS a Xbase++/Grafica GUI .. lo fai in 5 minuti, mantenendo TUTTI i progetti
realizzati prima .. ma forse fare tutto da 0 è meglio?
</pensiero_di_parte>

 </pensiero_di_parte>
No, no, condivido. Solo che ho avuto a che fare anni fa con un CASE e ne
sono rimasto praticamente disgustato. Quindi questo me ne fa tuttora
dubitare.
EMG

 dubitare.
In questo caso non possiamo pensare allo stesso modo, per ovvie ragioni e trascorsi.
Ora che il thread e' finito .. ne aprirei un'altro, se sei concorde. Come usare harbour con
applicazioni clipper e viceversa .. installazione etc .. se ti interessa partiamo un po' alla volta a
vedere cosa installare e a farei dei test di porting, cosi' vediamo quant'e' compatibile e in quali
casi puo' essere da alternaiva a clipper ...
apro?

 apro?
Sono molto interessato. Il problema è che finché non saranno pronti gli
RDD lo strumento è incompleto (io infatti aspettavo quelli). Comunque
procediamo pure.
EMG